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.
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:
- Designing the product.
- Testing a prototype.
- Manufacturing the products.
- Developing documentation for the products.
- Developing training for the products.
- Developing advertising.
- Running the ads.
- Setting up support.
- 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 cost – not on the final ROI of the program. Final ROI should be the program manager’s performance metric.
All this means that program managers must:
- 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.
- Work with the project managers to ensure that the scope of each project will serve its purpose in adding value to the program.
- 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