~ By John Moore
When projects fail to deliver results, ensuing conversations can often become accusatory. The division manager says,
Even with all the resources and money put into this new product, the quarterly numbers show that it's another loss. Plus, one of our competitors brought out an equivalent product before we were ready to launch ours.
The head of the department responsible for the project responds,
We did the job, delivered on time and stayed within budget. It's not our fault if the product didn't generate the money you expected.
The problem is…they're both right! But even with everyone doing their best, the results were disappointing, and the second-guessing begins. Were the business' expectations too high? Was the original scope of the project assessed correctly? And that competitor who introduced an equivalent product, was the possibility of that risk ever identified at either the outset of the project or during its life? If so, were those involved, stakeholders included, aware of the potential risk so measures could be taken to mitigate it? Or was it decided the team was just there to deliver a product and not manage external events?
Questions like those above are often argued once the project is over. Unfortunately, it's usually too late to repair the damage. That's why successful project teams take the time to consider such issues by building a solid business case at the inception of every project. This enables a team to address potential risks and plot alternative strategies while providing a tool for future variables throughout the project.
Once the business case has been developed, it is then applied at four critical phases in the project's life cycle in order to ensure that the project, once completed, will deliver the return on investment that was originally forecast.
An effective business case can contribute greatly to the success of a project during these four critical phases of its life cycle:
First, before development begins, the Business Case asks and answers the "why" of the project to document the justification for the initiative and how success will be defined. As cost estimates are gathered and incorporated, the stakeholders must identify the expected benefits of the project in measurable terms that will enable the organisation to determine if the project was (or wasn't) a success. These same estimated costs and anticipated business benefits also create a foundation against which any anticipated risks or uncertainties, such as the possible release of a competitor's product, can be measured. When gathering input, outside contributors such as personnel from the finance department, who can provide key input for forecasting the project's returns, should also be included.
Even at this early stage, it's not unusual for stakeholders to challenge the validity of the case's inputs, especially if they don't like what they hear. During this information gathering process, everyone involved must be willing to challenge the expectations of the business as related to cost and time. This is also the right moment for alternatives to be developed, each with their own cost, time and risk expectations. These provide a yardstick to measure the project against and potentially suggest better solutions for dealing with whether the project is viable.
After the input has been gathered, the business must make the decision whether to proceed with the project or not (go/no go). If the project is a go, then the business case will be used as the basis for decision making during the life of the project.
These are the key questions to ask about the business case at this critical point:
However, even after the project is initiated, the business case can still revisit the go/no-go decision, if changing conditions invalidate the why of the project.
After the business case is written and approved, it should be reviewed frequently. As the project progresses, the project's external environment may change, potential risks may become reality, new risks may come to light and new business decisions may directly impact the project. In some cases, the initial justification for the project, the why, may disappear. Consequently, the business case has to be re-examined continually as the content (especially the projected benefits) may be affected. It's also critical that all the stakeholders involved in gathering the initial inputs be kept involved to keep the case updated throughout its life cycle, especially during changes.
When the project is complete, it can then be viewed against the current business case. Only by comparing the project's results against the specified project why, can the degree of success be determined. However, it's important to remember that, while the project can be assessed immediately upon closing, many benefits may only be realised after the solution has been "live" for a period of time.
Ultimately, building a business case before beginning any project is a matter of common sense: it's not enough to just do something right, first you need to know why you're doing it.
John Moore is a technical project manager working for Newton Software Ltd and specialises in projects involving data intelligence. As a Learning Tree instructor, he teaches Course 212, "Building an Effective Business Case", and Course 315, "Developing User Requirements." He is the author of Course 921, "Recovering Troubled Projects", and technical editor for Course 938, "Contract Management Introduction" and Course 916, "PRINCE2® in Practice. He can be reached at firstname.lastname@example.org
Learning Tree International is a leading global provider of truly effective training to management, business and information technology professionals. Since 1974, over 13,000 public and private organisations have trusted Learning Tree to enhance the professional skills of more than 1.9 million employees. For more information, call 0800 282 353 or visit www.learningtree.co.uk