Sometimes you just have to crack on

Sometimes you just have to crack on.

I’m working with a team on a project that isn’t where it needs to be. They conducted a discovery session with a client for an e-commerce website. However, the focus of the session was more on brand and visual design, while the technical discovery was missed.

This particular e-commerce platform is quite involved. There are a few things around product bundles, credits, and subscriptions that aren’t your standard way of doing things.

The Issues: Client Relations and Project Slippage

Where I think this project might have slipped is due to the fact that the client is a long-term one and quite good friends with the team. As a result, they’ve been a bit relaxed with it.

We noticed that there hadn’t been much time scheduled for this project. Upon further investigation, we realised they hadn’t gotten a scope of work (SOW) signed. Yet, development had already begun after the designs were completed.

Red Flags: Unspecified Designs and Miscommunications

As I dug into this, realising this is a bit of a red flag, I noticed that the designs had been signed off. However, there were multiple comments, emails, and videos from the client expressing uncertainty, saying things like, “Not sure what we should do here. We need to think about this, etc.”

This suggests that the designs weren’t actually signed off because not everything had been fully specified.

The Misstep: Starting Development on the Wrong Site

A developer had started doing some work based on the designs for a brand new site. However, upon reviewing the communications, we realised they needed to update the existing site instead. We can’t move to a new site because there’s a lot of custom stuff that already exists, which we wouldn’t have time or budget to rebuild from scratch.

The Dilemma: Time Constraints and Risk Management

This situation has turned into a bit of a spider web: things have been started, some left unfinished, no clear timeline, no signed SOW, and we’re burning time until the client’s big launch campaign in about four months.

My instinct was to say, “Hang on. Let’s just pause, take stock, and get things sorted.”

Course Correction: Reworking the Project Plan

I had a couple of conversations with the client and started piecing together a functional and technical specification of what we’re actually going to build. We then retroactively created a scope of work to ensure we’re all covered.

This process took a couple of weeks, involving a lot of conversation, and we burned a lot of time—ultimately impacting our margin in this case.

Moving Forward: Proceeding at Risk

This situation wasn’t the client’s fault; we allowed it to happen. However, we still need to deliver for them. One of the company directors suggested, “I think we just need to go with what we know and accept that we’re going to need to work out some of this stuff as we go.”

Obviously, that’s not the best or most efficient way to do things. But given where we are, we could easily spend weeks retracing our steps, having repeated conversations with the client to fully spec everything out. But we can’t bend time, we have to hit a deadline.

Accepting the Reality: Agile vs. Planning

While we are continuing without having everything defined, I would call this proceeding at risk. We know what we don’t know. That doesn’t mean everything will be okay, but it means we are getting work done that needs to be done regardless.

Some businesses might call this agile, but I see it as a lack of planning and preparation. However, given the circumstances, it seems like the best way forward.

The Plan: Prioritisation and Transparency

We need to proceed at risk. We need to progress the work we can, working out what we need to as we go. I think we all know there will be compromises along the way.

To hit the deadline, we might have to reduce some functionality. We might adopt a phased approach, delivering the most critical elements first and anything non-critical after the originally agreed deadline.

Conclusion: Honesty and Adaptation

The key is to be honest about what’s happened—with the team, the developers, and the client. Often, a lack of preparation makes everything stressful for everyone involved.

Typically, account managers and project managers will say, “Yeah, it’s going to be fine.” But clients get nervous when they don’t see much progress, everything gets compressed, developers get stressed, and there’s a lot of rework and bugs.

Even if you manage to tick every box, everyone ends up upset by the end of it.

So, the takeaway here is that sometimes you just have to crack on with what you can. Even though it’s not perfect - rarely are things in life - taking action in the right direction, while calculating the risks ahead is better than doing nothing.

However, it’s important not to proceed blindly.

This means letting the team work on what they can, while you stay one step behind, figuring out what needs to happen next. By proactively having conversations with the client and pre-empting complex sections of the scope, you’ll position yourself as best as possible given the circumstances, even if it’s not the ideal outcome.

Not everything is ideal.

You do have to adapt sometimes.