The big important project you’re on is tough and it solves a critical business problem. How do you know when it has become a “Death March”?
Read on to see a list of criteria to help you evaluate your project, but first let me tell you the story of project “Maverick.”
I was a part of a big organization with lots and lots of users. Our ID provisioning process simply could not scale to meet our growing user base, and we were unable to grant and revoke access. The toolset we had chosen to solve this problem was promising – it could scale to an appropriate level and was buzzword-compliant with our incumbent tools.
Unfortunately we could not build a test environment with a big enough workload to fully vet the toolkit. The only way to know whether it would work was after a big bang implementation. Using hindsight it seems obvious that this was risky with a capital R.
When I joined the team the project had been going on for about three years. Each time there was a setback the project leadership earnestly believed it was simply another hurdle to be overcome. Over time the small new investments grew to the point where quitting would have meant greater and greater losses, both financial and political. No one wants their project to fail – especially after they’ve gone to the well over and over again to ask for more money.
We were fortunate that after launch the initial damage was limited to about 700 user groups which were emptied – denying acces to hundreds of users. This cost us a ton of unbudgeted overtime costs to manually clean up the mess after we backed out the new system from production.
Eventually we concluded that the project was not merely difficult but actually was not going to succeed no matter what we did. Now what?
We had to find a way to:
a) Solve the business problem that the project was intended to address, and
b) Allow the project to gracefully shut down without the leadership losing face.
a) Solving the business problem:
- New team capability – Over the course of the project we had grown our internal development teams (needed for enterprise system integration).
- Reuse of tools we already owned – We looked around at other enterprise-approved technologies that could attack parts of the problem so we could avoid the “big bang” aspect. It also allowed us to “fail fast, fail cheap” by developing some prototypes before the big project was officially dead. Quick successes in that area helped our credibility when we started to talk about letting Maverick die.
- New tools – We had acquired another toolkit which could act as an important front end of the alternative to Maverick.
- Big bang – In all my years I have never seen an effective launch replacing an incumbent system where the new system required a big bang implementation. If this is a key component of your plan – this should be a red flag, and a big one.
- Very complex system architecture – the solution covered a number of different areas, with little margin for failure – a crash in one subsystem would flow to many other systems.
- Huge initial implementation cost – It’s true that you get what you pay for, but since we would not see any results until after the new system was in place, this was a risk factor.
- Successive failures requiring significant unscheduled investment – none of these seemed big enough to justify killing Maverick, but the sum of the accumulated costs made the decision clear.
- Timeline extensions due to scope changes and failures.
- Multiple changes in project leadership – the factors above contributed to turnover in project leadership.
- Lack of faith in the solution. The team no longer believed it would work, so why go the extra mile for something doomed to failure?
Knowing when to walk away is a key part of Raising Your Game.
Leave a Reply