Managing the Program and the Project: What’s Similar, What’s Different?

My previous blog article of March 27th, “Project Investments Are Whole-System Efforts and All Levels Must Play Their Parts,” stated the proposition that all levels of management engaged in project work have a specific role to play. If at any level there is ignorance or incompetence, the result will be substandard project results, in the form of decreased value and reduced benefit to the organization.


To some extent, project work is like an onion: a project contains lots of smaller work packages which contain lots of smaller activities. But the project is usually part of the onion, too, one of many projects that are part of a larger program. And one key activity, performed incompetently, can destroy an entire program, causing delays and/or quality issues that cut deeply into the intended benefits for which all the work was undertaken. I suspect that the vast majority of those who worked on the Kansas City Hyatt Regency Hotel did a good job—but that didn’t stop the structural design flaw from destroying the project and killing 114 people.

KC Hyatt Regency collapse

People frequently have trouble understanding the distinction between a project and a program. They often describe work as being part of a project when it’s clearly an entire project within a program. The Glossary of the Fifth Edition of the PMBOK® Guide gives the following definitions (p. 553):

Project: A temporary endeavor to create a unique product, service, or result.

Program: A group of related projects, subprograms, and program activities managed in a coordinated way to deliver benefits not available from managing them individually.

Other than the important (in my opinion!) omission of the word “investment”, these definitions are appropriate – a project is undertaken to deliver a product, service or result that is intended to lend value to the other work within the program.

  • The job of the program manager is to ensure that the program delivers benefits and creates maximum value for the investment.
  • The job of the project manager is to deliver a product, service, or result that best supports the program’s value creation.

The program manager selects the projects that must be done to ensure optimum value creation. Separate projects may include:

  1. Designing the product.
  2. Testing a prototype.
  3. Manufacturing the products.
  4. Developing documentation for the products.
  5. Developing training for the products.
  6. Developing advertising.
  7. Running the ads.
  8. Selling.
  9. Shipping.
  10. Training
  11. Setting up support.
  12. And other work.

When all is said and done, the value that the program generates is squarely on the shoulders of the program manager. And therefore the failure of a single project to play its intended role in the program’s value creation is also the failure of the project manager. This strongly suggests that the program manager must have authority to create projects and to dismiss and replace unsatisfactory project managers. After all, the ROI of the entire investment is on that individual’s shoulders.

Unlike a project, where much of the scope and much of the schedule is clearly mandated (to build the robots that the design team conceived, for our project we have to get the materials and equipment, then build the parts, then assemble the parts, then install the circuits, then…), the scope of the program is much more discretionary. The program manager needs to know how to select, plan, schedule and direct the scope, schedule and cost of the needed projects.

The projects within the program are selected on the basis of their expected value-added within the program. And that means that a value breakdown structure (VBS), a very useful tool at the project level where it denotes the value-added of optional work packages, becomes vital at the program level where it denotes the value of optional projects, because almost all the projects in a program will be optional and therefore project selection criteria must be based on the value-added!

The timing of the projects within the program is also much more discretionary. Unlike with a project, where all project work usually concludes and then the product is deployed, programs often involve “staggered” deployments: some modules, some marketing, some geographies before others. (And yes, if some readers are thinking that this sounds a lot like an agile software development methodology, it is: agile development often morphs into a series of projects within a single program.)

The scheduling of these projects and deployments often requires a process very similar to critical path scheduling on a project. But whereas a project schedule is driven by logic, and logical dependencies, where D cannot occur until A and B are finished and C is 20% finished, at the program level the sequencing of projects is (a) much more discretionary and (b) must be based on maximizing the value of the entire program!

Each project in the program is selected because it is expected to increase the program value. And the value of many of the projects will be “kindled” by the other projects and work – if we produce a great product, it may be worth very little without advertising, or if our marketing campaign is bad. Those issues are the responsibility of the program manager, but not of the project team that created our wonderful product – that project manager has no control over the marketing process, and so no responsibility for its failure. Which is why project performance can only be judged on the basis of expected monetary value (EMV) and expected project profit (EPP) dependent on scope (including quality), completion date and costnot on the final ROI of the program. Final ROI should be the program manager’s performance metric.

All this means that program managers must:

  1. Select and sequence projects (and non-project work) with careful consideration given to maximizing value (and sometimes minimizing risk). This means careful identification and planning of enabler projects whose scope will enable and kindle the value of other program work.
  2. Work with the project managers to ensure that the scope of each project will serve its purpose in adding value to the program.
  3. Stipulate scope/cost/schedule performance and progress metrics for each project team on the basis of maximum value-added (and the DIPP!). This almost always means large delay costs and/or acceleration value for enabler projects, as the value generation of the other projects they are enabling is dependent on the enabler project!

I will explore the unique nature of those enabler projects within a program in my next article.

Fraternally in project management,

Steve the Bajan

Project Investments Are Whole-System Efforts and All Levels Must Play Their Parts

There’s been a good deal of conversation on LinkedIn discussion groups regarding some of my recent blogs. Many good comments have come in the Managing Benefits group. I strongly recommend that group for those who feel, as I do, that too often projects do not generate the intended benefits.

Whose fault is it that project effort is so often wasted?

  1.  Is it due to project managers who care only about delivering a product or service on time and on budget?
  2. Or is senior management, either the sponsor/customer or other senior managers, to blame for not performing their roles adequately?
    • For failing to itemize the specific desired benefits?
    • For not ensuring the product scope will deliver those benefits?
    • For omitting the necessary clauses and language in a contract that would provide incentive to the contractor to ensure customer value?
    • For failing to oversee the project manager in the project team to deliver the most beneficial product?
    • Or perhaps for setting impossible goals, guaranteeing that the team will engage in a “death march” project and take risks that ultimately lead to poor quality and/or costly and delaying rework?
  3. Or is it the fault of the PMO, that artifact that new executives like to create and then staff with inexperienced personnel whose main role often seems to be to encumber project managers with administrivia, and which will be disbanded as soon as the next cost-cutting regime takes charge? (Please don’t misunderstand: I absolutely support the establishment of competent PMOs that add genuine value – it’s just that, in my experience, such institutions are rare.

The answer, of course, is that all of the above are to blame! Management of projects is a whole-system function – ignorance or incompetence in any part will result in the dysfunction of the entire enterprise. And that means that all levels of the organization, from executives to program managers to project managers to team members to the PMO to contracts to finance to HR… all have a role to play in making projects more beneficial.
This starts with unanimous recognition that ALL projects are investments. It continues through each of those levels and functions needing to understand certain fundamentals of project management (like why the critical path and critical path drag are so important!). And it ultimately requires that each of those roles and functions perform their jobs in supporting those project investments, and be critiqued and measured in terms of their value-added (or value-subtracted!).

I returned from vacation yesterday (which explains why there haven’t been any new blog articles during the past week). But over the next few weeks, my intention is to delve deeper into the process of how those management levels and departments must perform their roles in support of projects. Specific topics, in no particular order, will include:

  • The project within the program.
  • The nature and importance of enabler projects.
  • The value/cost of time on enabler projects.
  • The value breakdown structure (VBS).
  • The true cost of activities, and those with negative value-added.
  • The responsibilities of a PMO that wants to add value.
  • The difference between resources on and off the critical path.
  • The pernicious effects of contracts which don’t align customer and contractor benefits.

Do these topics sound interesting to you? If so, I hope you’ll come and read these, and leave some comments.

Fraternally in project management,

Steve the Bajan

Bill Gates is Right about Epidemics! And Project Management is the Answer!

Gates has an article in today’s (March 18, 2015) New York Times titled “How to Fight the Next Epidemic: The Ebola Crisis Was Terrible. But Next Time Could Be Much Worse.” Whether it’s his businessperson’s experience with urgent projects or simply commonsense, much of what he points out is similar to what I have been saying for many years: the standard project management techniques we use in planning projects worth a few $100K are being ignored in preparing for emergencies worth thousands and millions of human lives!

Gates starts his article with: The Ebola epidemic in West Africa has killed more than 10,000 people. If anything good can come from this continuing tragedy, it is that Ebola can awaken the world to a sobering fact: We are simply not prepared to deal with a global epidemic… Of all the things that could kill more than 10 million people around the world in the coming years, by far the most likely is an epidemic.”

That is completely accurate. But should we say that the hundreds who died unnecessarily because of the slow response after Hurricane Katrina, or the thousands that would die after a major Bay Area (or Haiti!) earthquake, or even those ten thousand Ebola victims in West Africa aren’t important because they don’t number in the millions? Because as Katrina showed, we are also unprepared for even more mundane disasters.

Gates continues: “The problem isn’t so much that the system didn’t work well enough. The problem is that we hardly have a system at all… (O)nce it became clear that a serious emergency was underway, trained personnel should have flooded the affected countries within days. Instead it took months.”

It took months. On a corporate project, time is money. On an emergency response project, time is human lives. Unfortunately, as deficient as the project management discipline is at estimating the dollar cost of critical path delay, estimating the mortality cost for time is even less practiced. And the process of project scheduling to reduce mortality is totally unknown by most planners in non-corporate, non-military disciplines, especially healthcare in general and public health in particular.

This has been a big issue for me for a long time. I am happy to help manufacturers and software distributors and banks and insurance companies improve their project skills and results – I believe that improved efficiency in pretty much any industry benefits everyone. But my heart sinks at the thought of how many people die every year due to project management incompetence in other fields.

In my new book Managing Projects as Investments: Earned Value to Business Value, I use as one example an immunization program, and show how critical path analysis, utilizing critical path drag and with drag cost measured in human lives, can potentially reduce mortality significantly. Another example is in my chapter “Time is a Murderer: The Cost of Critical Path Drag in Emergency Response” from the Handbook of Emergency Response. The chapter is provided here on my website with the permission of the publisher, CRC Press. That example is based on response to an earthquake, where victims lie trapped in the rubble and every passing hour leads to more deaths.

But the process of optimizing a critical path is essentially the same whether the effort is to implement a new corporate ERP system or to save lives after an earthquake or a disease epidemic.

Just for the record, here are some suggested steps:

  1. Prepare generic plans for each genre of emergency response in WBS template form, with as many templates as seem appropriate for different types of emergency.
  2. Itemize the resources needed for various levels and types of epidemic.
  3. Establish roles and responsibilities, with a database of those individuals from which the appropriate personnel would be selected, immediately informed, and then replaced if they are not available.
  4. Optimize the schedules for these templates so that the aid/suppression effort reaches the critical area with the critical resources as fast as possible.
  5. Train key headquarters personnel to customize, as quickly as possible, the WBS template to the incoming information as to the specific nature of the emergency. As Bill Gates points out in his article, each epidemic and each locale will require somewhat different reactions. But that’s little different from professional services organizations that use WBS templates for systems deployments and then customize them for each specific implementation, pulling off unnecessary branches, twigs and leaves and occasionally adding a unique twig here and there. When it’s a bubonic plague outbreak in a Western city, the headquarters personnel would quickly create the appropriate plan for a contagious disease, with a known treatment protocol, in an urban environment in a Western country. And the appropriate activities would populate the plan, complete with resource needs and schedule, and the plan would immediately be disseminated to the appropriate personnel.
  6. Finally, train and practice, practice, practice! Train all personnel to understand a WBS and a precedence Gantt chart. And then periodically conduct exercises, consisting of:
  • Reports reaching headquarters with only partial information;
  • Requests for specific additional information;
  • Selection/customization of the template;
  • Dissemination of the customized plan; and
  • Implementation of whatever team actions are deemed appropriate, including assembly of personnel and equipment.

This is all standard project management procedure. I sincerely hope that Mr. Gates’s article (which I urge you to read) will stimulate epidemic response plans based on such processes.

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

In PM and in Sports, the Metrics Beget the Tactics

In 2004, Michael Lewis’s bestselling book Moneyball: The Art of Winning an Unfair Game revealed how the Oakland Athletics general manager Billy Beane was consistently able to field one of the best teams in baseball by applying new metrics that better model the essence and goals of the sport. In 2011 the book was made into the Oscar-nominated movie Moneyball starring Brad Pitt as Beane.

Although the book and movie deal with baseball, the same principles apply to any endeavor: cricket, football, investing… and yes, project management. The metrics we use must reflect what we are trying to achieve.


Beane got his methodology from the work of sabermetrician Bill James. I had started reading James’s work in 1982 with his 1982 Baseball Abstract (now $177 for a used copy). In the fourteen hours it took me to read all the statistics and explanations in that book, I came to realize that I had never previously understood baseball, despite my almost-fanatical devotion to following the sport and its statistics.

What James pointed out is that the essence of major league baseball is making money, and making money is almost identical with winning games – you win more games, you sell more tickets, you charge more for advertising billboards, and you generate more television revenue. Therefore every tactic, every player, every decision should be measured in terms of its impact on a team’s win/loss percentage.

Baseball statistics in the early 1980s were hopelessly outdated. Batting average was still considered the prime metric of a hitter’s performance (the player who leads the league in that statistic is still called the “Batting Champion”!). But batting average ignores things that contribute greatly to winning games, such as a batter’s walks and extra base hits like home runs.

The result was that, prior to James’s new approach, players with high averages but little power who never walked, like Bill Buckner, were regarded as stars, while much better players like Fiore Gino Tennaci, whose low batting average was far more than offset by his walks and home runs, were often dismissed as mediocre.

Once Billy Beane recognized the importance of James’s approach, he used it to far better assess talent. He stocked up on players who were undervalued by traditional statistics but who actually contributed to winning games. And the result was that, with a much smaller player salary budget than the New York Yankees, Beane was able to build teams that could compete with the big money teams on an even basis. That is, until the big money teams also started using the same techniques and the wealthy Boston Red Sox, with James as an adviser, won the championship for the first time in 86 years in 2004. And they’ve won it twice more since.

What has all this to do with project management? Like batting average in baseball, the metrics we use to measure project performance and to categorize a project as a “success” “or “failure” are deeply flawed.

Baseball is a sport, and its metrics need to be based in the winning or losing of games. Projects are investments, and their metrics need to be, like all other investments, based in creating value above cost, i.e., ROI or profit. The batting average statistic tells us something about a baseball hitter – but disconnected from data about wins and losses, it suffers from distortion. So too traditional PM metrics, such as on time and within budget, tell us something about project performance – but disconnected from the expected monetary value (EMV) of a project, and its expected project profit, they too are subject to distortion. Which would you rather have – a project that creates an adequate product on time and on budget or one that is even more fine-tuned to the needs its intended to address, that is deployed earlier and costs less?

This discussion in the LinkedIn Managing Benefits group led to me mounting my Moneyproject: Metrics, Baseball and Project Management Powerpoint slides under the PRESENTATION tab on my website home page. There also is an article titled Moneyproject that I published in 2006 at as part of a six-article series on the basics of the Total Project Control methodology. I hope you will check these out when you get the chance.

But meanwhile, in the LinkedIn discussion Jed Simms points out some crucial factors. He writes:

“It is a poor manager who only measures ‘project success’ in terms of ‘profit’.”

He’s correct. Projects frequently aren’t intended directly to generate profit – but they must always be designed to generate benefits. These can then, through the rest of a program and/or other projects, generate further value that eventually becomes revenue, savings or non-monetary benefit. That benefit is the core of the effort and must be quantified in terms of its “expected value”. And I call the expected value of a project minus its expected cost its “expected project profit” (EPP). Someone may call it something else, but it seems to me that the term I use is an appropriate one. And its “expected” because, as with all investments, the future is unknown.

Jed continues:

“The existing project mgt tools are good for delivering projects (outputs/deliverables/products) but NOT for delivering a project investment.:

That’s the crux of it, isn’t it? Why would they be? A project is not defined as an investment – even though every project is one! Not only is the old adage about getting what we measure an accurate one, but the tactics the “performers” use are designed to reflect well on them through those metrics – and who cares about those externalities that we don’t measure?

Jed also writes:

“Use of project mgt tools alone is very wasteful in lost opportunities and returns… It is a poor manager who only measures ‘project success’ in terms of ‘profit’.”

And again he is correct. The metrics are the way we judge performance – and inadequate metrics beget inadequate tools.

But new and better metrics will generate better tactics. In baseball, techniques like bunting and hit-and run plays have decreased in frequency because better metrics show that they usually reduce the number of expected wins for a team. Instead, hitters who take lots of pitches, drive up pitch counts and get lots of walks are now highly valued.

Similarly, better project metrics that assess the value/cost of time and determine the drag of critical path activities can show where spending an extra $40,000 for a resource will reduce an activity’s drag cost by $100,000. A value breakdown structure (VBS) will quantify the value of optional work and show where the drag cost of an activity that has migrated to the critical path makes it no longer worth its inclusion. The tools will always follow the measured and demonstrated need. And once the overall approach is accepted, practitioners will add more and more tools to the toolbox.

It took almost thirty years for Bill James’s approach to become standard operating procedure in major league baseball. The first edition of Total Project Control was published just 16 years ago. But slowly, its techniques are beginning to have an impact.

Have a great weekend!

Fraternally in project management,

Steve the Bajan

Expansion on Amendment #10: The ABCP in the Project Postmortem

A discussion of the blog article directly below, “Ten Amendments to the Practice of Project Management,” has started in the LinkedIn forum “The Project Manager Network”. One reader, Bob, wrote:

“Interesting points. I like number 10 and including the as-built critical path (ABCP) as one of the key artifacts for lessons learned. I assume the lessons learned would include a discussion of the discrepancies between the as-built versus the as-planned critical path.”

He is exactly right. In terms of schedule, the postmortem should focus on the changes/variances from Version 1.0 to Version Complete, showing what triggered the changes and why the specific change was selected (were there other alternatives; what would have been their impacts; and why were they declined?).

Some frequent (but not all!) reasons for changes would include things like:

  • Simple delay (or acceleration!);
  • Resource unavailability;
  • “Dropped batons” at handoffs;
  • Scope changes (ECPs, rework or scope pruning);
  • Altered work sequence (approved or “extemporaneous”, the latter of which should be avoided);
  • Risk/opportunity factors (actualized, retired or newly emergent); and
  • Black swans“.

The ABCP analysis should measure the impact(s), assess the decision(s), and design/create a Lessons Learned database organized by the specific factors to allow future planners of similar projects to account for the potential of some of these variances to infect future projects and perhaps to develop workarounds.

One very important output should be identification of the delays due to resource insufficiencies and how much they impact expected project profit. This not only identifies those resources that may appear again and again on the critical paths of our projects, but also measures their drag and drag cost. A Pareto chart of such data would thus allowing senior management to see that spending an extra $350,000 per year for two additional fulltime hobbits would be more than justified by the amount it would save in drag cost on eight different projects in the next year (even, by the way, if those two hobbits are only being utilized at a 50% rate, but that 50% is almost always on the critical path!). (I describe this in detail in my book Managing Projects as Investments: Earned Value to Business Value.)

ABCP analysis is one of those project management techniques/ideas that seems to be applied in only one industry (construction), but that might have value in many others. A few other techniques that I’ve come across that might be extended to other industries include:

  1. Strict measurement of the cost of time (nuke plants and refinery maintenance).
  2. Frequent and close communication with customer/users (IT, S/W, “agile”).
  3. Managing to high-level milestones (toys and other retail development efforts).
  4. Parallel development efforts to find a suitable solution, and pursuing whichever gets “there” first (pharma and medical device development, but there are other examples from the Second World War that are shown in the The Imitation Game‘s Enigma code-breaking project and in the television series Manhattan, about America’s atomic bomb program.

Manhattan and Imitation Game posters

Not all techniques that arise in one industry can or should be used in others. But my experience with numerous industries over the past quarter century suggests that there is value in project managers becoming aware of ideas and techniques in other industries – too often I see project managers who assume that the only world that exists is software, or construction, or government contracting. Organizations like PMI and IPMA can help greatly with this as long as they resist becoming too dominated by any one discipline.

Fraternally in project management,

Steve the Bajan

Ten Amendments to the Current Practice of Project Management

I believe that project management is, in many ways, failing in what should be its purpose: to provide a valuable return to the investor(s) who provide the resources/money for the project effort and who hope to reap the benefits. But I don’t happen to feel that we need a whole new methodology. The basic tools in our toolbox (WBS, critical path analysis, resource leveling, activity-based resource assignments, earned value tracking) are wonderful techniques, and are being efficiently applied by many project managers.But in many other cases, projects are generating much less value than they should.

I do believe that some of the tools, as valuable as they are, need what I’d call “amendments”: sharpening, enhancing or re-shaping for wider utilization – such as the routine incorporation of the drag metric as a standard part of critical path analysis. But the major flaws, I believe, are not so much in the tools as in how they are being misunderstood and misapplied.

I‘ve been thinking for some time about preparing a list of “Amendments to Current Project Management Methods”. Below is a pretty barebones outline, without getting into a huge amount of explanation (because I just wrote a 255-page book that pretty much provides that!), which lays out some of the techniques and modifications that I feel would significantly improve the way we do projects.

This list will probably evolve over the months ahead (and I’m certainly willing to entertain other suggestions), but the Ten Amendments below ain’t bad for a start:

  1. Get agreement from everyone (team members to senior management and customers) that projects are investments.
  2. Get them to agree that investments should be undertaken for the value they are expected to generate.
  3. Get them to understand that the value/benefit they expect from the project will be based on its scope (mostly product scope) and that therefore the specifics of the product scope should designed with those benefits in mind. [This should lead to the creation of a value breakdown structure (VBS)].
  4. Get them to agree that the results of all investments are not guaranteed, but rather involve estimates, uncertainty and risk. Explain that “deadlines” and fixed cost caps (“budgets”) are arbitrary strictures that are far more likely to cause negative behaviors (e.g., Parkinson’s Law, or secretively cutting quality to meet deadline/budget, or simply taking unwarranted risks when pushed for time/cost adherence) than to have magically made an accurate prediction of what the project would really require. Suggest instead getting the organization used to the terms “target date” and “target cost”.
  5. Get everyone to agree that, the vast majority of the time, project delivery date has a big impact, positive or negative, on the expected value of that scope. This should lead NOT to a deadline, but to an estimate of the value/cost of each unit of time earlier OR later than the target date. And this quantified estimate should be a part of the initiation documentation of every project! And any contract for a project should include clauses establishing incentives (positive and negative) for schedule performance, aligning as much as possible the potential benefits to customer and contractor.
  6. Show everyone how, with the expected value of scope, the value/cost of time, and resource usage all quantified in monetary terms, the three sides of the “Iron Triangle” are now all integrated and monetized so that it has become the Golden Triangle. Any variance in any side will have a quantified impact on the integrated value of the project as measured by expected project profit (EPP) and the DIPP. Show how this now provides a single metric against which project performance can be tracked, with better performance being measured not just in schedule or cost terms, but in what should matter to everyone and particularly to those funding the project: investment value, or ROI, or expected project profit!
  7. Ensure that everyone understands that every project, no matter how it is scheduled, will be precisely as long as its longest path of activities, logical constraints, resource constraints, delays, rework, sprints, and stumbles! And therefore no matter how it has been scheduled, critical path analysis that includes drag, drag cost, and true cost (TC = drag cost plus resource costs) computation must be performed, seeking opportunities to reduce drag costs and thus accelerating the schedule where greater project profit can be generated. Everyone should also understand that the value/cost of time on enabler projects (i.e., those that enable other projects to generate value) go through a multiplier effect, and thus identify such enabler projects and their elevated value/cost of time.
  8. Ensure that both time-limited and resource-limited resource leveling is performed on each project, and on all projects (and especially prospective new projects!), within the portfolio of a multiproject organization. The data regarding the cost of delays caused by insufficient availability of each specific type of resource should be analyzed on an organizational basis at least quarterly, with Pareto charts assembled to identify and quantify the project delay costs to the organization of resource insufficiencies on the critical paths, and to improve efficient levels of staffing for each resource type and functional department.
  9. Ensure that everyone understands that earned value is not about project value, but about project cost, i.e., resource usage! The term has been the source of persistent confusion. Even to a contractor, project value almost always includes value drivers that are not part of the price/budget. On a medium sized project in an organization without robust financial tools, earned value planning and tracking can be performed adequately on the basis of planned and actual labor hours. (Indeed, CPI-Labor should be an important metric in any EVM system.) Everyone also should know that earned value is inadequate for schedule tracking, at least in the way it is customarily applied, and can lead to incentives for out-of-sequence and noncritical work. Schedule must be tracked through critical path tracking and/or by developing a separate earned value baseline for schedule tracking that takes into account the critical path by being scheduled on the late dates.
  10. Ensure that project postmortems are performed on all significant projects (not just on those that went badly!) and that the as-built critical path (ABCP) is presented as one of the key artifacts for lessons learned, particularly in identifying causes of project delay with their quantified costs. And that every postmortem sets a future date on which the data on the mature final product can be analyzed with greater knowledge and objectivity so that current assessments of quality, durability, and value (including revenues/savings) can be updated.

Okay, so at least that’s a start. And I think implementing these would make a huge difference. So anyone have additional suggestions?

Fraternally in project management,

Steve the Bajan

Weekend Puzzler: Earned Value & the DIPP Exercise

Most project management people are familiar with the basics of earned value. But as I plan to blog about this topic in the next few weeks, I thought I’d introduce it with some fairly simple multiple choice questions for the weekend. (These are the sorts of questions my graduate students are asked on tests.)

You can see the answers by scrolling down beyond the test.

Have a great weekend!

Fraternally in project management,

Steve the Bajan


For Project Steel Donkey, the budget is $12 million and the expected monetary value (EMV) is $20 million if completed in 50 weeks, generating and expected project profit (EPP)of $8 million. Every week or part thereof later will reduce the EMV by $500,000 and every full week earlier will increase the EMV by $200,000.

At the end of Month 6, the planned value (PV or BCWS) is $5.0 million. The earned value (EV or BCWP) is $4.5 million. The actual cost (AC or ACWP) is $5.5 million.

  1. What is the schedule variance (SV)? (a) – $1.0M (b) – $0.5M (c) $0.5M (d) $1.0M (e) None of the above
  2. What is the simple schedule performance index (SPI)? (a) .80 (b) .82 (c) .85 (d) .90 (e) None of the above
  3. What is the cost variance (CV)? (a) – $1.0M (b) – $0.5M (c) $0.5M (d) $1.0M (e) None of the above
  4. What is the cost performance index (CPI)? (a) .80 (b) .82 (c) .85 (d) .90 (e) None of the above
  5. What is the critical ratio CPI (CRCPI)? (a) .72 (b) .74 (c) .76 (d) .90 (e) .91
  6. Assuming the SPI is accurate, what is our current estimated schedule overrun? (a) 2.3 weeks (b) 3.4 weeks (c) 4.5 weeks (d) 5.6 weeks (e) 6.7 weeks
  7. Assuming the SPI is accurate, what is our current estimated delay cost? (a) $1.5M (b) $3.0M (c) $4.5M (d) $6M (e) None of the above
  8. Assuming the simple CPI is accurate, what is our current cost estimate-at-completion (EAC)? (a) $12.0M (b) $12.6M (c) $13.5M (d) $14.6M (e) None of the above
  9. Assuming the simple CPI is accurate, what is our current cost estimate-to-complete (ETC)? (a) $6.5M (b) $7.1M (c) $8.0M (d) $9.0M (e) None of the above
  10. Assuming the critical ratio CPI is accurate, what is our current cost EAC? (a) $15.2M (b) $16.2M (c) $17.2M (d) $18.2M (e) None of the above
  11. Assuming the critical ratio CPI is accurate, what is our current cost ETC? (a) $9.7M (b) $10.2M (c) $10.7M (d) $11.2M (e) None of the above
  12. Assuming the simple CPI and SPI are accurate, what is our expected project profit (EPP) at completion? (a) $2.4M (b) $2.6M (c) $2.8M (d) – $2.8M (e) None of the above
  13. Assuming critical ratio CPI and SPI are accurate, what is our expected project profit (EPP) at completion? (a) – $.08M (b) – $0.4M (c) $0.4M (d) $0.8M (e) None of the above
  14. What is our planned DIPP (DIPP = [$EMV plus or minus $acceleration premium or delay cost] divided by $Cost ETC) at the end of Month 6? (a) 1.80 (b) 2.0 (c) 2.40 (d) 2.80 (e) None of the above
  15. What is our Actual DIPP at this point based on the CPI and SPI? (a) 1.80 (b) 1.87 (c) 1.97 (d) 2.07 (e) None of the above
  16. What is our DIPP Progress Index (DPI) at 6 months (DPI = Actual DIPP divided by Planned DIPP)? (a) .65 (b) .75 (c) .85 (d) .95 (e) None of the above

If we identify an activity in our project where spending an extra $1.0M would erase 4 weeks of critical path drag

  1. What would our expected project profit become using the simple CPI and SPI? (a) $0.4M (b) $1.4M (c) $2.4M (d) $3.4M (e) None of the above
  2. What would our expected project profit become using the critical ration CPI and SPI? (a) $1.4M (b) $1.8M (c) $2.2M (d) $2.6M (e) None of the above
  3. What would our current DIPP become using the simple CPI and SPI? (a) 1.68 (b) 1.78 (c) 1.88 (d) 1.98 (e) None of the above
  4. What would our DPI be using the simple CPI and SPI? (a) 0.66 (b) 0.76 (c) 0.86 (d) 0.96 (e) None of the above



  1. What is the schedule variance (SV)? (a) – $1.0M (b) – $0.5M (c) $0.5M (d) $1.0M (e) None of the above ($4.5 – $5.0M = – $0.5M)
  2. What is the simple schedule performance index (SPI)? (a) .80 (b) .82 (c) .85 (d) .90 (e) None of the above ($4.5 divided by $5.0M = .90)
  3. What is the cost variance (CV)? (a) – $1.0M (b) – $0.5M (c) $0.5M (d) $1.0M (e) None of the above ($4.5 – $5.5M = – $1.0M)
  4. What is the cost performance index (CPI)? (a) .80 (b) .82 (c) .85 (d) .90 (e) None of the above ($4.5 divided by $5.5M = .82)
  5. What is the critical ratio CPI (CRCPI)? (a) .72 (b) .74 (c) .76 (d) .90 (e) .91 (.90 * .82 = .74)
  6. Assuming the SPI is accurate, what is our current estimated schedule overrun? (a) 2.3 weeks (b) 3.4 weeks (c) 4.5 weeks (d) 5.6 weeks (e) 6.7 weeks (50 weeks divided by .90 – 50 weeks = 5.6 weeks)
  7. Assuming the SPI is accurate, what is our current estimated delay cost? (a) $1.5M (b) $3.0M (c) $4.5M (d) $6M (e) None of the above (6 * $500,000 = $3.0M)
  8. Assuming the simple CPI is accurate, what is our current cost estimate-at-completion (EAC)? (a) $12.0M (b) $12.6M (c) $13.5M (d) $14.6M (e) None of the above ($12M divided by .82 = $14.6M)
  9. Assuming the simple CPI is accurate, what is our current cost estimate-to-complete (ETC)? (a) $6.5M (b) $7.1M (c) $8.0M (d) $9.0M (e) None of the above ($14.6M – $5.5M = $9.1M)
  10. Assuming the critical ratio CPI is accurate, what is our current cost EAC? (a) $15.2M (b) $16.2M (c) $17.2M (d) $18.2M (e) None of the above ($12.0M divided by 0.74 = $16.2M)
  11. Assuming the critical ratio CPI is accurate, what is our current cost ETC? (a) $9.7M (b) $10.2M (c) $10.7M (d) $11.2M (e) None of the above ($16.2M – $5.5M = $10.7M)
  12. Assuming the simple CPI and SPI are accurate, what is our expected project profit (EPP) at completion? (a) $2.4M (b) $2.6M (c) $2.8M (d) – $2.8M (e) None of the above ($17.0M – $14.6M = $2.4M)
  13. Assuming critical ratio CPI and SPI are accurate, what is our expected project profit (EPP) at completion? (a) – $.08M (b) – $0.4M (c) $0.4M (d) $0.8M (e) None of the above ($17.0M – $16.2M = $0.8M)
  14. What is our planned DIPP (DIPP = [$EMV plus or minus $acceleration premium or delay cost] divided by $Cost ETC) at the end of Month 6? (a) 1.80 (b) 2.0 (c) 2.40 (d) 2.80 (e) None of the above ($20M divided by $7M = 2.88)
  15. What is our Actual DIPP at this point based on the simple CPI and SPI? (a) 1.80 (b) 1.87 (c) 1.97 (d) 2.07 (e) None of the above ($17.0M divided by $9.1M = 1.87)
  16. What is our DIPP Progress Index (DPI) at 6 months (DPI = Actual DIPP divided by Planned DIPP)? (a) .65 (b) .75 (c) .85 (d) .95 (e) None of the above (1.87 divided by 2.88 = .65)

If we identify an activity in our project where spending an extra $1.0M would erase 4 weeks of critical path drag…

  1. What would our expected project profit become using the simple CPI and SPI? (a) $0.4M (b) $1.4M (c) $2.4M (d) $3.4M (e) None of the above  ($19.0M – $15.6M = $3.4M)
  2. What would our expected project profit become using the critical ration CPI and SPI? (a) $1.4M (b) $1.8M (c) $2.2M (d) $2.6M (e) None of the above ($19.0M – $17.2M = $1.8M)
  3. What would our current DIPP become using the simple CPI and SPI? (a) 1.68 (b) 1.78 (c) 1.88 (d) 1.98 (e) None of the above ($19.0M divided by $10.1M = 1.88)
  4. What would be our DPI using the simple CPI and SPI? (a) 0.66 (b) 0.76 (c) 0.86 (d) 0.96 (e) None of the above (1.88 divided by 2.88 = .66)

Educating the Boss

As seems to happen periodically, a thread that I started in a LinkedIn discussion group about one of my blog posts has led to a spirited discussion of the problem of getting the project sponsor/customer to fulfill their role responsibly. There are some cogent responses expressed, which I will not plagiarize, but you can find them here. I started to respond within the thread, but then realized that what I’d written was a suitable topic for this blog.

Some opinions in the LinkedIn discussion are very pessimistic: senior management is ignorant and stubborn and will not change. I have certainly come across senior managers whose attitudes would lead to that conclusion. But I’ve also met others who are very smart and positively motivated – they need only a corrected vision of what project management is all about to lead their organizations to the promised land of less chaos and more profitable projects.

And we in the project management community need to provide that vision.

Other opinions in the thread suggest that, faced with impossible project goals, the PM should “manage” the sponsor and set more realistic expectations. I agree. In addition, I believe that whenever possible, the dog should stop its master from walking into the quicksand, the locomotive should slam on the emergency brake if the engineer doesn’t recognize that the track ahead is out, and the cart should lead the horse to water (but it can’t make it drink!).

Cart before horse

Yet in most cases these options are neither satisfactory nor sufficient. The horse will rarely accept being led by the cart. I fear that human societies will always be led by the Golden Rule — whoever has the gold, rules. And the sponsor has the gold.

In general sponsors and senior management are not stupid – but they are uneducated about projects and project management and we in the PM community need to start educating. Currently, the vast majority of senior managers don’t know their elbows from a hole in the ground when it comes to project management, and, as I write in my book, couldn’t find a critical path with both hands and a mirror.

Yet it’s really not their fault. Most have simply not been taught. They’ve been taught other things: marketing and finance and public health and a variety of other specific subjects. As far as I know, no professional PM organization — not PMI, IPMA or AACE — has taken it upon itself to educate senior management and project sponsors/customers. And the “project management” that is taught in the vast majority of MBA programs is, for the most part, laughable.

About six years ago I made a presentation to the Mass Bay Chapter of PMI titled “Project Value Drivers: How Sponsors and Customers Should Enable Value”. The reception among the project manager attendees was so positive that I started thinking about the problem. (If any readers would like me to send them the 26 slides of that presentation, I’ll be happy to – just send me an email.)

Finally, I decided to try to change the situation. I began with my new book Managing Projects as Investments: Earned Value to Business Value which came out last fall. Yes, I believe the new techniques have value for PMs and team members. But this book was also written for senior management. Without getting too much into the weeds, it explains all the value they can get from good processes and knowledgeable PMs, and the organizational procedures that will enable those PMs rather than, as is so often the case currently, sabotage their efforts. Counter-productive procedures like:

#1. Deadlines;

#2. Utilization rates;

#3. Elimination of schedule and cost reserve;

#4. Organizational rejection of, or obstacles to, comp times;

#5. The standard version of the schedule performance index for schedule tracking.

Et cetera.

I believe we have to start by changing the standard definition of a project. Every project is an investment — no one can reasonably dispute that. But projects are not defined as such, planned as such, measured as such or tracked as such.

Small wonder then that senior management and sponsors, who well understand the concept of investments and jump to salute whenever someone mentions the word, fail to recognize the importance and value of good PMs and the need to create a culture and processes that will empower them in maximizing the business value of the investments. Instead of recognizing projects as investments, they all too often regard them as cost centers, and the PMs as overhead on cost centers! (And that’s why good PMs are so often underpaid in comparison to their value.)

These organizational procedures can only be addressed at the organizational and senior management level. But it all has to start with project management itself: with a re-thinking of the essence of every project and program, and then using the techniques and metrics that truly support and reflect good decision-making and management.

I may have chosen the wrong rock to push up the hill, but it is the one I have chosen and, with the book and now this blog, I have started the journey. If someone who looks at this blog and reads my new book disagrees with the approach, I hope they will raise it in the comments right here. I respond very well to constructive criticism, and would also love additional ideas and input. But I hope that anyone who reads the book and likes it will do two things:

#1. Spread the word that this is “not your father’s PM book”, that it contains new ideas, techniques and metrics (some of which we have touched on in other articles here) that can improve our discipline; and

#2. Lend their copy to the boss, sponsor, customer, VP or CEO. (Don’t make them buy their own copy — you know how they can be sometimes!)

Fraternally in project management,

Steve the Bajan

Let the Customer be Aware!


Gary Heerkens’s outstanding column “Imposed Deadline Syndrome” in the March 2015 issue of PM Network (which I discuss in the article just below) has triggered me to think more about the topic of sponsor/customer knowledge and responsibilities. Additionally, some issues raised on the subject in the LinkedIn discussion group The Project Manager Network make me feel it is worthy of a lot more discussion.

First, let’s agree that it is in the interest of everyone – team members, project managers, sponsor/customers, corporate executives, stockholders and taxpayers – that project funds be used as productively as possible. A dollar that has been spent in a way that helps make someone’s life better or longer, in whatever way, is superior to one that fails to enhance the value of the project outcome, perhaps due to poor quality, unnecessary “gold-plating”, bad timing, simple waste or moral hazard.

That said, whose budget/resources/money is it that is being wasted? If an investor buys what turns out to be worthless stock or real estate, or just give their money to an investment manager who is either incompetent or a charlatan, they may have grounds for moral outrage — but they are the ultimate loser. So surely it behooves them to perform due diligence before turning their funds over?

And surely the same is true of the project sponsor/customer? Certainly the management and stockholders of the company or taxpayers of the country, who have entrusted the senior manager or customer with these funds/resources, expect them to invest wisely and carefully. One might say that this is the primary responsibility of every project/program sponsor, and it is a job at which, as Gary Heerkens’s article suggests and I agree, far too many are failing.

Over the years, I have had many thousands of students attend my classes to study project management techniques. Multiply that by the number of teachers/trainers of project management group and we’re probably into the millions every year. But what percentage of the people who attend such classes have as their primary job *at that time* (as opposed to later acquiring such responsibilities) the role of project sponsor or senior management? In my classes at least, the number is tiny.

We can argue about the quality of project management training courses – but surely there is little doubt that project managers and would-be project managers recognize that they need to learn how to manage projects. Do project and program sponsors feel that they were born knowing how to fill those roles? Instinctively understanding how to design the program and project scope in a way that will generate greatest value? How to communicate that information, perhaps via ESP, to the program or project manager to whom they now seem so willing to blithely entrust this crucial function? Were they born knowing how to run a progress meeting? How to write a project RFP and, even more important, ensure that the contract they sign for a project will meet their ultimate needs?

Or is it simply that they don’t care enough about the corporate or taxpayer funds of which they have been made responsible to educate themselves about the fundamentals of projects and programs? Certainly the skill set of a project sponsor/customer is different from that of a project manager – but surely there is a substantial amount of overlap? If I don’t have a solid grounding in the tactics and techniques of football, how can I possibly function as a competent head coach?

While organizations such as PMI and IPMA, as well as graduate programs for university MPM and MBA degrees, focus on the project and program manager roles, the crucial role of the project sponsor is given little attention. (The UK’s Managing Successful Projects (MSP) touches on the subject, but barely more than that.) Why is this? Is it that there is no market for such training/education?

If a chain is as weak as its weakest link, surely the weak link in project and program management is more likely to be where little or no education has been conducted on the needed techniques than where vast amounts of training has been focused for many years.

In writing my recent book Managing Projects as Investments: Earned Value to Business Value, I tried as much as possible to avoid “getting into the weeds” of complex project management techniques. (Some of those I saved for my upcoming book Total Project Control: A Practitioner’s Guide.) Yes, I felt that describing the methods for managing a project as an investment required me to cover the rudiments of critical path, drag and drag cost. But I stuck to simple finish-to-start relationships (the subset of people who need to know about SS, FF, SF and lags/leads being much smaller than those who just need to know what a critical path is). My goal in part was to introduce a new approach, but also to write a book that project managers and team members could get senior managers and sponsors to read without their eyes glazing over. Because if anyone should perceive projects as investments and want to know how to maximize their value, it’s the customer and senior management.

From many conversations I’ve had over the past couple of years, I think that the business world is getting ready to focus on the weak link in project management. I hope that link is about to get much, much stronger.

Fraternally in project management,

Steve the Bajan