The Value-Abled Project

by Stephen Devaux, October 12, 2006 | SHARE

Only by managing and demonstrating project value can we truly justify adding
resources, changing scope or moving deadlines. In a new series, Steven
Devaux describes how project managers and organizations can break out of
the time-budget mindset to better focus on the most important part of any
initiative the return on value.

This is the first in a series of articles exploring, summarizing and expanding on the specific techniques,
metrics and implications of a methodology called Total Project Control (TPC), which focuses on
managing and demonstrating project value.
Lets begin at the beginning, with a definition: Project. A temporary endeavor undertaken to create a
unique product, service, or result. This definition is from page 338 of the Glossary of the Project
Management Institutes 2004 edition of the Guide to the Project Management Body of Knowledge. Oh,
what a wondrous moment that was when the first PMBOK Guide was published, back in 1996 so many
knotty arguments that hinged on semantics seemed suddenly to disappear such as Whats the difference
between a task and an activity? and Is a work addition that doesnt alter the final product really a change
in scope?
Those who remember the lost-in-the-wilderness pre-PMBOK days should think carefully before urging a
change in the definition of a word as fundamental as project. I want the reader to know that I have
thought this over very carefully for many years, and have come to the conclusion that a change is essential
to the progress of the project management discipline.
The Case for Change
Lets examine the parameters of the following hypothetical project: 1.) The planned duration is 12 months;
2.) The budget is $10 million; 3.) Upon delivery of the final product, the customer will pay us $8 million.
Whats wrong? Is something missing? Do you feel that I must have omitted some very important item of
information, or else we would not be doing this project?
First, let me assure you that this project fits the PMBOK Guide definition in every way it is a temporary
endeavor to create a unique product. That said, there is something very important missing both in the
project parameters and in the definition.
We know that projects often fail to generate their expected value. However, no one, ever, knowingly
undertakes a project that is expected to have greater cost than the value it returns. This is not true just
99.9 percent of the time its true 100 percent of the time. It is so true that in looking at the above project
parameters, one immediately assumes that there is an important piece of information missing: what other
value do we expect to get from this project? And if the answer is none (or, indeed, if the answer adds up to
less than some number that exceeds $2 million), then the assumption must be that whoever undertook
this project needs to be hauled off to the local State Home for the Grievously Bewildered.
Of course, there are many kinds of value drivers that could add enough value to redeem the above
project: follow-on business, good customer relations, brand name publicity, improved staff skills, and
resource availability premium are just a few. But the crucial facts of this example are:
1. Everyone immediately recognizes that either one or more of such value drivers must exist, or we should not
be undertaking this project.
2. That such knowledge is an elemental data point in project selection (and, I would argue, project
performance).
 This example should tell us something not just about this project, but about every project, whether
revenue-producing, cost-saving, productivity-enhancing, humanity-helping, personally-gratifying, or any
combination of the above expected value is the raison detre, the reason for being, of every project, and
cannot be an afterthought. The expected value-above-cost (can we agree to call this by the great
oxymoron: project profit?) and the scope/schedule factors that drive it are data items that should guide
all decision-making, including:
Project selection, along with portfolio balance and management.
Scope development (both product and project scope).
Schedule optimization.
Resource allocation, including organizational staffing levels.
Risk/opportunity management.
Cost planning and control.
Schedule tracking and control.
The details of precisely how all this should be done require far more space than is available here, but three
questions do need to be answered in this first article in the series:
1. What are the grounds for saying that the investment aspect of a project has been overlooked?
2. What have been the consequences of this oversight?
3. What is the proposed solution?
The Evidence
Some readers who work in specific industries might feel that their projects are already profit-driven.
Any such individuals are most likely to work in contracting, or (less likely, but possible) new product
development. But even in the most enlightened of such industries, where senior managers may perhaps
use expected value and profit in making project portfolio decisions, almost none of that information ever
seeps down to the project managers, activity leaders and individual contributors. These are the people
who, on a daily basis, make decisions that hugely impact project profit, either positively or negatively. And
yet they are expected to march blindfold to a budget/deadline cadence, with a wall between them and the
detailed value data.
How can they possibly make informed decisions about the integrated scope/cost/schedule tradeoffs? And
in other application areas (corporate IT, highway construction, hospital medication reconciliation,
systems integration, etc.), there is almost zero value-analysis invested in the specific details of scope,
resources and timing around which managers and teams implement projects.
Where is the evidence for the above assertions? First off, the fact that not a single commercially-available
project management software package comes with out-of-the-box functionality for entering, managing,
and tracking project value or profit in integration with the activity list, schedule, and cost.
Second, while the PMBOK Guides index lists the word cost as appearing on a total of 89 of the 295 pages
of its 12 chapters (as well as seven additional uses in constructions such as cost control or cost-of-quality),
the same index does not list either profit or return-on-investment (or ROI). And with the notable
exception of earned value terminologies, the guide mentions value only three times (twice in value
engineering and once in expected monetary value).
Finally, and perhaps most telling, is that few people seem to recognize that the term earned value is a
misnomer that confuses value with cost. Earned value was originally a U.S. Department of Defense
technique used to track contractor progress on DoD acquisitions programs. From its point of view, the
DoD (which does not see its acquisitions as investments, despite the fact that they clearly are) wanted to
ensure that the contractor was doing the work for which the DoD was investing, i.e., earning the value of
the DoDs invested dollars. This was recognized in the fact that the three parameters of DoD earned value
measurement (budgeted cost for work scheduled or BCWS, budgeted cost for work performed or BCWP,
and actual cost for work performed or ACWP) all contain that key letter C in the second position: for
cost.
But as the DoD technique proved its usefulness and spread to private sector projects, what should have
been a highly meaningful distinction between project value and project cost became blurred. And when
the 2000 edition of the PMBOK Guide trimmed the admittedly difficult four-letter acronyms to two letters
(PV, EV and AC), even that subtle distinction of the letter C was gone. (Of course, no one planning or
judging an investment, other than a government, would ever confound cost and value. Only by being
blind to the essence of a project as an investment is it possible to mistranslate a metric such as planned
cost into planned value or PV).
The Consequences
The simplest and most blatant problem with the failure to recognize and manage the value and profit
aspects of projects is bad projects. This starts at the level of project selection and portfolio management,
where resource usage in the multiproject portfolio is not targeted and optimized to give the greatest
return. It continues in the failure of project teams to look for opportunities and take advantage of the
scope/cost/schedule tradeoffs to maximize project profit. And it leads directly to so many of the problems
that bedevil project managers, and project management. Want to save money? Trim the projects budget.
Want to save more? Terminate the project. Your project needs more resources? Forget it youre costing
us too much already!
Bad project management costs us all
because of delayed or overbudget pharmaceutical products, asthmatics and diabetics live in pain and
die.
because of poor project planning, hospital IT systems fail to perform adequate medication
reconciliation, and patients die.
because of late DoD programs, soldiers die.
because of inadequate template development and optimization, responses to national emergencies are
sluggish, and citizens drown, or burn, or asphyxiate beneath rubble.
because of poor project decisions, taxpayer-funded infrastructure projects go $12 billon over budget and
take four times longer than planned.
The problem lies not in the stars, but in ourselves. We, the practitioners and theorists, have labeled
ourselves as cost centers, and focused our responsibility on the project negatives of time and cost. The
two key metrics we use to judge project performance Is it on time? Is it within budget?) doom us
to march within our limited goals of deadline and budget, while shrugging off responsibility for the most
important part of our effort: the return of value for which were doing this. Only by managing project
value and demonstrating increased project profit can we justify resources, trim or add scope, delay
deadlines, and show that the extra time and cost spent on quality or risk reduction will increase the
returned value.
And the solution? Amend the definition of a project slightly Project: a temporary investment in work
undertaken to create a unique product, service, or result.
Change the definition, and ideas and techniques will rapidly germinate and spread to maximize, manage
and track the investment in the best ways possible. These ideas and techniques will be explored in the
upcoming articles in this series.
Next: Money Project, or measuring the project investment.
Stephen A. Devaux, PMP, is Adjunct Professor of Project Management at Brandeis University and
Adjunct Lecturer in Project Management at The University of the West Indies at Cave Hill, Barbados.
He is also president of Analytic Project Management, Bedford, Mass., a PMI Global R.E.P. A former
project manager of corporate training, Devaux has spent 19 years training and consulting with Fortune
500 clients in industries ranging from aerospace and pharmaceuticals to software development and
telecom. He is the creator of the Total Project Control (TPC) methodology, and author of Total Project
Control: A Managers Guide to Integrated Project Planning, Measuring and Tracking (John Wiley & Sons;
1999).
http://www.projectsatwork.com/content/articles/233444.cfm