A Framework for Value, Risk, and Capability: The Project Balance Sheet

A Framework for Value, Risk, and Capability: The Project Balance Sheet

Over a number of years of working with project teams and executive sponsors, this author has conceived and evolved the concept of the project balance sheet. [12], [13] The project balance sheet is a conceptual and quantitative model suitable for relating business value with project capability and risk. To this point, we have discussed three well-known models of business value and customer expectation. Now it remains to couple these models to projects. Coupling to projects also provides a means to relate the numerical expressions of business value with the numerical measures of project capability and performance.

We begin with this premise: project sponsors and business executives who charter projects and invest in their success have an expectation of results, more often than not results that exceed the project investment, and for these investment gains, they are willing to accept some risk. These expected results support directly the goals and strategies that back up the value models we have discussed.

Project managers, on the other hand, accept the charter as their marching orders, developing a scope statement and an estimate of resources that corresponds. Now it often comes to pass that the project manager discovers that the available investment comes up short of the resources estimated, given that the full scope is embraced. Negotiations begin, but in the final analysis there usually remains a gap between capability and capacity on the project side and the value imperatives on the business side. What to do? The answer is: take a risk. How much risk? Only as much risk as is necessary to balance business needs and values on the one side with project abilities and needs on the other side. Who takes this risk? The project manager; the project manager is the ultimate risk manager. [14]

Financial Accounting

An understanding of balance sheet math is needed in order to proceed. For project managers not familiar with the balance sheet idea from the domain of financial accounting, here is a quick overview. First, the balance sheet is nothing more than a graphical or tabular way to show a numerical relationship: y = a + b. However, this relationship is not functional since all three of the variables are independent and, because of the equality sign, a relationship exists among the three that makes them interdependent as well. Thus, a change in one requires a change in another to maintain equality among the three. This equality is called "balance" in the accounting world, and the process by which if one variable changes then another must change in a compensating way to maintain balance is called "double entry accounting."

Second, accountants would understand the equation this way: assets ("y") = liabilities ("a") + equities ("b"). That is their "accounting equation." If assets increase, then so must either or both liabilities and equity increase in order to maintain balance. In fact, any change in the variables must be compensated by a change in one or two of the other two variables.

There is an important business concept to go along with the math: assets are property of the company put in the custody of the company managers to employ when they execute the business model. Assets are among the resources to be used by project managers to execute on projects. Assets are paid for by liabilities (loans from outsiders) and capital, also called equity. Equity is the property of the owners and liabilities are the properties of the creditors of the company. Thus, some stakeholders in the project arise naturally from the accounting equation: the financiers of the assets! As noted, these are the suppliers (accounts payable liabilities), creditors (long-term and short-term notes), and owners or stockholders (equity owners).

An asset cannot be acquired — that is, its asset dollar value increased — without considering how its acquisition cost is to be paid (increase in liability or capital, or sale of another asset). An asset cannot be sold — that is, its dollar value decreased — without accounting for the proceeds. Typical assets, liabilities, and equity accounts are shown in Table 1-2. A balance sheet for a small company is shown in Table 1-3.

Table 1-2: Balance Sheet Example


Liabilities and Capital Employed

Current Assets

Current Liabilities

Cash on hand


Vendor payables




Short-term notes


Finished inventory



Work in process



Long-Term Assets

Long-Term Liabilities





Software and equipment



Supplier loan



Equities or Capital Employed


Capital paid in



Retained earnings



Stock ($1 par)


Total Assets

Total Liabilities and Equities





  • Cash on hand is money in the bank.

  • Receivables are monies owed to the business on invoices.

  • Finished inventory is tangible product ready to sell.

  • Work in process is incomplete inventory that could be made available to sell within one year.

  • Buildings, equipment, and software are fixed assets that are less liquid than current assets. Software is usually considered an asset when the capitalized development, purchasing, or licensing cost exceeds certain predetermined thresholds.

  • The supplier loan is money loaned to a supplier to finance its operations.

  • Vendor payables are invoices from vendors that must be paid by the business, in effect short-term loans to the business.

  • Short-term notes are loans due in less than a year.

  • Mortgages are long-term loans against the long-term assets.

  • Capital paid in is cash paid into the business by the stockholders in excess of the par value of the stock.

  • Retained earnings are cumulative earnings of the business, less any dividends to the stockholders.

  • Stock is the paid-in par value, usually taken to be $1 per share, of the outstanding stock. In this case, there would be 98,000 shares in the hands of owners.

Table 1-3: Balance Sheet Accounts


Liabilities and Capital Employed

Current Assets

Current Liabilities

Cash in checking and savings accounts

Monies owed to suppliers

Monies owned by customers (receivables)

Short-term bonds or other short-term debt

Inventory that can be sold immediately


Long-Term Assets

Long-Term Liabilities

Overdue receivables


Loans to suppliers

Long-term bonds

Investments in notes, real estate, other companies

Overdue payables

Plant and equipment


Software (large value)

Cash paid in by investors for stock


Retained earnings from operations and investments

  • Current assets are generally those assets that can be turned into cash within one year. Some companies may assign a shorter period.

  • Long-term assets are less liquid than current assets, but nevertheless have a cash value in the marketplace.

  • The dollar value of all accounts on the left side must equal the dollar value of the accounts on the right side.

  • Current liabilities are generally those due and payable within one year. Some companies may assign a shorter period.

  • Long-term liabilities are less liquid than current liabilities, but nevertheless have a cash value in the marketplace.

  • Equity is the monies paid in by owners or monies earned from operations and investments. These funds finance the assets of the business, along with the liabilities.

Debits and Credits

Accountants have their own curious methods for referring to changes on each side of the balance sheet. Traditionally, assets are shown on the left and liabilities and capital are on the right. Dollar increases on the left side are called debits. Increases on the right side are called credits. Debits and credits are only allowed to be positive numbers; that is, one does think of recording a negative debit. Debiting an asset always means increasing its dollar value. To reduce an asset's dollar value, it is credited. No particular connotation of good or bad should be assigned to the words debit and credit; they are simply synonyms for dollar increases left and right.

There may be a question at this point. If negative numbers are not used on the balance sheet, how do we keep track of things that have balances that go up and down? Enter the "T" chart. We set up a "T" chart for a specific asset, like cash, defining both a right and left side on the cash "T" chart. (Refer to Figure 1-6 for an illustration.) We can then record all credits on the right side of the "T" chart and then net them with the starting balance and subsequent debits on the left side. Then, when it is time to compute a new balance sheet, we record the new net amount on the left side of the balance sheet for cash. "T" charts are not mini-balance sheets. They do not convey an equation. Their left and right sides do not need to balance. They are simply a recording mechanism, in chart form, for individual transactions, debits and credits.

click to expand
Figure 1-6: "T" Chart for Cash.

However, if cash has been credited, we also need a second change, a debit, on the balance sheet to maintain the balance. If cash is to be credited, then a liability must be debited (decreased) or another asset is debited (increased). For example, we could use the cash to buy an asset and all would be in balance. Again refer to Figure 1-6 to see how this is done.

Project managers in some companies are asked to review the monthly "trial balance." The trial balance is a listing of all the debits and credits recorded in a period. Naturally, they should balance. Of course, a debit or credit could have been made to a wrong account and the trial balance still balance. That is where the project manager can add value: by determining that all the project debits and credits have been applied to the proper accounts.

Here is an important point: balance sheets do not record flows, that is, a change in dollars over a period. They show only the balance in accounts on a specific date, like apples in a barrel. To see a flow, two balance sheets — one at period beginning and one at period ending — need to be compared.

How about your ATM or "debit" card that you carry around? Is it correctly named? Yes it is; let us see why. The money in your checking account is a short-term liability on the bank's balance sheet. It is money owned by outsiders (you) and thus it conforms to the definition of a liability. It finances or pays for an asset of equal amount, the bank's cash on hand. Everything is in balance. Suppose you want to take some of your money out of the bank. This will decrease the bank's liability to you. Recall that transactions to liabilities are credits (increases), so in order to decrease a liability we record a debit to the liability. To wit: a decrease of a liability is a debit to the liability; thus the "debit card." Now, of course, we still need the second transaction to the balance sheet to maintain the balance. If the liability is to be debited, then an asset must be credited (decreased), like the bank's cash on hand, or another liability is credited (increased), like a short-term note, to obtain the money to pay you.

Now that we understand a little bit about how accountants do their math, let us get back to project management.

The Project Balance Sheet

We now consider the insights about the business learned from the accounting balance sheet that will provide a quantitative framework for the project manager. First we direct our attention to the three elements that are necessary to form a balance sheet. To charter the project, business sponsors assign resources and state the required project returns needed for the business. Project returns are both functional and financial. Any one of the business value models we have discussed could be used to form the sponsor's view of the project. Sponsor-invested resources correspond roughly to the capital or equity investments on the accountant's balance sheet. As many companies are measured by the returns earned on the capital employed, so it is with projects. We will discuss in subsequent chapters that a project metric in wide use is the concept of economic value add (EVA). In effect, EVA demands positive returns on capital employed.

Second, the project manager is entrusted with resources owned by the business to carry out the project. These resources correspond roughly to the company-owned assets of the accountant's balance sheet. Like company managers who are often measured on their ability to create a return on the assets entrusted to them, so it is with project managers. Project managers are always judged on their ability to employ successfully the sponsor's resources to achieve the project objectives.

Third, there is the gap between the investment made available and the resources required. On the accountant's balance sheet, this gap between investment and resources is filled with loans from outsiders: suppliers and creditors. On the project balance sheet, the gap is filled with risk! Risk is taken, or assumed, to fill the gap between expectations and capabilities, between sponsor investment and project estimates of resources. Figure 1-7 illustrates the tool we have been discussing.

click to expand
Figure 1-7: The Project Balance Sheet.

We now have the elements for the "project equation," a direct analog to the accounting equation: "Value delivered from resources invested = project capability and capacity plus risks taken." [15]

For project managers, their mission is now defined: "The project manager's mission is to manage project capability and capacity to deliver expected value, taking measured risks to do so." [16] [17]

Project Balance Sheet Details

The project balance sheet seeks to make a quantitative and qualitative connection between the business and the project. On the left side, the business side, is the sponsor's view of the project. The sponsor's view is conceptual and value oriented, nearly void of facts, or at least void of the facts as the project manager would understand them. Often the sponsor has no specific understanding of project management, of cost and schedule estimating for research and development, or of statistical analysis of risk, and does not seek to acquire an understanding. In system engineering parlance, the project sponsor sees the project as a "black box." However, the sponsor knows what the business requires and knows how much investment can be made toward the requirements.

The project manager has the facts about the project, even if they are only rough estimates. The project manager knows and understands the scope, even if the scope has "known unknowns" that require more investigation and definition. [18] We have already made the point that risk balances the facts with the concepts. However, a bridge is needed to couple unambiguously the sponsor's understanding and the project manager's understanding of the same project. That bridge between project manager and business manager is a common understanding of scope. Even with language and experience barriers, scope is the translator. The test for the project manager is then to ensure that there is good understanding of scope and then to convey the risks in business terms. This done, the project charter can be signed with expectation of good results to come.

Now what about debits and credits? Where do they come into the project balance sheet? Like the accounting equation, the project equation is not a functional equation of the form y = f(x) + c that specifies y to be functionally dependent on x. Indeed, the left and right sides are pretty much independent, just like in the financial domain. By independent, we mean that the estimates of cost and schedule done by the project manager are based on the facts developed by the project team for the work specified in the work breakdown structure (WBS). Those project team estimates are not, or should not be, dependent on the business value estimate developed by the project sponsor. However, once the charter is set, a change in one of the three elements (business value on the left side, risk or project capability on the right side) requires that another of the three elements must correspondingly change to maintain balance.

If, for instance, we continue to say debits are increases to the left and credits are increases to the right, then a debit of scope by the sponsor (that is, an increase in scope) must have a corresponding credit on the right or else balance is violated. By way of another example, if the situation were that the project manager had to credit the capability, [19] and no debit was available from the sponsor, then the required debit must go to risk in order to restore balance.

But is balance really all that important? Yes. The interpretation of imbalance is that there is not a meeting of the minds regarding the value demanded (left side) and the likelihood of successful delivery (right side). Consequently, the project may not be sustained, sponsor confidence in results may be challenged, and the project team may not be supported adequately during execution.

Integrating the Project Balance Sheet and Business Value Models

Now let us integrate the concepts discussed in this chapter to complete the framework on which we hang quantitative analysis to be discussed in the remainder of this book. The business models drive the left side of the project balance sheet. The model results, working through the value flow-down process, frame opportunity (new products, new markets and customers, operational and organizational needs) and quantify goals. Goals, deployed through strategy, lead to identified projects. It remains to select among the identified projects those that are affordable, most beneficial, or of highest priority to the business. We will discuss decision making in quantitative terms in Chapter 4. Suffice it to say there is a means to make these selections and charter the project. The generally accepted definition of the project charter is "a document issued by senior management that formally authorizes the existence of a project..." [20] More about the charter can be found in the literature, primarily A Guide to the Project Management Body of Knowledge. [21] With charter in hand, the project sponsor conveys the project requirements and investment allocation to the project manager. Doing so completes the chain from business executive to project sponsor, thence to project manager through the connectivity of the project charter and the left-to-right-side bridging effect of scope on the project balance sheet, as illustrated in Figure 1-8.

click to expand
Figure 1-8: Business Models and Project Balance Sheet.

We now have a consistent and traceable path to and from the source of business value for numbers from the right side of the project balance sheet representing capability and risk. A traceable path is needed, after all, because projects draw their value only from the business.

On the right side of the balance sheet we have two elements: (1) project capability and capacity and (2) risk. A well-accepted method to express capability and capacity is with the so-called "iron triangle" of scope, time, and cost. Since there is interdependency among these three, it is traditionally to set the one of highest priority, optimize the second highest priority element, and the third becomes what is necessary to close the triangle. This author prefers the "project four-angle" of scope, schedule, resources, and quality as shown in Figure 1-9. The set-and-optimize process is about the same as in the iron triangle, except that two elements could be involved in the setting or optimizing.

click to expand
Figure 1-9: The Project Four-Angle.

We will see in Chapter 3 that the best quantification tool for scope is the WBS. Time and cost can be estimated for the scope on the WBS somewhat independently, but ultimately they are tied together through the concept of value. Earned value is the preferred numerical analysis tool, and that will be discussed in Chapter 6. There are numerous ways to evaluate quality. One we will address in Chapter 8 is Six Sigma.

Finally, there is risk. Risk in quantitative terms is expressed in the same units as the related item in the project capability and capacity. The risk component of the right side of the balance sheet holds the variance to the mean that must be managed in order not to endanger the business investment.

Figure 1-10 illustrates the points discussed.

click to expand
Figure 1-10: Right Side Project Balance Sheet.

[12]Goodpasture, John C. and Hulett, David T., A balance sheet for projects: a guide to risk-based value, PM Network, May (Part 1) and June (Part 2) 2000.

[13]Goodpasture, John C., Managing Projects for Value, Management Concepts, Vienna, VA, 2001, chap. 3.

[14]The author is indebted to Lou Lavendol, Senior Systems Engineer at Harris Corporation, Melbourne, Florida, for his insightful discourse with the author regarding risk taking and business value in the context of proposing on defense industry programs. In those discussions in the early 1990s, the tension was between marketing (sales) that represented the voice of the customer and system engineering that represented the project. Often, there was a gap between marketing and engineering, a gap that could only be filled by someone taking a risk.

[15]Goodpasture, John C., Managing Projects for Value, Management Concepts, Vienna, VA, 2001, chap. 3., p. 46.

[16]Goodpasture, John C., Managing Projects for Value, Management Concepts, Vienna, VA, 2001, chap. 3., p. 46.

[17]The author has paraphrased slightly the project equation and the project manager's mission from the text given in the reference (also the author's work).

[18]"Known unknowns" is a concept from risk management. The idea is simply that in framing the scope, there may be many unknowns, but the fact that there are undefined elements of scope is itself known.

[19]Recall that we are using the word "capability" to stand in for the set (scope, cost, time, and quality). To credit capability means that either cost or time has increased, scope has expanded without corresponding relief from the project sponsor, or there is a greater demand on quality. A greater demand on quality usually means tighter tolerances, less scrap and rework, fewer functional or performance errors in the production deliverable, or perhaps lesser life cycle investment forecast for service and maintenance after delivery.

[20]A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 2000 Edition, Project Management Institute, Newtown Square, PA, p. 204.

[21]A Guide to the Project Management Body of Knowledge (PMBOK® Guide) — 2000 Edition, Project Management Institute, Newtown Square, PA, p. 54.