Day 87 of a 90-day engagement, and the demo room has that specific silence. The client's ops director is staring at a dashboard nobody on her floor asked for. The lead consultant is staring at his shoes. You are staring at the calendar, doing mental math on three months of burn rate, and the number you keep landing on is zero: zero users, zero shipped workflows, zero chance of a renewal.
I've been in that room, and the lessons from that failed software consulting engagement still shape how I scope every project. This is the retro I wish somebody had forced us to write on day one.
The most useful failed software consulting engagement lessons come from the projects that crater completely, and this one left a smoking rim. A mid-size distributor, forty people on the ops team, a fat signed statement of work, and nothing in production at the end. Here is the honest autopsy, with everyone's fingerprints left on the wreck, including mine.
Why do engagements like this fail? For boring reasons, mostly: no single accountable owner on the client side, a spec document mistaken for a discovery process, and a team that built for the demo instead of the floor. The fixes are equally boring, which is why nobody does them: name one owner, shadow real workers before writing code, and ship something small in week two no matter how ugly it is.
The Setup That Doomed Us
The client was a regional distributor, call it 200 people, running its operation on a spreadsheet empire that had accreted over a decade. Receiving lived in one workbook, inventory adjustments in another, and a woman named Deb reconciled them every afternoon from memory. Classic setup. The kind we've seen collapse under its own weight before.
That deal got signed by a VP who wanted "a modern inventory platform" and had a budget cycle to beat. Notice what that sentence lacks: a workflow, a user, a problem stated in the language of the warehouse. The statement of work was twenty-two pages of nouns. Dashboards. Integrations. Role-based access. It read like a brochure, and we treated it like a spec.
Red flag one, visible from space: nobody on the client side was named as the owner. There was a steering committee. Steering committees are where accountability goes to be diluted into a fine mist. Red flag two: we were explicitly told not to bother the floor staff during the first month because they were "too busy." We nodded. That nod cost three months.
Weeks One to Four: Shadowing Nobody
The FDE model, the thing that makes embedded engineering work, starts with sitting next to the person who does the job. You watch Deb reconcile. You notice she keeps a sticky note of SKUs that "lie." You learn that the receiving dock ignores the system every Friday because the truck schedule changes. That is discovery.
What we did instead was schedule interviews. Fourteen of them. Managers, mostly, plus one very polished walkthrough of a warehouse that had clearly been tidied for visitors. Managers describe the workflow they believe exists. The floor runs the workflow that actually exists. The gap between those two documents is where engagements go to die, and we set up camp right in the middle of it.
By week four we had a beautiful process map, validated in a review meeting, signed off by six people, and roughly 60% fictional. Nobody lied to us. They just described the org chart version of the work, and we had no floor time to contradict it.
The Prototype Nobody Asked For
Weeks five through ten, we built. And here I have to own our side of the wreck: the prototype was genuinely good engineering aimed at the wrong target. Clean data model. Sensible permissions. A receiving flow that matched the fictional process map to the pixel.
Demo day arrived, and the ops director brought two actual receivers, which we had not expected. Receiver number one tapped through the flow, frowned, and said the sentence that ended the engagement: "We can't scan it that way when the truck's late." Which was every Friday. The workaround Deb ran from memory, the one we never saw because we never sat with her, was the real process. Our software encoded the brochure.
We spent the remaining weeks in rework purgatory, and the trust was gone. Rework without trust is just a slower way to fail. Compare that with an engagement where software got built for the warehouse floor first and the demo was almost an afterthought, because the users had been in the room since week one.
Failed Software Consulting Engagement Lessons Worth Keeping
Out of the crater, five lessons survived. We now treat them as non-negotiable.
Kill the spec doc
A statement of work written before discovery is fan fiction. Replace it with a one-sentence problem, named in the user's language, plus a list of things we explicitly will not build. Everything else gets rewritten after shadowing, and the contract should say so.
Name a single owner
One person on the client side who can say yes, say no, and get fired if it fails. If the client can't name that person, the engagement is already over; you just haven't had the meeting yet.
Ship in week two
Something small, something ugly, something a real user touches. Not a demo. A deployment. The reason isn't speed for its own sake: it's that every week without a real user is a week you're building against fiction. This is also why shipping during peak season is sometimes smarter than waiting for calm; the floor's real behavior only shows up under load.
Price the emotional buy-in
Debs don't resist software because they're stubborn. They resist it because the last three tools made their afternoons worse and then got abandoned. Budget time to win the Debs. It's a line item, same as hosting.
Know when to walk
Week three is the cheapest exit. If you have no owner, no floor access, and no path to either, say so and leave with the relationship intact. We stayed because leaving felt like failure. Staying was the failure.
How We Run Retros Now
Blameless, but specific. Those two words fight each other, so we use a rule: you may never name a person, but you must always name a decision. "The spec was fiction" is allowed. "Communication broke down" is banned, because it means nothing and fixes nothing.
Every retro ends with the checklist, and the checklist gets applied to the next engagement's first week. Owner named? Floor access scheduled? Week-two deploy scoped? If any answer is no, that's the meeting. Not month three.
What a Good Engagement Looks Like Instead
The counterexample I keep in my head is a ninety-day logistics engagement that actually shipped. Same industry, similar size, opposite outcome. The differences were not talent or budget. The client's dispatch manager co-owned the project, the engineer sat in the dispatch pod from day two, and the first ugly tool, a glorified exception list, was live in front of drivers in week two.
That engagement had arguments, scope fights, and one genuinely terrible deploy. It also had users. Users forgive everything except irrelevance.
So if you're staring down a new engagement, whether you're buying it or building it, steal the checklist and skip the crater. Three months is too long to learn lessons this expensive twice.