Managing and Optimizing the Values and Schedules of Projects and Programmes

Introduction

As I was writing this article, I thought of sending it to Harvard Business Review. But even if HBR stooped to publish a mere project management article (and about a lowly topic like the crucial importance of scheduling and critical path analysis!), it would likely take many months before it saw the light of day.

So I will publish it, like so many previously, on LinkedIn where:

• It will instantly be available for reading;

• Many of the brightest minds in project scheduling will see it;

• They will be the kind of minds that will understand it with minimal explanation; and

• They will provide valuable feedback/criticism/enhancements, easily appended in the discussion thread.

 All that said, I believe this may be the most significant article I’ve ever posted on LinkedIn, at least about scheduling.

This article will explore:

-Why the distinction between what I will call a project and a programme is so important.

-Why the way in which projects within a programme interact to generate, enable or multiply value is crucial to optimizing a programme’s value.

-Why the programme-level value breakdown structure (PgVBS) is such a crucial tool for scheduling and optimizing a programme.

-Why three new programme-related metrics, downstream delay (DSD), downstream delay cost (DSDC), and total cost impact (TCI) are as essential to a programme as drag, drag cost and true cost of work (TCW) are to a project.

The Crucial Difference Between Projects and Program(me)s!

In this article I will walk, step by step, through two sets of fairly simple network diagrams, one for a project and one for a programme. The programme network is similar to the project network except that (a) all monetary values are multiplied by 10 and (b) whereas projects typically generate almost all of their value only when or after they finish, programmes often generate value periodically with the completion of their component projects.

Indeed, whether we call them projects and programmes or petals and petunias (“A rose by any other name…”), the way that value is generated IS A CRUCIAL DIFFERENCE BETWEEN THESE TWO TYPES OF WORK EFFORT, one that needs to be recognized and managed in different ways, whatever names we care to use! (Maybe languages other than English don’t have this particular problem?)

The fact that the term megaproject is used for large infrastructure efforts, when every one of them is really a megaprogramme, reflects the failure to understand the distinction. As this article will show, a programme can only be properly planned, scheduled and managed based on how the various value packages produced by the projects (and sometimes by related non-project work) will create that value.

It has been the decades-long failure of project management to appreciate that (a) all projects are investments and (b) that it is crucial to quantify the value of a project’s scope and use it to plan, optimize and manage the most important aspect of all investments: ROI! This is why PMI’s shift under Pierre Le Manh to focus on delivery value is so exciting, and likely to lead to major improvements in project management in the near future.

Managing and Optimizing Scope and Time Value on a PROJECT!

Figure 1 shows a flow chart of the activities planned for a project. We have assigned a budget of $200K to the project, estimated the duration of each activity, and assigned budgets to each activity.

Note that if we said the value we expected from this project’s scope is $150K, you’d assume we are crazy. THAT is because you understand that all projects are investments, and that no one would knowingly do work that would lose them $50K! If we are doing this project, it’s expected value needs to be MORE than its budget of $200K!

But remember: in Ben Franklin’s words, “Time is money!” Our schedule can add to or subtract from both the cost of the project and the value it creates.

Figure 2 shows the initial output of our business analysis and the value breakdown structure (VBS) that we developed. We estimate that, at completion, our project will have a value of $500K IF we complete it in 60 days.

Additionally, the VBS (omitted for brevity’s sake) showed that, of the nine activities, seven are optional and just two (B and C) are mandatory. This is an unusual distribution of mandatory vs. optional distribution for a project: in my experience 70%-80% mandatory activities is more common. (On programmes, by contrast, there is usually a much lower percentage of work that is mandatory. Selecting the best projects for a programme is much more discretionary, and often a knotty but VERY important problem for stakeholders to resolve, through a programme-level VBS [PgVBS].)

Mandatory activities consist of work that MUST be performed, perhaps due to governmental requirements or because the project would have no value without them (i.e., EACH of the left and right wings of an airplane). As a result, B and C have a value equal to that of the entire project ($500K) if the project is completed on Day 60.

Notice that, unlike cost, value is NOT additive across all the activities of a project. The fact that both the left and right wings of an airplane have value equal to that of the whole aircraft does NOT double the plane’s value!

In Figure 3 we have estimated the value that each of the seven optional activities is expected to add if the project is completed in 60 days. It’s usually better to estimate an activity’s value-added as a percentage of the expected value of the entire project. But I’m using simple monetary units because I want to keep this simple!

In Figure 4 we have completed our critical path schedule. Let me emphasize that, were this a real project, we’d absolutely have to plug in activity-based resource assignments, conduct resource leveling and, usually, adjust our schedule to address any resource bottlenecks. But I’m assuming there are no such bottlenecks because I want to keep this simple!

You will notice that the project is scheduled to be completed in the intended 60 days, and the critical path is Activities A -> F -> I, which have critical path drags of 10D, 15D and 5D respectively. Note that neither of the two mandatory activities B and C are on the critical path. That is a bit unusual, but by no means unheard of. I’m doing it this way because I want to keep—well, you know!

Also notice that in Figure 4, we have specified how acceleration or delay could change the project’s expected value: I% greater or less value, or $5K, for each day earlier or later. We will use this information to compute the drag cost and true cost of work (TCW) for each critical path activity in the project.

In Figure 5, we have computed the drag cost of each critical path activity based on a reduction of project value of $5K for every day of project duration. The drag costs are:

Activity A = 10D * $5K = $50K

Activity F = 15D * $5K = $75K

Activity I = 5D * $5K = $25K

These numbers give us the information to justify additional resources to reduce time and increase value. For example, if we can add $20K of resources to Activity A and thereby reduce its duration by 7D, its duration would become 8D, its drag would become 3D, its drag cost would become $15K, the project duration would become 53D, and the project’s expected value would increase by $35K for an additional cost of just $20K. Seems worth it!

In Figure 6, we arrive at a cost accounting concept of which the vast majority of finance departments are unaware. But it’s not their fault, since neither critical path drag nor drag cost have been standard project management metrics.

From the point of view of a finance department, the cost of performing an activity is the cost for its resources. And indeed, that is the case if the activity is not on the critical path. But if the activity is on the critical path, the true cost of the work (TCW) is the sum of its resource costs plus its drag cost. Thus the TCWs of the three critical path activities with the current plan are:

Activity A = $20K + $50K = $70K

Activity F = $20K + $75K = $95K

Activity I = $10K + $25K = $35K

Notice that the TCW of optional Activity F is just $5K less than the value it is expected to add. We surely would not want to include an activity that costs more than the value it adds! Activity F has a net value-added (NVA) of just $5K and, if something changes (such as F’s duration increasing by a mere 2D), F’s drag cost could rise to generate a negative NVA! This is a risk that must be monitored—yet the project team and finance department are often oblivious to its existence, due in large part to the lack of these metrics in popular project management software packages.

Managing and Optimizing Scope and Time Value on a PROGRAMME!

As I wrote at the beginning of this article, the way in which projects (or petals!) within a programme (or petunia) interact to generate, enable or multiply value is crucial to optimizing a programme’s value.

Those managing and scheduling the programme must understand the three possible types of projects in a programme:

1. Value generators [VG] which create value at or after completion;

2. Value enablers [VE] which at completion enable other work to generate value; and

3. Value multipliers [VM] which increase the value that other work generates.

To plan and schedule the programme efficiently requires knowing:

• Which type of project each is;

• Precisely how and when each will contribute its value;

• How much value each is expected to contribute; and

• How that much value will change if the project’s schedule is accelerated or delayed.

 To demonstrate the significant difference between managing value creation in a stand-alone project and managing it in a programme, I will use a programme schedule that is very similar to the project schedule we have just explored. But yes, I will also keep it as simple as possible.

• All projects will be value generators [VG] that produce their value immediately at the end of each project, periodically increasing the programme’s value. Therefore each project will have its own critical path to each value packet, and therefore its own drag and drag cost, instead of the value all coming at the end (as it almost always does with a project). The value packets in our programme example will accrue as each project ends, in a way that does not occur as each activity in a typical project ends.

• Instead of the programme’s total value increasing or decreasing based on the total programme duration, the value of each project will increase or decrease if it finishes earlier or later. We are stipulating:

1. If a project’s value-added is LESS THAN $499K, accelerating or delaying its completion will increase or decrease its value by $10K per week.

2. If a project’s value-added is GREATER THAN $499K, accelerating or delaying its completion will increase or decrease its value by $20K per week.

In the programme example, the durations have been changed from days to weeks, and the budgets and value-addeds have each been increased by a factor of 10. But the dependencies between the projects are the same as in the example of a single project, and once again only B and C are mandatory while all other work is optional.

As we see in Figure 7, the critical path to the programme’s completion is still A -> F -> I, and the drag of each of these is still 10, 15 and 5 (though for the programme these are now being shown in weeks rather than days).

However, now each project has a kind of drag based on how it is delaying completion of the value packets of their downstream descendant projects! And with that drag comes drag cost based on the value of those descendants! The “drag cost” for each project can be greatly multiplied if it has multiple value packets as descendants!

To distinguish the delaying factors of these projects within a programme from the drag of an activity within a project, I will call this type of drag Downstream Delay [DSD] and the resultant reduction in programme value due to a project’s delay Downstream Delay Cost [DSDC.]

In Figure 8, we show why the effects of downstream delay can have so much impact and how to quantify it:

The diagram in Figure 8 shows that Project A would have drag of 10 weeks in terms of the critical path to the milestone representing the programme’s completion. But, being a programme, value is intended to be delivered at various points along the way, here coinciding with the completion each activity. As a result, A is not only delaying the end of the project by 10 weeks, but also the value packages associated with the two other projects on the programme’s critical path, each by 10 weeks.

If A’s duration were reduced to zero:

• F could start right after B finishes and finish on Day 30, generating an additional $200K.

• Then I and H could both start on Day 31. I would then finish on Day 50 and H on Day 45, allowing them to generate an additional $200K each, or $400K in total.

• With only A as a predecessor, E could start Day 1 and finish 15 days earlier. With a value-added under $499K, that would be worth $10K * 15 weeks = $150K.

• Additionally, A itself has a duration of 15 weeks. The duration of A is therefore delaying its value package delivery by $20K * 15 weeks = $300K.

• Therefore the Downstream Delay Cost (DDI) is $200K + $200K + $200K + $150K + $300K = $1,050K.

 This means that EACH of the first 10 weeks by which Project A might be shortened offers an increase in the programme’s value of $90K. Eliminating any of the other 5 weeks of Project A’s duration would offer and additional $30 per week, as removing them would only impact the value packages at the end of Projects A and E.

That is a LOT of value being lost due to A’s duration. A critical path schedule that computes drag within A, and within each project can justify spending veritable pennies on resources to HUGELY increase the value of the downstream work in the programme!

The message? Drag cost within a project in a programme may greatly underestimate the cost of its duration unless  it takes into account the delaying impacts on the other projects in the programme!

Our final point is explored in Figure 9. It is intended to answer the question: “Is it only activities that are on the longest path of the programme that have a Downstream Delay Cost (DSDC)?”

Let’s look at Project D, which is not on the programme’s critical path and has 15 weeks of float. However, D’s 15 weeks of duration is delaying Project G’s completion by 5 weeks. G could start on Week 11 and deliver its value at the end of Week 20 if D were not a predecessor. The 5 weeks of delay (due to D being 5 weeks longer than G’s other predecessor C) is reducing G’s value by $20K per week for a total delay cost of $100K.

Additionally, D’s duration of 15 weeks means that its value delivery can’t be occur until the end of Week 15, meaning a value reduction of $100K per week for each of its 15 weeks, or $150K in total.

Every week that D could be compressed, up to 15W, will increase the value of D by $10K, AND the first 5 weeks of D’s compression will ALSO increase the value of G by $20K per week. This means that the first 5 weeks of D’s compression are EACH worth $30K, while compressing any of the ADDITIONAL 10 weeks of D’s duration would each be worth $10K more. D’s downstream delay cost = 5D $30K + 10D $10K = $250K.

D has a budget of $200K, so its total cost impact (TCI) = $200K + $250K = $450K. Since its value-added is only $250K, D is costing us $200K more to perform than the value it’s adding! We must change the way we do Project D (such as by compressing its critical path!) or jettison it! (Remember, we stipulated that ALL the value of each project will be created as soon as it is finished. If that is NOT the case, and D is enabling or adding value to the other projects in the programme, then that is CRUCIAL to know and the additional value-added must be taken into account!)

Summary

There is a great deal of confusion between what, exactly, is a project and what is a programme. The meaning of words can vary. But these are two different collections of work that generate value. There should be consistent and distinct terms for them, as the difference in the ways an investment generates value is of primary importance. Differences in value generation must be managed differently:

• One form, usually called a project in English, creates a product, service or result that has or creates value after its work is completed.

• The other, sometimes called a programme in English or a program in American, consists of more than one project (and sometimes non-project work). It generates value due to the interactions of all the work within it. Thus a programme will generate value not just when it’s work is finished, but at several intervals as its projects are completed.

As the focus on value delivery (per PMI’s new direction) will increasingly show, planning and managing programme scope and schedule is much more complex than for a project. But both should be driven by the intent to create maximum return on the investment. That requires information about what, how, how much and when the value of each project in a programme will be generated, enabled or multiplied.

The information about what, how and how much should be assembled in the form of a programme-level value breakdown structure (PgVBS). This should focus on the different components of the programme’s scope, and provide the basis for the scheduling that will optimize the when of value creation through the schedules of the component project interactions.

The new schedule- and value-based metrics such as drag cost, resource availability drag cost, true cost of work and net value-added still measure important aspects of programme work, but they become much more complex due to the interactions of the component projects, usually creating multiple delaying factors and critical paths to various types and amounts of value delivery.

The three new programme-related metrics that are developed in this article, downstream delay (DSD), downstream delay cost (DSDC), and total cost impact (TCI), are as essential to a programme as drag, drag cost and true cost of work (TCW) are to a project. They show the impact of scheduling decisions on the programme’s ROI and allow schedulers to make decisions that will maximize the return on the investment.

 ***

In addition to the general PM community, this article should provide food for thought for those who develop project management software. Please provide feedback on these ideas, including both criticism and  how they might be expanded even further. 

And if you feel like calculating the DSD, DSDC and TCI for some of the other projects in Figure 7, feel free. I’ll try to respond to your “answers”. 

Steve the Bajan