You Can Inherit a Project Without Inheriting Its Problems: Lessons from a Mid-Implementation Rescue

If you've worked in implementations long enough, you've gotten this call at least once: a project stalled somewhere in the middle, the customer's frustrated, maybe even to the point that they are an attrition risk, and now you're the one walking in to figure out what happened and what to do about it.

That was us here at DGD.

The previous implementation hadn't truly gone live. 

The customer team was frustrated and honestly, they had every right to be.

 It wasn't just that the software wasn't working the way they needed, it was that the whole process had fractured their trust. 

So when we stepped in, we weren't just picking up a half-built Workfront instance. 

We were picking up a relationship that needed rebuilding, too.

I spent a minute reflecting back on what that project taught us and why I think the lessons learned hold up well beyond just Workfront implementations. Here is the playbook for walking into a project that's already on fire.

Start by listening, not building

When something's broken, the instinct is to start fixing it immediately. 

But the first thing we did wasn't technical work at all, it was just asking questions and getting to know the project team and current challenges. 

• We requested access to the existing instance so we could actually see what we were working with.

•  We asked the customer what had worked, what hadn't, and where things had gone sideways. 

• We asked about their process before we touched a single configuration. 

• Only once we understood the real shape of the problem did we start deciding what to build, what to keep, and what to rip out.

Here's the thing about inheriting a project: you inherit someone else's assumptions along with it. If you don't test whether those assumptions are still true, you end up rebuilding the same problems with a fresh coat of paint.  An assessment isn't a delay, it's how you avoid that.

If there's one lesson this project reinforced, it's this: listening matters. I know I'm often guilty of jumping straight into problem-solving. But the best outcomes almost always come from slowing down first and understanding what people are really trying to say.

Skip the pretty plan, use every day you've got

We started real work in early January. The implementation was live by early March.

I'll be honest, that timeline wasn't the product of some beautifully sequenced project plan with clean milestones and a polished kickoff deck. Actually, my kickoff deck was pretty polished at the beginning but as soon as I understood the depth of what DGD needed to do, the need for pretty documentation drawing out timelines went out the window. 

There wasn't time for that, and frankly, it wasn't what the customer needed. What they needed was for every single day to count toward something real.

So that's what we did. We worked on whatever needed to happen next for the customer, not whatever a template said should come next.

 A project plan is a tool, not the goal. 

When trust is already thin and the clock's already running, customers don't need a gorgeous Gantt chart. They need to see real progress on the things that actually matter to them, week over week.

Make the call that's right for the customer. Yes, even when it's the harder one.

Inheriting a mid-implementation project means you're constantly choosing between the fast path and the right path. They're not always the same road.

Throughout this project, the decisions that ended up mattering most weren't the technical ones. They were the moments where we chose what was actually right for our client’s long-term success over whatever would've been easiest to deliver on a tight timeline.

Speed and integrity aren't actually in conflict, as long as you're honest about the tradeoffs as you go. The fastest way to lose a customer who's already skeptical is to quietly cut a corner and hope they don't notice. They notice. 

Trust gets rebuilt with honesty and momentum they can actually see.

Honestly, the biggest lesson from this project wasn't about implementation methodology at all. It was about how you rebuild trust once it's already been broken.

We were straight with the client, even when the update wasn't the one we wanted to deliver. Real talk: we also got to know the people on the other side of this project, not just their process and challenges, but we made sure the process had some fun in it too.

 And every single week, they could see real progress, not just at the finish line. 

That mix of honesty and visible momentum is what turned a skeptical customer into a confident one over eight weeks.

You can't just tell a customer to feel confident in you. You have to show it, over and over, in how you communicate and in how the work visibly moves.

The takeaway.

You can inherit a project without inheriting its problems. I’m not going to say it’s easy, but only if you treat the handoff as an actual reset, not just a continuation of the problems they have already been experiencing. 

1. Assess before you build. 

2. Use every day you have instead of every day a template says you should. 

3. Make the right call for the customer, even when it's the hardest one. 

4. And rebuild trust the only way it's ever really rebuilt: honestly, and out in the open, plus having some fun and learning about your customer as a human in the process too. 

That's what got our client to a successful go-live. And I think it's a pretty solid playbook for anyone walking into a project someone else left behind.