Robert Moses used lies and trickery to ensure that his projects were completed. He loved to start projects and let pride, politics, and sunk costs pull them to completion. Software development is notorious for grinding on and delivering projects years late that don’t solve the original problem.
SaaS project deadlines are artificial, usually the only thing that can stop a project is completion. Even projects with no developers will shamble on, zombie-like, eating a bit of everyone’s brain as they stumble through the code.
When you find yourself confronted with a long lived, poorly defined project, start asking questions:
- Was there a time element to the project, and has it passed?
- Have the assumptions behind the project changed?
- Have the company’s goals changed?
Was there a time element to the project, and has it passed?
Calendars are cyclical; it’s technically never too late or too early to get ready for your industry’s high volume period. But if you see a project to scale for Black Friday, in January, there’s a good chance that you don’t need to finish it.
Your company got through Black Friday without the project, why do you need it now?
Have the assumptions behind the project changed?
I have been involved with many “if we switch from technology X to Y, we can save a lot of money” type projects. Less than half produced significant cost savings. In most of the cases we knew that the savings wouldn’t materialize early in the project. The projects kept going anyway.
It is much easier to rationalize “the cost savings may not be there, but technology Y is better” than to work out if the new tech justifies the project on technical merits.
Have the company’s goals changed?
Long running, nebulous, projects run the risk of having the company’s goals change. I “increase performance” and “scale the system”. But when the customer profile changes, I am often scaling the wrong part of the system.
Learning To Question Is The First Step
Before you can stop a project, you have to question the project. Question the timing, the assumptions, and the company’s goals.
If the answers are no, it might be time to stop development.
