Classify Projects by Value Generation Type within a Programme

A few days ago, I published here on LinkedIn an article titled "Managing and Optimizing the Values and Schedules of Projects and Programmes”. You can find it here.

In the discussion thread that followed it, there were a lot of excellent points/questions raised, especially regarding HOW and WHEN projects in a programme generate value. Some of this I covered in my article in PM World Journal published last year, and in the discussion thread I linked to that article.

That article covers a range of topics, but it doesn’t focus on the ways in which a project provides value to a programme, and how that should impact scheduling. So I thought I’d write this follow-up article (especially in response to great comments by Trevor K. Nelson, PhD , Alexander Apostolov , and Josh S. .

Mandatory vs. Optional Work

The original Value Breakdown Structure (VBS) that I conceived of a few decades ago was designed for a project, and it divided activities into Mandatory and Optional categories.

Mandatory activities had to be performed or the project would have no value. Thus every mandatory activity has a value equal to that of the whole project. So a project can have several mandatory activities, each worth the same value as the whole project. Therefore value in a VBS is not additive, in the way that costs are in a work breakdown structure (WBS). (Yes, value is different from cost, which is something I truly wish that whoever changed the name of the EVM term Budgeted COST for Work Performed to Planned VALUE could understand! It should be Planned COST!)

By contrast, Optional activities have only the value that they are adding to the project. If the project is estimated to be worth $1M when completed with all the activities, but only $925K if Activity X is omitted, then Activity X has a value-added of $75K.

A typical project-level VBS will usually indicate that most activities (not all!) are mandatory. But interestingly, it is usually the optional activities that give the project team… well… options, wriggle room! And it is optional activities, especially those with low value-added, that a good project manager needs to keep an eye on if they migrate to the critical path, either during planning or, if the critical path changes, during performance. Why? Because the sum of the resource costs plus drag cost for a critical path activity can sometimes exceed its value-added. The project would be more profitable if you jettisoned that activity!

In a programme-level value breakdown structure (PgVBS), projects should still be categorized as mandatory or optional. But unlike at the project level, a larger number of projects will typically be optional, because the stakeholders choosing the scope of the project have more discretion to choose the scope that they think will increase the value most, and aren’t as constrained by Newtonian physics as at the activity level. (You have to build a foundation, frame and roof on a house, include landing gear, propulsion and both a left and right wing on an airplane, and write, test and debug the software code, correct? Or perhaps not debug? Oops! It may be very valuable--but mandatory?)

One more important note about the mandatory vs. optional distinction: if performing a project under a contract, all scope specified in the contract is mandatory—unless the contract is amended! Which it can be if all parties agree to it! And a customer, who has much less insight into the work than the contractor, would doubtless be very interested if told that an upcoming optional activity’s true cost of work (TCW = resource cost plus drag cost) is now greater than the value it’s adding. A trustworthy project manager’s ethics call for notifying the customer if such a situation might seem to have arisen. What the customer then chooses to do is their call.

Value-added Projects in a Programme

While the mandatory vs. optional distinction is still relevant for projects in a programme, even more important in the PgVBS is to focus on HOW each project brings its value to the programme. This should be a major responsibility of the organization's professional Business Analysts. This analysis can allow the projects to be sorted into three general types, each of which requires special treatment in terms of scheduling and resourcing:

1. Value Generators (VG) which directly generate revenue, reduce mortality, increase literacy, improve safety, or provide whatever benefit/value is driving (or helping to drive) the programme. A VG’s value occurs only after it has been completed, sometimes immediately after and sometimes following an interval. The value may be generated as a one-time burst, a series of periodic bursts, or a continuous flow of value that may be at a steady level, may wax and wane, or may start at a steady level and then slowly decrease over time. Whichever it is, the expected value and how it will accrue must be identified, specified and estimated, so that it can be scheduled and resourced in such a way as to increase its value above cost (where cost is the total cost impact: the sum of the cost of its resources plus how its duration and place in the programme schedule may reduce the value-added of the other downstream value generating or value-adding work).
2. Value Enablers (VE), which must occur in order for other work to be performed. Often, this means in order for another project or operation to start—but sometimes in order for it to add value. Examples include projects to make, hire, or otherwise obtain the resources (including money and workspace) for value-generating, -enabling, or -multiplying projects or non-project work. Obtaining permissions and licenses can often be value enablers. And sometimes a project can be both a value generator and a value enabler. Building a road, rail, bridge, airport, ship or wharf can both generate value and, once completed, enable other work to generate value. And value enablers which enable one or more value generators or multipliers can be the most valuable AND time-costly projects in a programme. The value generators can’t start without them AND delays on them can delay multiple downstream value generators and/or multipliers.
3. Value Multipliers (VM) [which in previous articles I have sometimes called Value Kindlers (VK), but I think Multipliers is a better term] add value to that being generated by other projects in the programme. Some value enablers can also be value multipliers—building a bridge to Prince Edward Island not only enabled much more construction there but also increased the value of such construction. An advertising campaign is probably the most obvious example of a value multiplier, but anything that adds value to programme work can be a value-multiplier: improved design, enhancements, user friendliness, documentation, celebrity marketing participation, quality assurance; all can greatly add to the value of certain programmes. Think of the 1970’s Pet Rock without the value-added provided by the humorous documentation and the packaging (in custom cardboard boxes with ventilation holes and straw bedding).

Scheduling Project Interactions within a Programme

Since some projects in a programme enable or multiply other work and its value, the projects in a programme should be scheduled in such a way as to maximize that value for least cost.

• A value enabler should be scheduled for completion before the project it will enable is scheduled to start. And a delay on the enabler is likely to delay ALL of the projects it delays, thus greatly increasing the cost of delay (i.e., critical path drag cost) on the enabler project.
• Value multiplier projects can’t multiply value of a project that isn’t yet ready to generate value. Thus VM projects should often be scheduled as a finish-to-finish (FF) successor to the VG project whose value they are going to multiply. As an example, a marketing campaign might be planned for the moment when the product is completed and ready for launch.

All these interactions should be scheduled to maximize the programme’s value generation while minimizing its cost.

Conclusions

All projects are investments, and if the programme/project manager, scheduler and team don’t know how and how much value a project within the programme is adding, and how that value would change based on acceleration or delay, they can’t optimize the value through a more efficient schedule, nor allocate resources in an optimum fashion.

This often means optimizing within the individual projects themselves, utilizing critical path analysis that includes critical path drag and drag cost, as well as using calculations of resource availability drag (RAD) and RAD cost to allocate resources optimally across the programme.

 Steve the Bajan