Introduction
The classical definition of project success centers on achieving results on time, on budget, and producing the agreed deliverables: the triple constraints of time, cost, and scope. Yet, over the past decade there has been a growing recognition that creating the requested deliverables does not ensure “success.” An increased emphasis on results has brought businesses—and non-commercial organizations—to focus on the “value” projects bring to the organizations that commission them. Not just “what did you build” but “did what you built justify the investment in the time and resources to create it.” With a sputtering world economy, an organization cannot afford to spend limited resources without assurance that it has used those resources wisely.
The formal name for this justification is “Business Case.” While the term “business” is used, the concept is as relevant in non-commercial environments—governments, not-for-profits, NGO's, etc.—where it may be known as a “case statement” (or similar terminology).
Why We Do Projects
Projects are done to fulfill business/organizational needs. The organization has some “problem” it needs to solve, so a project is initiated to resolve that situation. It might be a new initiative, an extension of existing operations, adding a new product to an existing product line, or something that needs fixing.
When the development of a project focuses on its deliverables, the implication is that as long as the project creates what was asked for, it has been successful. If and how the outputs are used is of no specific concern of the project team. This is an extension of the idea that project delivery is primarily a technical operation (hence, the common assumption that the ideal person to lead a project is the one with the most technical knowledge of the content).
The organization wants to see results—have the problem solved—so it can move forward and deliver its strategy. Having an “elegant” technical solution does not help the organization if the products are not used to deliver the expected benefits.
PRINCE2™ (the internationally recognized project management methodology) identifies these key elements of a project that support benefits delivery:
• A project's output is any of the project's technical deliverables (whether tangible or intangible)
• An outcome is the result of the change derived from using the project's deliverables
• A benefit is the measurable improvement resulting from an outcome that is perceived as an advantage by one or more stakeholders (PRINCE2™, 2009 edition, Section 4.2.2)
Here is an example:
Output: A new production plant is constructed and brought into operation.
Outcome: More of the company's products can be manufactured in the same time period.
Benefit: The company can deliver more products to its customers, and sales revenues increase by 20%.
The ultimate goal is to increase sales—so the construction of the plant, by itself, delivers no value to the organization. It is just a building filled with equipment. If the organization were unable to use it (or if it no longer had a need for it), then it would sit there as a big expense with no counterbalancing income derived from it—even it were built perfectly according to specifications!
With these elements in mind, the project manager's role must go beyond managing a technical development effort. If the primary purpose of the project is to deliver value, then the project manager's role is to help ensure that value is delivered. Clearly, the project manager does not have control over many factors that contribute to the successful use of deliverables—for example, the people who will define what the value is; or those who will actually work with the deliverables; or those who have to make sure the deliverables operate properly. But the project manager is responsible for helping to keep all parties—especially those paying for the project, those who have to use the deliverables, and those doing the development work—focused on this expectation.
The project manager's role must go beyond “creating the correct technical product” and become “delivering a solution to the organization.”
Why the Organization Needs a Business Case
If a project is commissioned without consideration for the value it will deliver (i.e., without a Business Case), a number of serious problems can arise:
(1) The organization wastes valuable resources on projects that don't help the organization achieve its objectives. This leaves fewer resources available for more valuable projects.
(2) The organization has no clear basis to prioritize projects, for establishing what is important. Without a Business Case—and some organization-wide agreed measure of “value”—there is no means of determining which projects are important, and which are less so. Many organizations use “the loudest voice” approach, in which the managers who yell the loudest (or who have more influence, or are more intimidating) get what they want—even when their projects have no relationship to the organization's objectives! The organization needs a more rational and effective means of allocating its limited resources. Without this the organization's strategy languishes with no clear assurance that the strategy is being progressed by any particular expenditure of resources.
(3) There is likely to be disappointment after the completion of the project, as the stakeholders wonder why the project is not giving the great results they imagined—very likely because the project manager didn't know what those expectations were, or was focusing predominantly on what was being built, rather than on how it would be used.
(4) No target is established for why the project's deliverables are being created—other than the meeting of technical specifications. This allows the project team to get over-engaged in technical details, losing sight of the goals of the project. At project completion there is no clear way of determining whether the project delivered value. Both occur because no benefit goals were established before the project began.
(5) The organization has no opportunity to improve its project management maturity. One key learning from each project should be: “how well did the resource usage support the organization's goals?”
How Does a Business Case Work?
The Business Case is a reference point before, during, and after a project.
As the project begins the Business Case establishes the ultimate goal of the project for all stakeholders—including the project manager and sponsor. There are invariably concepts in the minds of the key project participants of what they expect the project to accomplish. Creating the Business Case draws the discussion from “What do we want to build?” to “Why do we want to build it?” This provides the justification for starting the project. A written and agreed Business Case makes those expectations explicit. If there is lack of understanding, or disagreements over those goals at initiation, it is far cheaper to resolve them now, rather than after valuable resources have already been expended. (Quality reminds us that it is more economical to prevent this problem than fix it later.)
As the project progresses, the Business Case becomes the “guiding light”—the beacon toward which everyone knows the project is directed. It will often help inform the project manager as to which approach to take when alternative technical options present themselves. With a clear Business Case the project's stakeholders can monitor both the project and the project's environment to determine if the project continues to makes organizational sense.
After the project is completed—after the deliverables have been applied and are in use—the Business Case becomes the measure to assess how well the organization did with its planning and implementation. This is the learning linchpin for organizational improvement, for at that point we can ask: “did the project deliver the value we anticipated?” If it has, it is likely because the project management team (project manager, sponsor, key stakeholders) kept its focus on that value. If not, then there are critical organizational lessons to be drawn from the experience:
• Did we incorrectly estimate the expected benefits?
• Did we develop all the associated deliverables that were really needed to provide the expected value (e.g., did we roll out a new technical product, but didn't supply enough help or training support?)
• Did we develop the wrong deliverables?
• Did we get too caught up with the technical aspect and not make the deliverables usable enough to deliver the value we wanted?
• Did something happen within the project or the environment that we should have taken into account?
There are many other questions that can be explored—but none of them can be answered intelligently without a referent Business Case.
Business Cases Are Good Business/Organization Practice
In an article on “Broken Promises” (PM Network, February, 2006) it was noted that “Success [for Boards] is increasingly being defined as achieving the promised benefits, as opposed to the traditional focus on time and budget measures. The ‘promised benefits’ [the source of the title ‘Broken Promises’] refer to the ability of completed projects to deliver the intended specifications: a certain level of process improvement, cost savings, productivity gains or some other business goal.” The article adds “results indicate that while companies are delivering some value back to the organization, benefits are being leaked away. Without a sound program management function, project costs overrun, timescales slip, and the planned benefits lose their focus.”2 Organizations are looking for more than deliverables—the planned benefits must be defined as part of the project's Business Case. The Fourth Edition of A Guide to the Project Management Body of Knowledge (PMBOK® Guide) now takes greater notice of the Business Case (4.1.1.2 Business Case) but does not yet expand its explanation and discussion to take full advantage of the value of a Business Case to the project and organization.
A Business Case can take many forms. The following are several examples:
• ROI (Return On Investment): Spending time and money in development is expected to deliver far more money than went into the project.
• Strategic: The project supports the Organization's Strategy and/or Mission (which may not always be about short-term, or dollar-for-dollar returns).
• Investment: Developing new products in the laboratory, for eventual (“we hope”) expansion into money-making products.
• Values: This is a variation on Strategy/Mission—where the organization's social values are agreed, as part of the corporate culture, to be one of the organization's common expectations and goals.
• Research: “We'll probably lose money on this project, but we will learn a lot that will help us set the organization's future direction.”
• Efficiency: A variant of ROI, the project is done to improve the organization's operational processes.
• Compliance (Regulatory/Statutory/Fiduciary): A project is required for the organization to comply with external regulations.
What Does a Business Case Look Like?
A Business Case defines the value a project will deliver. Costs and benefits are key reference points, but other elements contribute significantly to presenting a solid and coherent Business Case. This section proposes its core contents, remembering that this is a key driver for the project as a whole, and will be vital to guide the project governance team (project sponsor and decision-makers) in making go/no-go assessments.
It is common to think that a Business Case is fixed, and should not change during the project. In fact, virtually every section of the Business Case can change. Hence, the sections of the Business Case have to be reviewed regularly (and updated as necessary), so the key stakeholders have up-to-date information to determine the project's viability. As it is dynamic document, it is the responsibility of the project manager and the owner of the Business Case (usually the project's sponsor) to regularly monitor those elements to determine if the justification for the project has in any way been diminished (“should the project be stopped or reduced in scope?”) or enhanced (“would it be worthwhile to invest more resources to deliver this project”).
Additionally, a good Business Case contains more than the specifics of the particular project. It also contains the context for the project. The context provides an account of the “operational environment” in which the project's value is defined. If external forces change that context, then the foundation upon which the Business Case is built may no longer support the need for the project itself. Thus the context too may change during the project, and alter the justification for doing the project. If the context is omitted, the project may continue along, oblivious to the fact that it may not longer be relevant or viable.
Business Case Contents: The Basics
Reasons
| What it is | Why the project was considered in the first place—its context. The problem or situation that initially led the organization to consider doing this project; the project's background. |
| Why it is needed | To understand the context of the project. |
| Source | The business requesting the project. |
| Why it might change | The original circumstances can change or disappear, indicating that the project is no longer necessary, or point to a better option that was considered. |
Options
| What it is | The possibilities that were considered in response to the problem statement (Reasons), and their anticipated results. Always includes “Do Nothing”, the minimum that could be done in response, and other possibilities. Indicate which option was selected (i.e., this project), and why it was selected. |
| Why it is needed | To understand the options that were considered, and why this project option was chosen over the alternatives. |
| Source | The business that requested the project, often via a feasibility study that came up with these options. |
| Why it might change | Elements of the options that were not selected can change (e.g., lower costs, higher quality, changes in the business environment), making a formerly less attractive option now more attractive than the option originally selected. |
Benefits and Dis-Benefits
| What it is | Benefits are the expected value to be delivered by the project, measurable whenever possible. Dis-benefits are negatives to the organization, and the project would want to minimize them. This section should also include: (a) The level of benefits expected (measureable/quantifiable whenever possible); (b) The timescale within which the benefits are expected to be realized (and when the benefits should be measured); (c) Any range of acceptability of a particular benefit (e.g., “we are looking for a return of between 18% and 22% on our investment”); (d) How the project will plan and help assess whether benefits have been realized (this should be documented in a separate “Benefits Review Plan”). Expected benefits should be tied to organizational strategy. |
| Why it is needed | These are what the organization ultimately wants to get out of its investment. Not just deliverables—but deliverables that are used and deliver value. This is a distillation of what the organization wants to happen (from the sponsor), and what the project can realistically deliver (from the project manager). |
| Source | The business proposing the project, supported by information from within the project. |
| Why it might change | They can increase or decrease—affected by external circumstances (e.g., a competitor coming out with a better product), or internal factors (e.g., technical, cultural, legal) that limit what the project can deliver. |
Timescale, Costs
| What it is | Minimally, the time and costs to bring the project to its natural conclusion; would include intermediate figures that might impact project success. It may also include operational and maintenance costs to bring the outcome to the point at which the benefits will be realized. |
| Why it is needed | These (along with risks and other factors) have to be balanced against the expected Benefits to determine if the project is worth starting or continuing. |
| Source | The development and maintenance of the project's schedule and resources (actual and projected) from the project management plan. |
| Why it might change | These figures are constantly changing during a project. If revised figures are out of line with original expectations, the project may no longer be viable. |
Major Risks and Opportunities
| What it is | The major threats and opportunities to the project. |
| Why it is needed | They could endanger (risks) or enhance (opportunities) the likelihood of the expected benefits being achieved. The weight of risk, the cost of mitigating them and the level of management's risk tolerance could render a project not viable. |
| Source | Project manager (internal), sponsor, and key stakeholders. |
| Why it might change | Risks and the costs to mitigate them are in constant flux, and changes in their circumstance can cause a project to lose its viability. |
The project's sponsor and stakeholders will take into account all the above elements in determining whether the Business Case has viability. Some of these elements will naturally evolve with the project—particularly time, cost, and expected benefits. Before the project planning effort begins, time and cost are broad estimates. With the creation of the project management plan, these elements will be solidified upon more detailed investigation. However, it is only during the execution of the project that the true costs and timescales (actuals) are determined.
The benefits follow the same learning curve: broad estimates at first, then a greater sense of real possibilities during planning and as the project progresses.
The true cost and time are only known after the completion of the project if operational and maintenance costs need to be considered. Similarly, benefits can only be assessed after some period of use (as defined in the Business Case).
Assessment and understanding of major risks is critical to the evaluation of project viability. While it may seem that any one risk may be tolerable to the sponsor and stakeholders, the aggregate of the major risks (both threats and opportunities) have to be balanced against the benefits that the project is expected to deliver. Those risks change constantly, and so that section of the Business Case needs to be updated as well.
The Benefits Review Plan
PRINCE2™ (2009 Edition) suggests that a Benefits Review Plan should be developed along with the Business Case. It should be updated as the project progresses, and eventually becomes the “instruction manual” for performing the benefits assessment—determining whether the identified benefits have been realized. Such a plan would have (minimally) the following components:
• Benefits to be measured (drawn directly from the Business Case);
• Accountability for measuring them (Who is accountable for doing the assessment—and who is accountable for delivering those results to the organization);
• How benefits will be measured (What are the measures? What how will they be calculated? What information will be needed to do those calculations?);
• When the benefits should be measured (When will the assessment take place? How is that related to when partial and/or full benefits are expected to be realized?);
• Who the resources are that will carry out the review (Who will perform the assessment? How will we make sure that resource understands what is being done, and has the proper skills to do the job?);
• Baseline measurements from which the improvements can be calculated (What is the reference point for comparison? Will that information be developed as part of the project, or is it already available?);
• How performance of the key deliverables will be reviewed (How the “outcome” will be evaluated).
The Foundation for Project Success
The Business Case sits at the heart of the project. It outweighs the technical objectives, which only exist to deliver some defined value to the organization. Developing and maintaining a solid Business Case will help ensure that (a) all parties will have a common understanding of the value the project is intended to produce; (b) the organization will have a clear, ongoing basis for determining whether the project is worth continuing; (c) resources are used effectively (on the right projects); (d) priorities are clearly established for the project manager and the organization; and (e) there will be a clear basis (through the Benefits Review Plan) for assessing project success. Working with a Business Case does not require a business degree—but it does call on the project manager to be more attentive to what the organization is seeking to accomplish through the project. When a Business Case is planned and managed effectively, it dramatically increases the likelihood of the project's success—in the minds of all project parties.
