It may seem very Ah-nold to manage a company that way, but killing a project is better than killing your company. From Valdocs (yes, I am that old) to the FAA’s almost killing us all with 12x over budget software - we all can tell stories, and we’ve all had a hand in real train wreck stuff.
What’s horrifying is that sometimes these are mission critical implementations. I saw a startup literally go out of business when they released Version/2 and killed all the popular Version/1 features for ‘improved’ stuff. They went from 25 or so high use customers to 12 in a week and then down to 1 in three months. When the renewal came up they got exactly 0. They *were* converting pipeline-to-customers at slightly more than 2/month but failed to convert a single customer with the new version.
They were also unable to rollback, but we’ll talk about disaster planning some other time.
So when do you terminate a project? There are some warning signs - over budget, late, harder than you thought, market seems to have moved during development, etc, etc. A lot of that can be avoided by reading my partner’s article on Only Try To Predict The Near Future. But sometimes you have things that are just bigger projects.
Here are my top 10 signs that something dreadful is going wrong:
1> Words have new meaning. Does “completed test case” now mean “sorta can do it?”
2> People get sick more often than before.
3> Regularly scheduled all-hands release meetings.
4> All the humor is dark.
5> Features that seemed innovative are, well, boring.
6> Daily status emails at every level.
7> Current revenue sources declining.
8> More experienced people are sending CYA emails to their managers.
9> You squeeze the budget to hire extra staff to “get some momentum”
10> Release features start moving to “post-release incremental” and/or you have (my favorite) Release 1, Release 1A, ….
So, what do you do? You have to take a good hard look at the project and decide if it should be saved. Not does it have to be saved, but can it be saved. It’s like the stock market - you may have bought it at $20 and now it is at $16. The question is not: can you get your money back, but is it a good stock to own at $16. If not, then sell.
So with a project. Not can you save it but right now is this the right project.
Look, I’ve seen a lot of projects that were saved because management decided that they would re-resource and re-plan and re-commit to the project. Probably only a third of them should have had that CPR.
Conversely, I don’t think I’ve ever seen a scuttled project that shouldn’t have been.
Would you like a personal example?
I once worked on a small team that built an object oriented database library. We were part of a startup using extensive OO tech (back when that was tricky). The entire development organization needed our library to work in order to go live with our production code. We were behind, working too hard, having too many emails, etc, etc. (See the above list - we got 6 of ‘em!) My manager at the time, took us offsite for two days (no computers, no email, no nothing) and we did exercises to see if there were any options, could we start over and delay the project launch for the whole company for three months, etc, etc. In conclusion we decided to do something much simpler and bring in another very good coder from the architecture team who was familiar with what we were doing. We ended up getting our stuff working 28 days after deadline. That was smart management.
Stupid management: A client, lo these many years ago, had a one year project that was in its second year. They brought me in “to get things moving again.” After three weeks of seeing 5 of the top 10 above, I took my client’s CIO aside and had a frank talk with him about the project. Frankly it was no longer required for the company and it was darn expensive. But it was less embarrassing to leave it running (without me, of course, I was replaced the next week) than to terminate it. The CIO was fired at the next budget cycle. Of course.
It’s even more important for a startup, because we don’t have the resources of a Dow ($2.3B ten year SAP implementation!) to have these kind of project issues. If you’re rolling out a new tool and it’s taking too long, or maintenance on existing tools is slipping, or your guys are in perma-grouse mode, or you’re suddenly having big-company style status meetings in a startup, then maybe you need to take a look at terminating the effort and re-focusing.
