Oxymora. Jumbo shrimp. Domestic tranquility. Yellow taxicab driver. Why is “project profit”treated as if it were another oxymoron?
And it is. Ask any project manager how big her project is and you will hear something like: “Well, it’s a 10-month project with a budget of two million dollars.” Great! But why are you doing it? Because you have nothing better to do with your time and resources? Because you need to get rid of all that money?
The truth is that the most important part of any project is usually ignored—why are we doing it? We are doing it because of the value we are going to get from it. And we are going to get that value from the product or service that is delivered at the project’s completion.
The implications of this omission are huge—if projects cost money and occupy time, then who would ever want to do them? Projects become “cost centers,” and everyone knows that organizational cost centers have a much harder time getting resources than “profit centers.” And if projects are cost centers, what does that make project managers?
The fault, dear project manager, lies not in the stars but in ourselves. The three sides of the Triple Constraint paradigm, that triangle that is fundamental to every project, have never been properly integrated. Project management theory has done an excellent job of dealing with two sides: TIME and COST. But that third side, PROJECT SCOPE, has long been ignored. Yet it is the most important of the three!
We have done so bad a job of dealing with that third side that there is not even unanimity on how it should be labeled. In IT projects, it is common to see the third side labeled “QUALITY.” Occasionally one sees it labeled “PRODUCT SCOPE.” The latter is closer to the mark, but both are incorrect. If it is the totality of the project that we wish to represent through this paradigm, then the third side must be project (or “work”) scope, for the simple reason that otherwise something will be left out. Some project scope is neither quality nor other product scope (e.g., features), but is nevertheless work which must be performed in order to complete a satisfactory project, and which adds time, money, and value to the project. A time/cost triangle could be constructed on the “base” of either product scope or quality, but it would be smaller, a subset of the total project triangle. And in order to accomplish true Project Integration Management, the totality of the project must be modeled. This leads to the Total Project Control (TPC) methodology.
In the 1980s, project management software packages often were marketed in terms of how well they performed what was called “cost/schedule integration.” This terminology was borrowed from the U.S. Department of Defense’s Cost/Schedule Control System Criteria (C/SCSC), but it was basically a way of saying that,within the software, if one changed the schedule, one could see the impact on cost, and vice versa. I would argue that even the best such packages didn’t really do cost/schedule integration, since the cost and schedule are measured in different units: cost in dollars (or sometimes manhours, as project cost is really a measure of resource use) and time in hours, days,weeks, etc. In order to really have integration, we need to have a single metric that works for both parameters.And for scope/cost/schedule integration, the metric would have to work for all three sides.
Just as the project itself starts with the reason for doing it, our quest for an integrated metric must also start. If we are undertaking the project scope because of the value (contract price, sales revenue, market visibility, productivity improvement, etc.) of the deliverable(s), then surely that is how we should quantify the work scope; by the expected monetary value (EMV) that justifies the spent time and resources. For example, if a new remotecontrolled lawn mower is expected to generate $20 million in sales, based on certain features and a delivery date ofMay 1, that is the most important fact about the project, its very raison d’etre. With that information, and only with that information, are we justified in investing the time and money necessary to bring the product to market.
This concept seems obvious—what smart investor would sink millions of dollars into stock without first assessing how much the return is likely to be,what the risk factors are, and whether other stocks might not be even more profitable and/or less risky? As we shall see, once a project is being performed, all sorts of decisions will hinge on the answers to these questions. But without doing such analysis, how can we even start? How do we know that this project, and not another, represents the best investment? How do we know how such risk factors as schedule, technical achievability, or resource availability might impact each project’s potential value? Yet, it is amazing how often this analysis is entirely omitted even for projects requiring multimillion-dollar investments.
Exhibit 1. The Three Sides of the Triple Constraint Triangle
Exhibit 2. Quantifying All Three Sides of the Triple Constraint Triangle
Monetization of the expected value of the project scope, whether performed by the project manager, the CEO, the division vice president, the marketing manager, or the contracted customer, should be one of the first steps in the project management process. All other decisions must then be justified on the basis of this value.And, of course, the next step now becomes obvious: the estimated resource use of the project is usually monetized as the COST side of the triangle! And the difference between the dollars we expect to generate or save, and the dollars we estimate having to spend to obtain that value is … the project profit!
Suddenly,with just two sides of the triangle quantified in dollars, all other project issues can suddenly be viewed in terms of how, and how much, they affect the project’s “bottom line.” But there is an equally important aspect of such “projectization” of profit. Suddenly, the project’s contribution to the raison d’etre of the entire organization (either profit or, for nonprofit organizations, additional value/services per used resources) is identifiable, measurable, trackable, and expandable. Instead of the project simply aiming for a completion date and budget that has been plucked from thin air, those controls can be determined on the basis of whether they increase or decrease the expected project profit. Even the individual elements of the project scope, right down to the activity level, can be put to the test: does, for example, a better package design, but one which adds both time and cost to the project, seem likely to increase the profit? If not, don’t do it!
Developing a Fully Integrated Metric:The DIPP
Although monetizing the first two sides of the triangle, PROJECT SCOPE and COST, provides all the data needed to calculate project profit, every project manager knows that the third side is, in its own way, at least as crucial as the other two. In order to have a truly integrated process, TIME has to be as measurable as the other two, and in the same metric: dollars!
Fortunately, we have the Forefather of American Project Management to turn to for the answer to this: “Time,” said Benjamin Franklin, “is money!” But how exactly is time money on a project? And the answer is … in any number of ways, depending on the nature of the project. But TIME is always money, in one way or another. It is a plus or minus value, an acceleration premium or delay cost, factored into the expected monetary value of the project scope.
Whatever the project’s EMV, it is based on a specific project completion, or delivery, date. Make that date earlier or later, and the EMV almost always changes. Sometimes a change of one day can change a project’s EMV to zero: a space probe being launched to rendezvous with a comet might miss its window if it’s either a day late or a day early. In other cases, there might be a slight bonus for acceleration, but a huge penalty for delay: a toy being developed for the Holiday shopping season may benefit slightly from being in the stores in early November, but lose its entire profit margin if it’s not there by Thanksgiving.
There may be cases where there seems to be no benefit from finishing a project earlier: fixed price contracts with specified delivery and payment dates, and no early delivery incentives. Such situations are distortions caused either:
1. By the contracting process, where the separation between the person receiving the value from the product and the person receiving the value from the contract, are different.
2. By the fact that the full scope of the project has been decomposed into smaller projects, where the projects for the subdeliverables are not on the critical path of the total project, but actually have float. Their full value is not generated until other parts of the project are completed.
Under the simplest of circumstances, if we recognize that every project is performed for the value generated by its deliverable( s), then, at the very least, finishing the project earlier generates that value earlier, while finishing it later delays receipt of the benefits. Simple net present value principles demonstrate that monetary value received a week later is less than the same value received a week earlier.
And so we have quantified all three sides in the same unit: dollars. PROJECT SCOPE is EMV dollars, COST is resource usage dollars, and TIME is the acceleration premium or delay cost dollars as function on the EMV. Thus project profit is really:
($EMV + or – $acceleration/delay) – $cost
In addition, and perhaps even more valuable, this allows us to formulate a profitability index. This index is one that I first proposed in an article published in the September 1992 issue of Project Management Journal, titled: When the DIPP Dips: A P&L Index for Project Decisions. In that article, the DIPP (which stands for Devaux’s Index of Project Performance) was proposed as an index for determining whether to terminate or continue funding an ailing project. What it took me several more years to recognize is that, by quantifying the three sides of the Triple Constraint triangle, the DIPP can be used as a barometer to gauge all project decisions. The formula would be:
DIPP = ($EMV + or – $acceleration/delay) divided by Cost ETC
Exhibit 3. Planned DIPP With a 5% Threshold Factor Built in for Senior Management Control
At the start of the project, the Cost ETC is the planned budget. As the project proceeds,work is accomplished, resources are used, and costs accrue and migrate from the estimate-to-complete column to the “sunk costs” column. Therefore the DIPP should curve steadily upward as the denominator declines. If it doesn’t, or it does not do so as rapidly as expected, it indicates that either the Cost ETC is declining more slowly than expected, or that the EMV has changed. There are many factors that could cause the EMV to decline. One is a change in market conditions. A second is a pruning of project scope. An even more common explanation, of course, is project delay, which can both reduce the EMV (per TIME delay costs) and prevent the Cost ETC from declining as rapidly as planned.
Whatever the cause, a variance between the planned DIPP curve and the actual one should send a signal that something is wrong. Threshold levels, such as those that are often built in on the earned value indices SPI and CPI, can be built in on the DIPP to allow senior management to oversee the project on an exception basis.
Tracking Portfolio Profits Through the DIPP
The senior management of a project-driven organization should also be tracking its own DIPP. To whatever extent an organization’s profits are generated by projects, to that extent the organizational DIPP, across the entire multiproject portfolio, is the barometer of profitability, a forecast of the future bottom line. Each portfolio manager should receive regular reports on the DIPPs and other status of each project that the organization is supporting. Such data might be displayed in the reporting format shown in Exhibit 4.
Exhibit 4. The TPC Portfolio Summary Report
Exhibit 5. TPC Data for Proposed New Addition to the Portfolio
With these data, the portfolio manager can track the profits and revenues of each project, and forecast profits across the total portfolio. If each of the project managers is working at the project level to maximize each project’s DIPP, the portfolio manager can be fairly confident that the profitability, for the current investment, is maximized. If any project slips from its current completion date, both its DIPP and the portfolio DIPP should decline. In addition, the portfolio manager can assess requests from project or line managers for changed priorities or increased staffing levels. These are the sorts of decisions that should never be made without assessing the impact on profitability at the organizational level.
The portfolio above seems quite healthy. The potential acceleration gains, especially the 5% per week, or $500,000, on Project D, might stimulate the portfolio manager to work with that project manager to see if additional resources or vendor incentives would be practical. But overall, as long as nothing slips, everything seems to be proceeding in an acceptable manner.
However, what happens when a new project is suggested? Perhaps a very profitable one, such as Project E, shown in Exhibit 4.
Assimilating a New Project Can Make the DIPP Dip!
First, please notice that Project E is not a three million dollar project— it’s a nine million-dollar project! This new mindset of “sizing” projects by the project profit instead of by the cost is crucial both to the process of justifying priorities and resources for this particular project, and for the future stature of project management within both this organization and throughout all of industry.
Second, let’s recognize that this project is an extremely attractive one. Even without doing the sort of detailed EMV analysis that the TPC process recommends, most portfolio managers would realize the potential value of such a project and immediately mandate its implementation. This scenario occurs every day in every business organization in the world (much to the chagrin of experienced project managers, who if they are reading this will already recognize where we are headed!). However, without access to the complete range of TPC data across the portfolio, such a decision is not only unjustified, but also dangerous!
There is only one way that the portfolio manager would be justified in making such a decision: that would be if an entirely new set of resources will be dedicated to the new project. But if Project E is going to be dumped into the hopper with the other four projects, accessing the same resource pool, then it can hardly help but impact the rest of the portfolio. And that impact can be so extreme as to offset all the new profits of Project E. If that is the case, of course, and profits decrease, it will be blamed on bad luck, or poor project management, rather than the simple lack of adequate data.
Exhibit 6. The TPC Portfolio Summary Report After Multiproject Resource Leveling
Exhibit 7. A CPM Network Logic Diagram Displaying DRAG Totals
The TPC process mandates that project data must be analyzed across the entire portfolio. The new project must be resourced and scheduled, and the portfolio subjected to multiproject resource leveling. And, unfortunately,when we do this,we discover that Project E, when added to the organization’s limited resource pool, delays all the other projects,with the results shown in Exhibit 5.
The ability to view such data may in fact be unsettling to some managers. The fact that, for the first time, they are able to quantify how undertaking an attractive new project will reduce the organization’s profitability (if it is implemented as shown above) may introduce an uncomfortable level of accountability. However, the fact of the matter is that this is what would have happened anyway, without the TPC Portfolio Summary Report. Additionally, the TPC data will show how any changes in the above data items will impact potential profits. In other words, there is now a yardstick that will allow the portfolio manager to adjust the individual projects and resources, using the DIPP and profits as a barometer to ascertain a more profitable climate.
Activity DRAG and DRAG Cost
We have thus far discussed project profitability at the project and portfolio levels. But just as portfolio profitability requires data and management at the project level, so too project profitability often requires drilling down to the activity level. Fortunately, other TPC data are available to help target adjustments, in work scope, schedule and resources, to those activities that will most benefit. The full range of these data are outside the scope of this paper. But the simplest new data item to comprehend (if not to calculate!) is DRAG, an acronym for Devaux’s Removed Activity Gauge. DRAG is the opposite of float: it quantifies how much time each critical path activity is delaying the project completion. This is data that is not provided by standard CPM scheduling software. Yet it is hugely important when trying to identify those activities whose compression, either by resource increase or scope reduction,would most benefit the individual project. DRAG data can help point the project managers in the right direction, but most project managers would be hard pressed just to determine which activity in the network logic diagram in Exhibit 7 is causing the most delay, never mind by how much. Fortunately, Exhibit 7 also lists each activity’s DRAG, in descending order, as potential for schedule compression.
Exhibit 8. The TPC Portfolio Summary Report After Project-level Adjustments for Optimized Profit
The DRAG calculation shows that Activity B is adding 18 days to the project, far more than any other task. If this were Project D, and each week of delay beyond January 30 represents a reduction in EMV of $1 million, the DRAG Cost of Activity B would be about $3.6 million. Surely something could be done to remedy this? And if not, how about Activity J ($2.4 million), A or G ($2 million each)?
Generating a More Profitable Portfolio Schedule
Once the value data is properly assembled, other data items (topics for another day) can help the project managers,working under the guidance of the portfolio manager, to optimize each project’s plan. Ultimately, a new multiproject profile, suggested by the TPC data, can help to generate a new, more profitable, portfolio profile, as shown in Exhibit 8.
Exhibit 8 shows that by adding resources to the activities with high DRAG Cost, even though it increases the budgets for Projects D and E by a total of $1.5 million,we also increase their EMV even more, and this should generate $8.2 million in additional profits. Would this be the optimum profile? Is the cash flow available to increase expenditures in such a way? Such questions can only be answered through further analysis. But now at least the data are there for such analysis, across work scope, schedule and cost, as well as across all projects in the organizational portfolio.
And, perhaps most important, the project managers, and project management itself, have demonstrated their value by finding a way of adding precisely $8.2 million to the organizational coffers.