It’s a well known fact that IT projects fail every so often. Standish Group has been researching the success and failure factors of IT projects for a decade and a half, and they publish their results in their CHAOS report every two years or so. According to their 2006 report, only about 35% of projects can be categorized as successful, while 65% are declared unsuccessful. In this report, word unsuccessful can mean anything from exceeding time and/or budget (46% of projects) or failing altogether (19% of them). With such a huge proportion of projects going astray, maybe there was something wrong with these projects from the very beginning. Were the time and budget unrealistic? Were the project requirements, or even objectives, unrealistic? Maybe. Or maybe not. How can you tell?
Obviously, with such a huge non-success rate, engaging in an IT project is playing against the odds. It’s not swimming up the stream, it’s not rowing up the Niagara Falls either, it falls somewhere in between. When you start an IT project, it’s more likely it will either burn much more money than you planned, or go down outright.
Did you ever wonder how many projects start with a business case? I did. I still do. Majority of projects I ever saw didn’t have anything close to a business case. How do these projects start, then?
This quotation from Lewis Carroll’s Alice’s Adventures in Wonderland pretty much explains that situation:
Many projects simply start with a business need. So you have a business need. Does this mandate a project? No. Many projects start with an RFI (Request For Information) or RFP (Request For Proposal), which demonstrates that someone has given the project some thought beforehand. This is a good start. But not good enough.
Before a project is initiated, a few questions should be asked:
Of course, there are dozens of other questions, but these will do to build something that is called a business case.
A business case is a document which explains why you start a project, what you will focus on with this project, what will it cost you to proceed or not to proceed with it, what you will get out of it. It will help you understand the scale of your investment, and also understand what kind of return you can expect, and when.
Some would argue that business case is equivalent to a project charter, another kind of document that is often skipped altogether. While there are a lot of touching points between a project charter, and a business case, I believe these are two different beasts.
Where I see the distinction is that a business case should be focused on explaining the value proposition of a project, and give the executives an understanding of what benefits will it give to the business, or sometimes even why it should be better not to proceed with it at all, while project charter is a document that gives an overview of a project, then gives authority and resources to project management team (or individual) to proceed with the project and burn the allotted money. Business case is an introduction to project charter, in my opinion.
In any case, business case is an important step in project initiation, and too bad it is so often overlooked.
Other Microsoft Sites
I'm a Customer
I'm a Partner
Use the official Twitter tags:
#MSDYNCOMM | #CONV13