Introduction
In the future, project management will become standard management practice; the way things are done in organizations. For this to occur, however, project management practices will have to develop from the current technical orientation into a business and organizational orientation. This means that the time-honored triple constraints, which are currently used to measure technical project success, will have to be expanded into broader measures of project success, such as the project's overall contribution to organizational value. This expansion of success criteria will change decision-making during projects, they way projects are judged as successful and the way that project managers are developed, measured and rewarded. That is, it will change the entire profession of project management. This paper will begin by outlining the changes in project management that have resulted in diminishing the adequacy of the triple constraints for measuring project success. A future business venture model of project success will then be developed. This model shows how the triple constraints eventually influence shareholder value and thus expand those project measurements into business system measurements. A business systems calculator will be introduced which visually shows the effects of various project decisions on the project's eventual contribution to shareholder value. This calculator is posted on a website and thus becomes a takeaway for all who attend this session.
Defining Project Success: From Triple Constraints to Shareholder Value
Project management began as a sort of counter culture movement. The original project managers worked outside the organization. In fact they were normally outside in a trailer at a construction site, in the then prototypical project office. Back then the art of project management was something akin to voodoo, and the seal of the craft was the PERT chart. Project managers were measured by their ability to work within the triple constraints of outcome, cost and schedule. Projects in the past had a bit more certainty in the outcome as the main source of uncertainty was in the technology used to deliver that outcome. But the tables turn, and as the technology becomes more reliable we find the definition of the project outcome becomes more illusive. A brief history of this change is given below.
The Distant Past
Outcome—In many cases in the past, the project manager had done something similar before, so they could see an example. For example, most early project management was done at construction sites. This results in reliance on clear specifications. Project practice dictated to not begin a project until detailed specifications were written. Often the specifications were made even clearer by architect's drawings. This allowed the project manager to know most of the components of the final product when the project began.
Cost—If you know what components cost and how much labor is needed, costs are much easier to estimate. This causes a reliance on the budget as project decisions were evaluated on their affect on the budget. The project manager was measured on adherence to budget. Only approved change orders were allowed, which results on heavy reliance on upper management for decision-making.
Schedule—If you know how long components take, scheduling is easier. This causes reliance on PERT and schedule techniques. Due to familiarity with similar projects it was easier to change people on the project without affecting the schedule. The project manager was also measured on adherence to schedule. Only approved change orders were allowed, which again results on heavy reliance on upper management for decision-making.
The use of triple constraint provided metrics for upper management measurement, evaluation and control. They knew how well the job was done when the project was over. Triple constraints also provided criteria for evaluating options for project decision-making. Thus, the triple constraints solved problems for both the project manager and upper management.
The Recent Past
As uncertainty in projects increased, the efficacy of the triple constraints decreased. With more uncertainty, the reliance on triple constraints begins to cause, not solve, problems. The first wave of increased uncertainty occurred when project management moved inside the organization and was applied to organization (customer) issues.
Outcome. Fewer examples were available for internal projects and these were not repeatable, as the customers always wanted something new. Project managers were still trained to not start without specifications. The result was to force specifications from customers who were not really certain what they wanted. These specifications gave the illusion of certainty, but the result usually disappointed the customer.
Cost. With a budget based on forced specifications, more changes were required as the project progressed. The project manager was measured on adherence to budget so necessary project changes required further consultation with upper management, which slowed things down.
Schedule. Since the schedule was based on forced specifications, it was highly affected by the many changes and decision delays.
Metrics used to evaluate projects caused suboptimization due to the myth of certainty. Relying on triple constraints caused project managers to chase after the wrong goal, satisfying constraints rather than satisfying the customer. When this occurs, something is delivered by the deadline, but it is not really what the customer wants. Lower customer acceptance leads to lower market sales and organization profit. However, since something was delivered somewhere near the budget, the project was often considered a success, even if the project outcome was a failure. Obviously, change was needed.
The Future
The next wave of increasing the uncertainty is being caused by the increasing speed of change, so-called Internet time. In extreme uncertainty it becomes impossible to determine a fixed outcome, cost and schedule for any project. The myth of certainty is no longer believable so that outcome, cost and schedule become project variables rather than constraints. Guidance for decision-making thus becomes the effect of the decision on economic value to the organization.
Outcome. Project outcomes begin very vague, then continually changes due to customer information gained from rapid prototyping. Project success is really only known after project outcome life cycle is completed, and heavily dependent on project's contribution to economic value.
Cost. Continually changing and in need of constant review— do we pour more money into this? The old concept of cost is seen as possibly irrelevant to the goal of contributing to economic value. Costs are thus seen as investments made now to increase organizational value in the future.
Schedule. The schedule becomes much more externally driven and not in your control. It is based more on the market than on time needed to produce the project outcome. As cycle times are reduced, project outcome success is heavily dependent on how you begin. Thus the fuzzy front end, the time at the beginning becomes most important for project success. This irritates upper managers who like to jump in at the end.
Triple constraint metrics used to evaluate projects will now cause real problems and possibly failure due to need for changes during project. Relying on triple constraints may cause you to deliver the wrong product. Something will be delivered by the deadline, but the technology may have changed and the market may have moved on. For the future, a new metric will be needed.
The New Metric-Project Contribution to Business Results
Future project managers need a longer-term business orientation that takes into account project contribution to business results. For most business organizations this means project contribution to business strategy and shareholder value. Fortunately, both of these can be seen as an extension of the triple constraints. What was before a set of three fixed constraints that bounded the project now becomes three variables that enable the project to achieve business results. This is achieved through a dynamic process of jointly optimizing the three project variables of cost, schedule, and outcome in service of strategic alignment, shareholder value and ultimately business results.
Why strategic alignment? Because certain tactical moves may be inconsistent with an overall strategy for the company. If a project engages tactically in an inconsistent direction, it may subtract from long-term business results even though it adds to economic value over the short term. For example a project the emphasizes cost savings for a new product or service in a company that stresses customer intimacy may save money over the short term, but it will not contribute to business results over the long term. The same holds for a project that emphasizes the latest technology in a company with a strategy that emphasizes low cost, high volume, and process efficiency (Cohen & Graham 2000, Ch. 3).
Why Shareholder value? Because over the long run and on average that is the goal of a publicly owned corporation. Shareholder value is a measure of economic value added for the company as a whole. If projects do not contribute to this in some way they represent money invested with a return below investor expectations. This, in turn, will lower the stock price over time and impair the company's ability to raise capital to support its competitive advantage in the marketplace. Thus shareholder value provides a compass for projects to maintain their direction in a stormy sea/turbulent environment. As things are constantly in flux, the project manager uses shareholder value as the system objective to set priorities and make decisions to guide project midcourse corrections.
How Project Decisions Relate to Shareholder Value
Here we are going to focus on project decisions related to project contribution to shareholder value. The system of variables which influence shareholder value from within the project is illustrated in Exhibit 1. Project contribution to shareholder value is influenced by two major factors, the combined cash flow of the project and its outcome life cycle (the project venture) and the internal charge for capital used to finance the project venture.
Exhibit 1
Capital charge. The internal charge for the use of capital is based on the company's weighted average cost of capital (WACC). Project managers do not influence this over the short term. Over the long term, however, they can lower this by managing good projects with successful outcomes. The capital charge is influenced by the use of capital by the project venture and the weighted average cost of capital for the company. The use of capital by the project venture is a combination of the use of capital by the project and the use of capital by the project outcome life cycle. At this point we can see the influence of the three project variables on this part of the business system. Project cost and project duration are a direct influence on the project's use of capital. The longer and/or the more expensive the project is, the higher the capital charge. Outcome, in turn, influences the capital charge of the project outcome life cycle. Here consideration of time to breakeven and the use of working capital become important. These financial results can be influenced by decisions made during the project and so the project manager and team members should understand the business implications of their decisions. For example, the decision to add a new feature may increase the project duration, which will result in an increase in the capital charge.
Cash Flow. The cost of the project, the revenues during the project outcome life cycle (POL) and the POL expenses influences the combined cash flow of the project enterprise. Project cost directly impacts immediate cash flow, but it also influences depreciation charges stemming from the POL. Duration and outcome influence price and market share, which determine POL revenues based on time to market considerations and meeting customer and end user expectations. Outcome also influences POL operating expenses that along with depreciation influences total POL expenses.
As illustrated in Exhibit 1, this is a fairly complex system of variables. It does not lend itself to a set of recipe answers on how to maximize shareholder value. Decision-making within the project is based on a sound business case that justified the project in the first place. The case is constructed to make all assumptions explicit and to explore the dynamics of the relationship in the business system of the project. This is in stark contract to the numbers game that is often played out using a business case purely for gaining project approval. You know it well—“What numbers do I have to fill in to get this project approved?” During the project, the business case is further researched, fleshed out, and turned into a detailed business plan so that the project team can continuously check assumptions about projected results with actual results. Decisions about duration, cost, and outcome are then made in relation to how they interact with each other and how this interaction impacts shareholder value. The process always involves tradeoffs. For instance we can cut the budget and eliminate features, but at what cost to customer demand and revenue from the POL? We can pull out all of the stops and spend whatever it takes to be first to market, but will the gain in market share really pay back enough to cover our additional expense? Even though conventional wisdom says yes, it may not always be the case.
Business System Calculator
Because this is a fairly complex system many people can better learn its dynamics through a “hands-on” approach. We have developed a calculator to allow you to experiment with different decisions in order to see how they influence shareholder value under different assumptions. We explain where to get it (at no cost) and how to use it below. We have also developed a simulation that illustrates how a portfolio of projects influences a company's shareholder value over time depending on how they are managed. This is available as part of a course to help project managers improve their business decision-making in projects.
The business systems calculator is a spreadsheet program that can be downloaded from www.projectmanagersmba.com. Usage instructions are contained in the program, under the first tab. As input you will use values typically contained in the business plan. This includes project cost and duration as well as the starting price and cost, and the price and cost erosion, of the project outcome. Input concerning the market is also required. This includes an estimate of the total market volume over the POL, the time the market for the outcome will begin, and estimates of your market share for entering the market at various times. The WACC is also input. Output includes the net present value for the entire venture as well as a graphical representation of the venture's contribution to shareholder value over the life of the project. Project decisions can then be evaluated by estimating the decision's impact on any of the input variables and then calculating the resulting effect on shareholder value. More details on the use of the calculator are contained in Cohen and Graham (2000) and a demonstration will be given at the paper presentation.
