Probably the hardest decision to make in any organisation is the decision to kill a project that’s underway.
Time, effort and money has been sunk into it. There are expectations of its completion — successful completion is preferred, but, when the chips are down, bare completion will do.
Egos are involved. Reputations, too.
No wonder so many enterprises have trouble with this.
Yet killing a project that cannot succeed is an act of mercy in many ways.
A project is in trouble when it starts slipping off the projections made for it. Projects are funded, approved and released for execution because the enterprise expects a certain result to obtain in a certain timeframe.
As a project absorbs more resource, more money, or more time than planned, the point at which benefits starts to flow recedes into the future. Meanwhile the costs are current, eating into the results obtained in this quarter.
Well, no plan survives contact with the real world. A good plan should have buffers built into it to deal with change.
But what if the reason the project isn’t proceeding well is because there are fundamental disagreements in the business about core aspects of the business? (This happens far more frequently than you might think.)
What if the process isn’t anywhere near as simple as it looked, and new marginal use cases are proliferating? (This happens when work is not drawn from the simple order, but a simple, process-centric solution is being imposed.)
What if the business area refuses to let go of the past, imposing major modifications to preserve it? (This often happens with package implementations: one of the reasons so many organizations are salted through with heavily-modified packages left over from the Y2K period is because the business area could insist, and the deadline was fixed.)
In all these cases there is no reason to continue to implement the project. It should be stopped and the underlying issues be sorted out.
In today’s world of delivery-as-a-service and outsourcing partners, there are other reasons why a project might be killed and the whole issue rethought.
I know of one organisation with a hard deadline for change: every year, they require a change freeze while a major annual activity takes over the business.
This year they decided to engage with a new outsourcing partner. Promises were made to win the business. While price mattered, commitments for when things would occur mattered more.
That vendor, having won the day, calmly ignored all their promises. It’s now a race against time as to whether everything can be done before the freeze comes on.
In this case, a lot of night hours, and a lot of screaming, probably brings things home — just. In many other cases, there’d be one too many items to close the loop on in time.
Then there’d be payments for old and new in parallel for weeks, while the freeze unwound.
There, too, a kill decision would have been in order. (If the vendor wanted to pay for the old services to keep the business alive, that would be a point of negotiation.)
Kill decisions, in other words, not only free good people up from projects that will potentially damage their futures, and free the organisation up to deal with its underlying issues, they can also lead to a much better vendor relationship.
One of the key jobs of the Governing Board is to make kill decisions. That way, it’s not one person’s call — with all the political ramifications — but an enterprise decision.
So make them.