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?
Applying the Business Case
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:
Phase One: Defining the Project
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.
Phase Two: The Go/No- Go Decision
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:
- Is the business need clearly stated and in line with the organization's strategy?
- Have the benefits been clearly identified?
- Is it clear what will define a successful outcome?
- Is the preferred option clearly stated?
- Are there alternatives presented?
- Is it clear how the necessary funding will be put in place?
- Are the risks-and the plans for addressing the risks-explicitly stated?
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.
Phase Three: If Changes Occur
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.
Phase Four: Project Closure
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 realized 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.
Don't forget to leave your comments below
John Moore is a technical project manager working for Newton Software Ltd and specialises in projects involving data intelligence. He is a Learning Tree instructor and course author and editor. He can be reached at email@example.com Learning Tree International is a leading global provider training to management, business and information technology professionals. Since 1974, over 13,000 public and private organizations have trusted Learning Tree to enhance the professional skills of more than 1.9 million employees. For more information, call 1-800-843-8733 or visit www.learningtree.ca.