Blog

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:

1. What are the objectives? What are we trying to accomplish with this project? It is important to articulate the objectives as clearly as possible. When objectives are not clear, you can expect them to shift several times during the project, because somebody at some point will suddenly remember that something else should also be done. This can sink a project like a paper-boat. You should collect the requirements, document them, then evaluate them and prioritize them. Then you can articulate the project objectives. To implement an ERP system (or whatever your project is about) can’t be an objective in itself, it can come in support of an objective. A valid objective would be to establish control of the flow of goods through inventory, or to implement processes which would result in decreased costs of production.
2. What is the expected outcome of the project? To put it simply, it is how we intend to meet the objectives, what the results of the project will be. This can be an ERP system, or something, but it is crucial that you match it with the objectives. If you simply want to implement an ERP system, then you are much alike Alice, you will get somewhere eventually, you’ll sure walk long enough before you get there, but where exactly you will end up, or when, you can’t predict, nor you can forecast any resources you will burn in the process.
3. What are the benefits? What good will this project do to us? Try to quantify these, then express them in financial terms. It is crucial to get these figures down, because without them, it’s hard to calculate the return. We will reduce bottlenecks in production by 40%, which will increase total throughput by 25%. We will increase the warehouse efficiency by 34%, which will allow as to accept 15% more sales orders while cutting inventory levels by 18%. It’s not easy to estimate these figures, but it’s a great deal easier to do so if you get the objective straight, then if you don’t. You also need to analyze existing processes, identify pitfalls and opportunities of improvement. Then you can estimate the benefits. But without benefits estimated you can’t know for sure whether it pays off to start a project or not. If you implement a 10 million dollar behemoth of a system to help you save a half a million a year, you must face the fact that you might never get the invested money back.
4. What are the costs? We would all like to keep the costs down, but estimating the costs might be a tricky bit of job. Be realistic. Getting from New York to Boston on foot in two hours can’t be done, period. Many projects simply allocate too tight a budget and too ambitious objectives. They might eventually meet them, but hardly ever at the estimated costs. To estimate costs, you must know the requirements, you must know the outcome of the project. And bear in mind that costs are not just licence fees for new software, or consultancy fees. Costs are also the costs of your own people you will allocate to the project, who won’t be able to perform their normal job duties, or will be able to do so to a limited extent. Estimating costs is as important as estimating benefits, because these two are required variables in the equation which will tell you your ROI.
5. What are the risks? What will happen if you don’t proceed with the project? Will you fail to comply with regulatory requirements, will your business collapse, or nothing will truly happen. It might sometimes be a case that you will still be able to go on with your normal business, even if you don’t proceed with the project. If there are no risks forcing you to proceed, costs are high and benefits unclear, there might be no point proceeding.
6. Has anyone done this before? If you are implementing a system, you might be interested to know about other companies in your vertical following the same path. Did they succeed? Or did they fail? If so, why? While this might not be as important as all of the above, it will give you a reference point.

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.