Project Management and Senior Management: Reconciling Their Needs

I’ve been developing and teaching techniques and metrics for managing the business value of projects for over 20 years. My first major article was “When the DIPP Dips: A P&L Index for Project Decisions”, published in the Sep/Oct 1992 issue of Project Management Journal. And the first edition of my Total Project Control book included techniques such the DIPP Tracking Index, the value breakdown structure (VBS), drag cost and the cost of leveling with unresolved bottlenecks (the CLUB): all techniques for managing and tracking projects for optimum value.

But something was missing. I would explain these techniques to experienced project managers in corporate classes and PMI seminars, and from time to time I’d be hired as a consultant to help plan a big project or pull in a slipped schedule. And then I’d leave and realize that I’d only handed the organization a fish. Despite my efforts, I had failed to teach them how to implement the processes to catch it themselves.

teach a man to fish

About five years ago, during the fourth day of a corporate class on the TPC methodology, an attendee said:

“Steve, these concepts and techniques that you’ve been teaching us are great – but we’re the wrong audience. We’re just the master sergeants. You need to be teaching the colonels and generals in this company. Because they don’t understand any of this!”

I started thinking: what is it that I’m missing? Why is it that senior managers have almost no interest in learning about the techniques of something that so clearly impacts an organization’s bottom line?

And so it finally hit me: the concept that I had been talking all around for two decades, the magic word that would make senior managers sit up and take notice. Investment! The thing that senior managers do understand! Not just understand, but respect and study and believe in planning and tracking and optimizing.

Project managers are subject matter experts. They are engineers and chemists and programmers and biologists and doctors and geologists and… They know a lot! They have not only extensive education, but experience in things that it is very important to know!

Where they often don’t have a great deal of knowledge is in terms of what some would call “business skills”: investment and economics and marketing. And you know what? That’s okay! Knowing how to make sure that the building doesn’t collapse, or the airplane crash, or the software consume the hard drive, or the pharmaceutical compound kill someone, or the ground water get polluted… That’s hard and that’s important! Yes, it would be nice if these smart and conscientious folks also had business knowledge and skills – but if we want those skills, they are going to have to be “add-ons”, because these people have been busy all their lives putting their energy into other very valuable knowledge. And that’s why corporations bring in people like me to teach their SMEs project management.

Executives have learned an awful lot as well: about investment and economics and marketing and taxes and interests rates and corporate bonds and organizational structures and behavior… and that’s all important stuff too. What they don’t know about is project management. And most of the time, they are not willing to attend project management classes.

Now, I’ve met some senior managers who seem to think that project management is somehow “beneath” them. (After all, what’s the big deal about delivering a mall or a jet fighter or an oil well or a cure for depression by an arbitrary deadline for an arbitrary budget, right?) But actually most senior managers I have met are bright and conscientious people, too! It’s just that no one has explained to them why knowledge of project (and program!) management – its techniques, metrics, and governance — is importance to what they do: especially investment!

This is where both sides have to learn! They have to learn a common language. They have to institute and use common metrics that are based in the investment information that senior management respects. But those metrics must then guide the project teams in making the right decisions, and senior management must know that this is occurring.

This is the approach that I took in my book Managing Projects as Investments: Earned Value to Business Value that came out last September. It was intended to provide the “common ground”, the knowledge and understanding that both senior managers and project managers need to share. And that is why it was so rewarding for me when the June issue of PM Network included that very nice review of the book by Gary Heerkens, himself the author of The Business-Savvy Project Manager, which I strongly recommend.

Gary’s review said: “But what about during the project? Luckily, in his book,… Stephen Devaux makes solid points about what can be done to maximize ROI during project execution, and it reveals a large void in my perspective on the business of projects.”

Do not be fooled by Gary’s humility! His own book and his regular writings in his PM Network column have taught me a great deal that I didn’t know. Both of us (and let me emphasize that I have never met Gary!) share a love for project management, a desire to learn and, most important, a willingness to admit when we don’t know something. But what makes me happiest is that he identified, without any assistance from me, the deepest intention of the book: to create, define and explore that crucial nexus between the project management discipline and its techniques and the senior management interest in, and concerns about, business value and investment.

I believe project managers must say that word again and again – investment, investment, INVESTMENT! – to project sponsors and customers and all of senior management (especially, when possible, to the Chief Financial Officer!) to establish that we understand why we are doing these projects. (And then, of course, we must be sure to manage them as investments!)

By the way, I have seen this work in a slightly different arena: job interviewing. I often mentor former students through the interview process, and I always urge them to say, at an appropriate point: “Of course, all projects are investments and really need to be managed as such.” They invariably report back to me that the hiring manager’s face lights up. The next former student that tries this technique and later reports that they didn’t either get the job or at least get another interview will be the first!

This territory is also where this blog will continue to cultivate and nourish the improved status of and respect for project management. I believe it is where project/program management and business management must come together for the sake of organizational progress and efficiency.

Fraternally in project management,

Steve the Bajan

How to Use the VBS and Critical Path Drag to Ensure Maximum Project/Program Benefits

In recent articles, I have written about the value breakdown structure (VBS) and tried to show the benefits it offers to both program and project. One of the most important of these is the ability to align the business benefits that the sponsor/customer/program manager wants to the products and work that will create those benefits.

The VBS may be created for projects within a program or for work packages and/or activities within a project. Once the upper levels of the plan (i.e., the major summary elements of the work breakdown structure) have been conceived, communication between the sponsor/customer/program manager and the project manager/team should start, ensuring that the planned elements will in fact create the desired benefits as well as prioritizing the elements.

The initial stage of prioritization is between mandatory and optional work.

  • Mandatory work is that which must be performed or else the project/program will have no value. The value-added of mandatory work is therefore equal to the expected monetary value (EMV) of the entire project/program.
  • Optional work will add value to the project/program, sometimes great value – but the rest of the work would have value even without this particular item. The value-added of optional work is therefore equal to the difference in EMV of the entire project/program with and without this particular product or work item.

Ultimately, it is the optional work that can provide “wriggle room” when the project is being performed – but also can cause lots of mischief, either by being omitted when it shouldn’t be or included when it should be omitted. In other words, optional work often requires decision-making. This is one reason why the MoSCoW method, which simply separates optional work into Should, Could, and Won’t categories, is insufficiently granular. If we are deciding whether or not to invest in a specific element of work, we need a monetary estimate of both its value and its cost.

In the last article, we defined the concept of the true cost of work (TCW) in a program or project:

  • If a work item is on the critical path, its true cost is the sum of its resource costs and its drag cost, the latter being the value/cost of the time that the work item’s duration is adding to the critical path.
  • If an activity is off the critical path, its drag and drag cost are both zero, so that its TCW is only the cost of its resources.

This important distinction means that one can have a situation where a valuable (“Should”) work item ought to be omitted in favor of a low value-added (“Could”) work item, if:

  • The Could item is off the critical path with a value-added of $40,000 and a resource budget of $20,000; and
  • The Should item is on the critical path with a value added of $200,000, but with a resource budget of $30,000 and drag of three weeks at a drag cost of $60,000 per week.

Remember: chances are that the sponsor/customer/program manager will not know the details of the work, in terms of schedule and cost, two levels down from them. That is why this example is crucial in demonstrating how important it is that the project manager/team, who should know such details:

  1. Understand the desired benefits of the work;
  2. Understand how the components/work items are aligned with those benefits;
  3. Understand the relative priorities of those components/work items in monetized value-added terms (i.e., the VBS);
  4. Understand the monetized value/cost of time on the project/program;
  5. Perform critical path analysis up front and periodically during execution, including
  6. Computation of critical path drag and drag cost; and
  7. Ensure that no work is costing more than the value it is adding.

The sponsor/customer/program manager will not have this information; only the project manager and team will. Therefore it is of utmost importance that the sponsor/customer/program manager ensures that the project manager and team have the information, knowledge and skills (each as enumerated above) to ensure that the desired benefits are generated without wasted effort and money.

Unfortunately, what percentage of sponsors/customers/program managers know how to do this?

In my next blog article, I plan to show how to use the VBS information in combination with schedule data in a network diagram that includes critical path drag, drag cost, and true cost to determine when an optional activity goes from value-added to value-subtracted.

Fraternally in project management,

Steve the Bajan

First Amendment to Current PM Practice: All Projects are Investments

My recent blog article, “Ten Amendments to the Current Practice of Project Management,” has experienced such positive feedback that I’ve decided to follow it up with articles that explore each of the “amendments” in more detail. This article will explore my proposed:


Amendment 1: Get agreement from everyone (team members to senior management and customers) that projects are investments.


In Greek mythology, Athena sprang fully formed from the head of Zeus. However, few things come into existence fully formed, either from someone’s head or anywhere else. Philosophies, science and practices all tend to evolve over time, modified to meet changing conditions and needs.

How well I remember when the first edition of the PMBOK® Guide was published in 1996. I had been teaching corporate classes in project management for eight years. Occasionally an attendee would skeptically assert something like: “Who says we have to use this WBS thing?” (Or CPM thing or earned value thing.) “We do a task list and that seems just as good to me.” And then I’d have to explain why a hierarchical chart offered benefits a task list didn’t: summed data, templates, easy modification, etc. Sometimes they were persuaded and sometimes they weren’t.

The first PMBOK Guide changed all that. Suddenly I could point to an authoritative compendium of “best practices” and say: “Well, here is the way that many of the most experienced organizations are doing it.” Besides, it was now in a book, all beautifully bound – that fact alone carried much more authority than anything little Stevie might say!

Because something is not in a specific edition of the PMBOK Guide (for a current example, critical path drag and drag cost), it doesn’t mean that it won’t be in four or eight years. First, although so many people insist on calling it the PMBOK, it is the Guide to the project management body of knowledge! Second, even as a guide, it must evolve or risk obsolescence as the needs of the project world change.

Until that first edition of the PMBOK Guide was published, there was little agreement even on what a project is. What separates a project from other types of work (e.g., manufacturing, or retail, or hotel operations)? Thence came the two adjectives in the current definition of a project:

  1. Temporary”, as opposed to an effort that continued unchanged day after day and perhaps year after year; and
  2. Unique” to describe the output of a project, as opposed to manufacturing a million identical widgets.

But the real problem comes with defining a project as an endeavor. What exactly is an endeavor? The American Heritage Dictionary defines endeavor as: “1. A conscientious or concerted effort toward an end; an earnest attempt. 2. Purposeful or industrious activity; enterprise.”

So what does that mean? Endeavor is one of those nebulous words, applicable to many different types of activity. If I jump to touch the ceiling fan, that’s an endeavor. So too is trying to fall asleep at night, walking through the park, or getting a date with that attractive neighbor. But are all of these projects? And should we necessarily study the PMBOK Guide before approaching the neighbor?

Suppose we were trying to describe ice hockey to a visiting Alpha Centaurian. We might say: “It’s an endeavor we earthlings undertake that involves hitting a hard rubber disk with bent sticks across a surface of frozen water toward rectangular frames with nets while wearing boots with blades at the bottom.”

Nothing we have said above is untrue – but would our visitor have any sense of what ice hockey really is? Or why we undertake this “endeavor”? Until we use a more precise word like game or sport or contest (“game” is the second word in the American Heritage Dictionary’s definition), our Alpha Centaurian would have little idea of the essence of ice hockey or why so many Canadians love it.

What kind of endeavor is a project? It’s an investment. Every project is. No one ever funds a project unless they expect the eventual product, service or result to be worth more (to them!) than the expected invested amount. And while there may often be cost and time constraints on projects (we may only have so much money available to invest, and if we don’t finish it before New Year’s Day it will become worthless) and value drivers that seem less tangible (loss leaders, good publicity, enabler projects, etc.), the ultimate determinant of success is, as with every investment, a relative one: how much more (or less!) value did it generate than it actually cost, i.e., its profit.

When a project finishes, we rarely know its actual value – that may take years to determine. The same is true of many other investments. But we should manage all our investments in ways designed maximize their profits (i.e., their expected project profit, or EPP). And that should be based on quantified decision-making across the variables of:

  • Scope (which generates the value);
  • Time (which almost always impacts the value of the scope, positively or negatively);
  • Cost of resources (which drives the invested amount); and
  • Risk/opportunity (which can impact any or all of the other variables).

All this is discussed in this November blog article Turning Iron into Gold! and in much greater depth in my book Managing Projects as Investments.

But all the metrics, techniques and tools must necessarily follow from the understanding of the essence of a project. To do otherwise is to participate in ice hockey without understanding its essence as a game. Once the customer/sponsor starts to define their project as an investment (which, by the way, most understand intuitively if not explicitly), they will start to rely on typical investment metrics like ROI and profit. And those metrics should, in turn, drive the tools of project management: not just WBS and CPM and earned value, but their investment-based extensions: value breakdown structure (VBS), critical path drag and drag cost, the DIPP and DIPP Progress Index (DPI), and who knows what further advanced techniques that others may develop in the future?

I would love it if senior managers and sponsor/customers would suddenly become aware both of the importance of managing projects as investments and of the appropriate tools that can be used. But the most likely way for this to happen is through the project management community itself: those who “labor in the fields” to start marketing their services as customer-centric, benefits-based and investment-driven. After all, those are the things that customers want – they just don’t know how to get them!

But the project managers, and project management consultants and companies, who do comprehend them can work to reach that initial understanding with the potential client. Then they can win assignments and contracts that they otherwise mightn’t, because the client now understands the investment approach and wants this kind of “client-benefit-based” project management that is being offered. A persuasive enumeration might include:

  1. “We approach your projects as investments.”
  2. “We want to collaborate in determining the factors that drive your benefits and value.”
  3. “We will provide you with project progress metrics that are based in those factors.”
  4. “We will use our innovative techniques to maximize your ROI on the investment.”

From my own experience, I have found that an approach that starts with the MoSCoW method of prioritization and uses it to build a VBS for the customer’s values can be very impressive and persuasive.

And finally, the standing of the project manager, and of our whole discipline, will rise dramatically if projects are redefined as investments. Instead of being viewed as overhead on a cost center, the project manager will become a valued leader of a profit center, maximizing benefits-above-cost through their knowledge, experience and decision-making. And I think that’s a pretty good deal for us.

Fraternally in project management,

Steve the Bajan