A balance sheet for projects

a guide to risk-based value--part 1


by John C. Goodpasture, PMP, and David Hulett


WOULDN'T WE ALL AGREE that every project is about delivering value to its investors? There's rarely an argument on that point, especially if we think of the project sponsor and the executive team as investors. Indeed, every deliverable, every project outcome, must be valuable enough to warrant investment of management's resources. But like all investments, projects deliver value within a prescribed limit of risk. The operative word here is prescribed. Obtaining this prescription at the project outset is key to aligning the investor's expectations and the project team's capability. The project team owes its investors an accounting for the value earned and the risks managed as resources are consumed, much like the business as a whole must report periodically to its owners about the returns earned on the owners’ investment. In this article, we look at the concept of a project as a business decision to invest in an outcome. In Part 2 (coming in the June PM Network) we will consider some statistical techniques that give insight into the risks that investors accept when projects are approved for implementation.

Approving a project is really a business decision to invest in a project, and because it is an investment decision, the business leadership of the firm makes it. Of course, investors are not project managers. As a consequence, the investment expectations of management are often at variance with the realities of implementation capability. This variance is a fundamental source of risk, representing a misalignment of management need and project delivery capability. Questions to be answered: Why does this happen? Can the risk be quantified? And, what is the right risk response?

Business and Projects. However diligent management is about conveying the value proposition of the project and formulating the return expected from its investment, “business” is not often the language of the project implementation team. Is this a problem? It could be. A miscommunication of expectations could be one of the first risks the project team has to overcome. Management describes projects in terms of expected outcomes and what those outcomes will do for the business. Like all expectations, this is really the outcome desired weighted by the probability of success. Today, executives are demanding a high weight on success. And, we are describing values found in all types of projects. In fact, we need only to look to Robert S. Kaplan and David P. Norton's defining paper on the balanced scorecard of goals and strategies [“The Balanced Scorecard—Measures That Drive Business,” Harvard Business Review, January– February 1992] to see that business leaders commonly find value in four major categories: customer perspective internal business perspective, innovation and learning perspective, and financial perspective. In the customer perspective are found goals like new products, responsive supply, and preferred supplier. In the internal business perspective are goals such as manufacturing excellence. In the innovation and learning perspective are technology leadership and time to market. In the financial perspective are the traditional measures of cash, income, and return. It's commonly understood that expected project outcomes should flow down from the top-level goals of the organization, through strategy, directly to projects. This flow is shown in Exhibit 1.

Reader Service Number 029

Projects derive value from their support for strategy

Exhibit 1. Projects derive value from their support for strategy.

Executives view a project as a black box, but the project team has the white-box details

Exhibit 2. Executives view a project as a black box, but the project team has the white-box details.

In Exhibit 1 we see that valuable projects derive their business priority from their support for strategy. Thus, executives often find that they actually do not need to know the project implementation details in order to establish and appreciate the project's business value. As such, management can approach projects top-down. It's only a matter of project alignment with strategy and goals and a matter of deciding priority among competing projects.

On the one hand, from the top down, project details need only be known in the abstract, making the project a black box” to executives. How the project will come together internally is not as important as knowing, from the outside, what the outcomes will be and for what investment these outcomes will be achieved. This concept is illustrated in Exhibit 2.

On the other hand, the project is necessarily a “white box” to the project team. Team members know all the internal details of the work breakdown structure, tasks, skills, and deliverable specifications. Unlike business values and strategic priorities, which are often qualitative and sometimes subjective, objective “facts” specify the white-box project solution. Facts include things such as how fast vendors can deliver on parts, subassemblies, or services; how much capital budget is needed for new plant and equipment; what performance can be achieved with readily available technology; or, more speculatively, what new “physics” are needed to achieve the project objectives.

But the management team often maintains a certain indifference to the “undeniable facts,” often to the frustration of the project manager. The management team wants only that the project team understand the business imperatives that cause constraints to be imposed and that a project of X magnitude delivering Y capabilities has been decided.

Obviously there is a dilemma here: Undeniable facts may not always be in balance with business decisions and management expectations. We need a third element to create balance and stability.

We assert that this element is risk. Risk balances the expectations and demands of business with the realities of project capability. Haven't we all been part of negotiations to get the project “close enough” to the “minimum” business goals so that each team—the project team and the management team—can accept the risk of going forward? This is, in effect, prescribing risk as part of the project specification.

So, we have three parts to deal with: the expectations and investment requirements of management; the constraints of cost, schedule, quality, and resources; and the risk that balances their differences. Conceptually, this is all we need to create a project balance sheet.

The Project Balance Sheet. The project balance sheet is illustrated in Exhibit 3. Just as in the familiar two-column balance sheet used in business financial statements, where the firm's assets, liabilities, and retained earnings are listed, there are three variables on the project balance sheet.

On the left side is the value proposition of the project, as represented by the firm's investment. Typically, this would be documented in the project charter. From Exhibit 1, we have seen that the value proposition is derived from the organization's top-level goals and strategy. Projects are commissioned to implement strategy. As such, the value proposition usually includes components from all perspectives of the balanced scorecard.

On the right side are the quality and cost-schedule-performance estimates developed during the planning phase, and documented in the project plan. Opposing arrows in Exhibit 3 convey the idea of competition between management's top-down approach to setting need and the project team's bottom-up approach to estimating delivery. Almost always, these two are not equal; for whatever reason, the expectations of management often go beyond what the team has the capacity to deliver. Or, stated in another way, to meet management expectations the project team needs more resources, more time, or a performance breakthrough to meet the investment objective. But more often than not, more is not available.

Reader Service Number 096

Also on the right side, risk provides further balance with the left side. Rather than more resources, the project team takes on risk. How much risk? Well, this is a matter of planning, quantification, and negotiation, but certainly no more risk than is required to balance inequalities between top-down expectations and bottom-up estimation of capability. It's also a matter of recognizing a principle from system engineering that is in play here: Risk is the “dependent” variable; it is derived from the imbalance between the left side and the project estimates on the right side. The risk is as great as it needs to be in order to achieve balance.

Like its counterpart in accounting, the project balance sheet provides double-entry accounting necessary to understand and appreciate the trade-offs among the three components. An entry on the left requires a compensating entry on the right in order to maintain balance. Continuing with the financial metaphor, value on the left side is “financed” by project resources and a prescribed limit of risk. Changing the value expectation changes the “financing” options: project resources may be changed, or more or less risk may be taken. Since a balance sheet conveys equality of the left side with equality on the right side, it can also be expressed as a linear equation. Thus, we assert that the accounting equation of Assets = Liabilities + Retained Earnings is much like the Project Equation:

Top-Down Business Value = Bottom-Up Implementation Estimate of the Project + Project Risk.

Who manages the balance sheet? Certainly, the left side belongs to the executives who chartered the project. The right side is the project domain, so we assign the right-side risk management to the project manager. This is an important point. For the risk prescribed in this equation, the project manager is the risk manager. The executive team is not in charge of managing this element of risk. In reality though, there is uncertainty on both sides of the project equation. Neither corporate management nor project management has sufficient scope and influence to absolutely ensure that the project earns its hoped-for value. Each has to manage the risk and uncertainty in its sphere of influence and rely on the other to manage the risk that is outside its direct control.

Risk balances value with capacity

Exhibit 3. Risk balances value with capacity.

The investors, that is, the management team, manage the risk to business benefits over the operating life of the project deliverables. Even if the project performs as well as desired, the business benefits may not materialize. This “value risk” will be discovered only after the project is complete and long after the project manager has moved on to other efforts. Therefore, the mission of the project manager flows from the project equation: The mission of the project manager is to ensure that the project earns the value expected by investors, taking measured risks to do so.

The project manager must manage to achieve value but also must manage to contain the risks built into the project equation. To succeed in meeting these two management objectives, the project manager needs two important tools in the project toolbox: a means to measure value accomplishment along the way and a means to deal quantitatively with the uncertainties of risk. Earned value systems are a good tool for the value measure; these and other performance measurement tools are described in the PMBOK® Guide and elsewhere.

WHAT HAVE WE LEARNED from Part 1? Of importance is that:

Projects are valued top-down by management, who think of themselves as investors. The project details are often not of interest; only the outcomes.

Projects are estimated bottom-up by the implementing team. These estimates are usually independent of the top-down valuation of the project. They rarely equate.

The project is made acceptable to both investors and implementers by recognizing that some compromise, in the form of risk, balances the two points of view. The project balance sheet is born from the need to compromise.

The project manager is the one tapped to manage the risk and the project. The project manager's mission is to deliver the value expected by the investors, and it is the project manager's task to defeat the quantitative predictions of risk analysis.

Next month, in Part 2 of this article, we will take up quantitative risk analysis. ■

John C. Goodpasture, PMP, has 26 years of experience in project and program management. He is vice president for Professional Services Operations, Lanier Worldwide Inc., a company specializing in document management solutions.

David Hulett, Ph.D., is president of Hulett & Associates of Los Angeles, Calif. He consults and trains in project management disciplines, including risk assessment and management, cost estimating, and project scheduling.

PM Network May 2000



Related Content

  • Right on time, right on money--personal experience member content open

    By Klein, Tom One of the most effective ways to learn about the challenges and dynamics involved in managing projects is to study cases of implementing actual projects. This paper examines the author's experience…

  • Six (yes six!) constraints member content open

    By Siegelaub, Jay M. Project professionals have long recognized cost, time, and scope as the constraints influencing a project's outcome. Prince2 has expanded this list to include quality, benefits, and risks. This…

  • Lessons learned from risk situations in projects member content open

    By Alves, Roberto Antônio Over the past fifteen years, Brazilian companies working on industrial projects--primarily within the mining sector--registered more than 300 risk situations. This paper synthesizes these situations…

  • Project termination member content open

    By Sohmen, Victor The final termination date of the typical project has a tendency to be somewhat later when formally commissioned than that projected during the pre-execution segment of the project life cycle. A…

  • Seminars & Symposium

    Configuration management member content open

    By Canepari, John E. Configuration Management addresses the need for establishing a methodology to control the various elements of the change and validation processes. The general definition of Configuration Management…