Skip to main content

Building a Business Case as the Foundation for Project Success

BusCaseAsFoundation1When 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?

Applying the Business Case

Questions like these 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.

Expert Advice from Today’s Top Professionals

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 organization 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 should also be included, such as personnel from the finance department who can provide key input for forecasting the project’s returns.

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 alternatives 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 specializes 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 [email protected]

Article courtesy of Learning Tree International, a leading training provider for Managers and IT Professionals.