David A. Fields Consulting Group Sometimes things just go wrong. How you handle the situation as a consultant makes all the difference.
For instance, one of life’s little pleasures is a freshly detailed car. Last week, an expertly trained professional gently removed the thin film of grime and buffed some new-age, uber protective coating onto my sedan. And as I tootled down the highway, I couldn’t help but slow down and admire the deep, burnished glow of the metallic black hood.
That is, until I was passed by a tractor-trailer emblazoned with a pastoral scene featuring freakishly large cows glaring down at traffic while they munched organic grass. The artwork was actually catchy; however, either the heffers inside the trailer were enjoying one hell of a road trip or a large vessel had burst, because pouring from the rear of the trailer was a white waterfall of calcium goodness. An impressive flow that hit the pavement at 70 miles per hour and frothed all over my gleaming black car. My first thought was, “Milk? Seriously?!”
My next thought was that this was emblematic of consulting. Every once in a while a project wanders off the rails. I had a project go south recently. The client just wasn’t happy. The fact is, even the best designed consulting projects can stumble. Sometimes we fall short—we’re all human and fallible—or the client and consulting team mix signals or some exogenous land mine blows everything up. It really doesn’t matter why. What matters is how you recover.
Eight best practices will help you rinse off the sour milk of a troubled project and shine brighter than ever in your clients’ eyes. I’ve captured these eight best practices in a “Project Rescue” infographic, which you can download below.
Click Here to View The Full-Size Infographic
After you download the infographic, please share an experience you’ve had with recovering from an engagement that hit the skids. What did you do that made a difference?
Text and images are © 2025 David A. Fields, all rights reserved.
I had a project that hit the skids. What I did in the end was recommend 3 vendors to consult with to finish the project in the new way they wanted (dramatic scope change), which was not my area of expertise nor a solution I would recommend – based on benchmarking in the same industry and my gut.
Essentially, I saved them 40K with a shorter project (50% of the total cost), and apologized for it not working out as loosely planned. The PM (another contractor with the client company) was rather defensive and controlling throughout, insisting he knew best how to handle next steps in my area (not his). The client was quite passive and directed by him, so I graciously accepted my role ending in the project (along with the revenue).
It had always taken two months to get paid by the client, largely due to my not insisting on calendar scheduled payment terms (interdependent deliverables) and contract changes with a dynamic scope. I strongly suspected scope issues from the start, when I was asked to make training for software that was not fully configured! But I took the chance because I wanted the contract and to help my colleague. Lesson learned. Unfortunately, the client (my colleague) never responded to my calls or emails after that.
Fabulous input, Karen. One of the takeaways from your cautionary tale is to trust your gut and pay careful attention to any red flags that pop up prior to closing the deal. Your strong suspicion that there were scope issues were a good clue. I’ve found that when I ignore those types of warnings, I end up with a sour experience during the project. Thanks for your willingness to share a less-than-perfect project.