Whilst teaching an IT architecture class in Moscow this week I was asked the above question by one of the students. The question was in relation to projects and when you should realise the project is not going to deliver and should therefore be cancelled rather than carrying on regardless. I hate using the phrase “it depends” in answer to a question like this but this was one case when that’s all I could think of! However, having had a bit of time to reflect on this (on a long journey back home) here are a few thoughts that I’ve had since then. This is also related to my previous blog entry.

In some ways working on a software delivery project is a bit like fighting a war (though admittedly you don’t usually risk losing your life). In a war you may not win every battle and may sometimes need to retreat and reconfigure however, the important thing is to focus on the strategic battles that will lead you to get to the overall objective (and win the war). In a software delivery project winning the war is to successfully deliver the system or application on time and within budget. The battles are what the architect and project manager must fight every day to address the technical and other issues which arise and must be overcome for fear of letting the project get out of control. So what are the battles, which if not won, are going to cause the project to fail and, more importantly for this topic, will lead to surrender if the cost gets too high? Here’s my top five in order of importance:

1. No, or poor, sponsorship.If there is no clear (and strong) sponsorship from the right level in the enterprise then you may as well pack up and go home immediately. Even if the project does get to the delivery stage the chances are no one will really want or need the system. The job of the sponsor is to evangelise, convince and cajole a sometimes reluctant workforce of the need for the new system and the change that it might bring about. Weak sponsors will be unable or unwilling to do this.
2. Not having a water tight business case.If the business case for why the new system is needed is not well thought through with a clear cost-benefit analysis then there is a danger that the project could be cancelled at any time. I once worked on a project that was cancelled days before we were due to exit system test because a review of the business case revealed a flaw in the return on investment (ROI) of the new system so the client decided to pull the plug on the project rather than deliver something that would not make the cost savings that were expected of it. Painful but probably the right decision!
3. Not engaging all stakeholders. Not identifying and engaging (i.e. talking to, convincing, schmoosing, wining and dining or whatever it takes) all the stakeholders is a bit like death by a thousand cuts. Although you will start off well, entropy will gradually set in and and things will start to fall apart. Stakeholders who should have been informed early on will learn about the project through the grapevine and will not only not support it but may actively try to kill it. They may see it as a threat or may treat it as sour grapes, “no one bothered to tell me about it so why should I support this”?
4. Underestimating the complexity of building interfaces to legacy systems. Very few projects have the luxury of a clean sheet of paper when starting out. There is nearly always some old, creaking legacy system that needs to be interfaced with, even short-term or temporarily. In my experience one should never underestimate the complexity of these legacy system interfaces. And I don’t just mean technology interfaces. Many times IT departments will see it as a threat to their existence that what starts out as an interface may ultimately lead to a complete replacement of the system that they run and manage so lovingly and will therefore do whatever they can to derail the project.
5. Not having regular and viable releases of the system/application. Gone are the days when a project could go off for many years before delivering anything of value to the key stakeholders (or I hope they have). I cannot emphasise enough the importance of delivering something of value that users can get their hands on and starting using that will give them some business benefits. This not only shows them the value of the new application but also gives them a belief that IT can actually deliver stuff and will also get them to “buy-in” to the new system and may well have the useful side-effect that they become sales-people for the new system and will convince colleagues of its benefits.

I believe that if one or more of these issues exist on your project you should either take very serious steps to address them or consider looking for another job because there is a greater than 50% chance everything is going to get very messy and is going to end in tears or much, much worse.