It takes a strong leader to kill a bad project. This post is part of a series called Will Somebody Please Kill This Project?

If you’re a project leader on a project that needs to be killed, you’re likely looking for an exit strategy to make the decision a little easier. You’re looking for something to help the team swallow the bad news; you want to say it was worth the effort. You want to say there was some value in what the team has accomplished — even though the project did not meet objectives.

Look, there may not be much to salvage. Shelve the code. Facilitate and document the post-mortem. If you’re lucky, there’s a component you can use on another project.

But even if there’s nothing to salvage, put the project to bed.

This is difficult stuff. But if it needs to happen, you need to find a way to make it happen.

Take care of your team; rally them around their new direction; make it happen.

-Donny

It takes a strong leader to kill a bad project. This post is part of a series called Will Somebody Please Kill This Project?

We may not say this out loud, but we are worried about how we look if we have to kill a project — to our management, our peers, and our team.

We want to be right, and killing the project probably means we were wrong.

So we keep driving down the wrong road (escalation of commitment). Go figure.

Look, if you’re on a project that isn’t likely to deliver bang for buck, you’re squandering company resources. 

Yes, it looks bad.  Suck it up and pull the plug. 

If you don’t, it gets worse.

-Donny

The new solution will be based on newer technology and will have a better architecture. The old system is not scalable and it’s hard to add new features.

You’ve heard these lines. Maybe you have even used them to justify a project.

These statements are code for:

We would rather write new code than fix the old code.
We would rather build a new architecture than refactor an existing architecture.
We would rather develop on a new technology.

I’m not being completely fair. No doubt, the old system is messy and the new system will be designed to do things better.

But technology and architecture do not deliver value directly and are insufficient criteria for project viability.

The real question is:

What business value does the project deliver — above and beyond what you have today?

-Donny

It takes a strong leader to kill a bad project. This post is part of a series called Will Somebody Please Kill This Project?

No Project Review Process

Companies and organizations that pride themselves on intellectual horsepower spend millions on software projects without establishing project checkpoints to review and confirm basic project criteria —  even when business conditions have changed dramatically since the inception of the project. 

Not smart.  This is the stuff that kills companies.

For major projects, facilitate an objective business review with key stakeholders to guide the project and provide continue/stop/adjust-course decisions at the end of  each phase.  Questions to consider:

• How much more will we spend before this project delivers benefit?
• What is the value? How is the value quantified?
• Are we willing to spend this much for this value? Is now the right time to make this investment?

In other terms, would we spend this much money to buy this system if a vendor showed up on the doorstep with it today?

If you’re not asking the right questions about your projects, you’re probably squandering company resources and damaging your company’s capability to deliver real value and operate profitably. 

-Donny

Software development projects are hard to kill. Even when they are ill-conceived, poorly executed, and deliver insufficient value for your company.

Why? Several factors and mental traps can prevent us from shelving projects that need to die.

Sunk-Cost Bias

“We would kill the project if we hadn’t already invested so much.”

Sunk costs have no basis in future decisions, yet engineers, managers and executives fall blindly into this well-documented thinking trap. 

This may be the first excuse you hear (or use) to continue escalation of commitment to a bad project.

Debunk this fallacy quickly and move on to the relevant factors.

-Donny