Home / Programme Management / The Complete Guide to Life Cycles for Programmes and Benefits Management

The Complete Guide to Life Cycles for Programmes and Benefits Management

benefits-managementA key responsibility for any organisation delivering programmes and projects is to ensure not only that the work gets done, but, more importantly, that it is valuable. This is where programme management in general and benefits management in particular come in.

The Programme Manager and the Programme Management Office (PMO) needs to manage the programme and the realisation of the benefits from the very beginning to the ultimate conclusion of the programme. This work needs to be structured, tracked and managed in such a way as to ensure that it is always in control and aligned to the business expectations. This need for control entails the application of life cycle management.

PMI®’s Standard for Programme Management refers to benefits management and provides a diagram of the benefits management life cycle. However it does not provide a coherent view of how to apply benefits management in an integrated way for managing programmes. The current entry addresses this lack. It describes how the life cycles correspond to each other. All quotations are from PMI’s Standard for Programme Management – Second Edition (2008).

It should be understood that many of the ideas are to a greater or lesser extent personal “work in progress” to fulfil a need that does not appear to be dealt with in any of the current literature: they are not endorsed or supported by PMI® or ESI and are presented as a basis for discussion and debate

1. The Programme Management Phases

The following diagram is adapted from the Standard for Programme Management:

1.1 Pre-Programme Preparations

The goal of this phase is “to establish a firm foundation of support and approval for the programme”.

Programme-level deliverables:

  • High-level business case
  • High-level programme structure (checkpoints)
  • Programme initiation plan

Phase Closure Condition

  • Programme mandate
  • Approval of business case and programme approach

1.2 Programme Initiation

“To continue to develop in greater detail how the programme can be structured and managed …”.

Programme-level Deliverables

  • Programme Charter

Phase Closure Condition

  • Appointment of sponsor
  • Signed-off charter
  • Assignment of key programme resources

1.3 Programme Set-up

“To establish the required infrastructure, develop a detailed roadmap, create the required set of planning documents and integrate them into a programme management plan.”

Programme-level Deliverables

  • Programme Infrastructure
  • Programme Roadmap
  • Programme Management Plan
  • Including all subsidiary plans

Phase Closure Condition

1.4 Delivery of Programme Benefits

“To initiate the component projects of the programme and manage the development of the programme benefits …”

Programme-level Deliverables

  • Project deliverables
  • Realised benefits
  • Operational improvements

Phase Closure Condition

  • Achievement of objectives or decision to curtail investment

1.4.1   Programme Closure

“To execute a controlled closedown of the programme.”

Programme-level Deliverables

  • Effective transition
  • Programme document archive
  • Post-programme review with lessons learned
  • Release of all resources

Phase Closure Condition

  • The Second Edition does not have a phase-end checkpoint to the programme closure phase!! It should be: Approval by Programme Board.

The lack of formal confirmation of programme closure is a surprising decision by PMI. I had first written “surprising oversight” but realised that this is not the case: the first edition of the standard specified a gate at the end of the Closure phase, so the decision to omit this gate must have been a conscious one. Without a gate, there is no effective control on the quality of a phase, so the loss of this gate appears to encourage incomplete and unprofessional closure to programmes – a situation that occurs all-too-often in real life, without the need to make it still easier.

2. Alignment with the Benefits Management Life Cycle

As can be seen in the diagram above, adapted from the PMI Standard, the “benefits management life cycle” as shown only caters for the realisation of the benefits and not the long-term operational delivery. The term “benefits realisation management” would be a better description of this life cycle.

 

The PMI standard does not provide a definite indication of the relationship between the two life cycles – and the benefits management life cycle was modified between the first and second editions of the standard.

The presentation of the two life cycles together indicates the following features:

  1. Benefits Identification starts in the Pre-programme Preparations phase and carries on into Programme Initiation.
  2. Benefits Analysis and Planning starts during Programme Initiation and completes with the end of Programme Set-up.
  3. Benefits Realisation starts at the same point as Delivery of Programme Benefits, but is one step in the two-step loop with Benefits Transition.
  4. Once all of the Benefits Realisation stages have been competed, the final Benefits Transition step can either be completed to end with the end of Delivery of Programme Benefits or to overlap into Programme Closure. Note that that the first option is better, but the Standard for Programme Management seems to recommend the latter.

In conclusion, this is the relationship between the two life cycles that drive and control programme management: the programme management life cycle and the benefits management life cycle.

Now we will take a look at the benefits realisation management life cycle in greater detail. That is to say, the goal is not to define the entire life cycle of managing benefits, but only the part that the programme is concerned with – i.e. the realisation of the benefits: creation and transition into the operational environment. The longer-term delivery and exploiting of these benefits of the responsibility of the organisation and is outside the scope of a programme.

Benefits Realisation Management Life Cycle

1. Benefits Identification

The key output of this phase is a clear definition of each of the benefits required from the programme.

1.1 Define the Vision

Before defining the various benefits, an overall vision of the desired outcome of the programme needs to be defined. A vision should be documented in a way that describes what the situation will look like once all of the work has been completed successfully; it should be written in the present tense as if this end-point has been reached (e.g. “our vision is that no booked passengers ever have to be turned away from our aircraft due to our planning policies or practices”).

1.2 Describe the Benefits

The benefits description is based on an analysis of what will have changed (for the better) from the current state to the state described in the vision. These benefits should be described in purely qualitative terms: the benefits criteria should be defined along with a definition of the meaning of qualitative assessment terms (such as “high”, “medium” and “low”).

2. Benefits Analysis

2.1 Define the Mission

In order to make the vision more concrete, the vision has to be translated into a “mission”: the mission statement says what needs to be done (not how to do it) and includes the mechanisms for defining completeness. The mission statement needs to provide a high-level definition of the capabilities that need to be created (e.g. “provide effective forecasting and scenario analysis based on various demand curves”). At this point, the tactical approach needs to be defined – i.e. what approach should be taken for realising the benefits (e.g. quick wins, minimal cost exposure, high-risk first, etc.).

2.2 Define the Units

In order to allow tracking and consolidation, the qualitative analysis in the previous phase needs to be transformed into a quantitative forecast; this entails defining the units in which benefits will be measured. This is often overlooked – which can lead to later arguments about what the programme is attempting to achieve. In very complex situations, more than one set of units (“yardstick”) can be defined (e.g. market penetration as well as inventory turns). In this case, the benefits will have to be quantified in terms of each of these units and multiple tracking carried out.

2.3 Derive Benefits Metrics

For each benefit, the following must be defined:

  • Benefit capability completion criteria: i.e. how to determine if all of the capabilities required to achieve the benefit are in place
  • Benefit value (measured in the predefined units): there may need to be a value defined in each of the units if more than one yardstick was defined.

Further details of the metrics depend on the composition of the set of components.

2.4 Derive Components

Once the set of required capabilities has been defined, these have to be investigated in order to determine the set of projects (and non-project work) – i.e. components – required in order to deliver these capabilities. Prioritisation will depend on the contribution of the component to achieving the strategy. This requires the component-benefit matrix to be developed as explained below.

2.5 Map Benefits

It is unlikely that each component contributes to a single benefit, so a “component-benefit matrix” needs to be developed at the same time.

Each cell of the matrix indicates the relative contribution of a component (row) to a benefit (column); a value of zero indicates that the component does not contribute to that benefit; ideally, the values are then normalised so that each column adds to 1.

 

 

Component prioritisation is still required in order to establish the benefits realisation plan and set up the information on which to base the monitoring.

2.6 Prioritise Components

2.6.1 Value-based Priorities

The Component-Benefit map is the basis for component prioritisation: the question to be answered is: how much does each component contribute individually to the total programme benefits?” If several benefits yardsticks (see Part 2) are being applied, the component priorities may be different for each of these.

For each yardstick, you can calculate the component contribution as follows:
Value for Component i = sum over columns j of {[cell(i,j) * value of Benefit j}

Where cell(i,j) is the value in cell (i,j) of the Component-Benefit matrix.
The prioritisation can then be determined by sorting the components based on their calculated value.

2.6.2 Contribution-based Priorities

The Component-Benefit (“C-B”) matrix is required for this approach as well. However, this approach is independent of the measurement yardstick chosen. The priority depends simply on the number of benefits to which a component contributes.

This is calculated as follows:
Contribution count for Component i = number of non-zero cells in row i of the C-B matrix

The prioritisation can then be determined by sorting the components based on their calculated contribution count.

2.6.3 Additional Prioritisation Approaches

A number of other approaches can be considered, based for example on:

  • Risk level of the component
  • Estimated duration
  • Estimated cost
  • Political support
  • Etc.

2.6.4 Prioritisation Strategies

The prioritisation strategy will normally be based on a number of these techniques – e.g.

  • Create a set of ranking categories based on the contribution count
  • Within each ranking category, as necessary sort by component value

The strategy adopted for prioritisation must be documented and agreed upon within the programme core team. It can be modified during the life of the programme based on a similarly formal decision.

Once the priorities have been determined, the benefits realisation plan can be established.

2.7 Establish Benefits Realisation Plan

This planning is carried out in close collaboration with the Programme Set-up phase. The planning will subdivide the Delivery of Programme Benefits phase of the Programme Management life cycle into successive stages. Each stage corresponds to the delivery of all of the components required for a given benefit. If all of the benefits are only achievable once all of the components are complete, the Delivery of Programme Benefits phase will contain a single stage.

In addition to the component priorities, this process needs to take into account the inter-component dependencies. These dependencies can be documented in the form of a precedence table exactly as for establishing a project precedence diagram.

The planning algorithm is then simply:

A: Component sequencing

  • In priority order, list all components for which all precedence requirements are satisfied

B: Benefit milestone determination

  • For each component from step A, determine if it completes the work on a benefit
    • If so, define the corresponding “benefit realisation stage complete” milestone

A2, B2 … repeat from A until all components have been dealt with

  • The last benefit milestone corresponds to “all benefits realised”; stop.

This will provide an initial roadmap for sequencing the work. However, operational and strategic constraints then need to be factored in before a realistic realisation plan can be established. Examples of such constraints are:

  • Operational constraints
    • Resource limitations
    • Budget limitations.
  • Strategic constraints
    • Maximum number of projects of a given type at any time
    • Cumulative risk exposure.

Although the roadmap should generally not change during the realisation phase, the detailed plan needs to be reviewed and as necessary updated as the operational and strategic environments evolve.

All that remains in the Benefits Analysis and Planning phase is to establish monitoring.

This part describes a development of the project management Earned Value method to cater for programmes. This Earned Benefit method should then be used for tracking, forecasting and reporting (“Monitor Components” and “Report Benefits”) during the Benefits Realisation phase (which corresponds to the Programme Management Delivery of Programme Benefits phase).

Earned Benefit Method

The concept of “earned benefit” for a programme is a natural extension of the project management Earned Value method into programme management.

The approach is to recognise that projects aim at deliverables, whereas programmes aim at benefits. For a programme, therefore, the goal is to translate from progress on delivering the scope of the projects, into progress on achieving the benefits capabilities. This is described below and then explained by use of a worked example.

1.1 The Component-Benefit Matrix

The C-B matrix was defined above and then used to help prioritise components. In this part, it is the core of the Earned Benefit method.

1.2 Calculating Earned Benefit

Start from the Component-Benefit weighting matrix

1) Determine degree of completeness of each component

2) Apply the formula: for Earned Benefits

Planned Benefit

The planned benefit at any point in time is the earned benefit up to that point. This can be plotted against time in a Cumulative Benefit curve (Benefit values on the Y-axis, Dates on the X-axis).

1.3 Benefit at Completion

The benefit at completion value of a stage is the value of the planned benefit at the end of that stage.

1.4 Percent Complete

This is the ratio: (Planned Benefit) / (Benefit at Completion).

Example

Remember the formula for Earned Benefit:

Your programme is aiming at 3 Benefits (B1, B2 and B3). The way in which the components (C1 to C6) contribute to them is shown below in the normalised Component-Benefit table.

Earned Benefit and Percent Complete

Your current stage is the first stage and contains components 1, 2 and 5

C1 is 50% complete

C2 is 25% complete

C5 is complete

There are no other components active

The benefits B1, B2 and B3 are valued in the business plan at €100K, €200K, €300K

Using the component-benefit matrix above, calculate

1) the Earned Benefit,

2) the % Benefit realised for the stage and

3) the % Benefit realised for the programme

The worked solution is as follows

(showing the unnormalised Component-Benefit Matrix; normalisation is carried out on-the-fly in Excel)

So this is the concept of Earned Benefit in order to evaluate “percent complete” of a programme. Here we take the idea still further and extend the ideas to allow monitoring of programme costs as well.

Earned Benefit Variables

1.1 Benefits Performance Index

The Benefit Performance Index at a given “data date” is (Earned Benefit) / (Planned Benefit).

1.2 Benefits Variance

This is the difference between the Earned Benefits and the Planned Benefits (EB – PB) at a chosen data date.

1.3 Benefits Equivalent Date

This is the date at which the current Earned Benefit was planned to be achieved (see example below).

1.4 Benefits Schedule Delay

The delay is the difference between the data date and the Benefits Equivalent Date. A positive value for the delay means the programme is late (behind schedule).

1.5 Benefits Schedule Performance Index

This can be calculated by dividing {(time elapsed since programme start) – (benefits schedule delay)} by (time elapsed since programme start).

Monitoring the Budget

1.1 The Benefit-Cost Curve

In order to track performance with respect to costs, a Benefit-Cost curve has to be developed as follows:

  • Start with the Cumulative Benefit Curve (in 1.3 above)
  • Take the program Cumulative Cost curve (a deliverable of the program planning process)
  • Replace the dates on the X-axis of the Cumulative Benefit Curve by the corresponding cumulative cost at that date (the X-axis is no longer to scale but that does not matter; if required the graph can be rescaled).

1.2 The Equivalent Benefit Cost

The Equivalent Benefit Cost is the planned cost for achieving a given benefit value. It is the X-value on the Benefit-Cost curve that corresponds given Benefit (Y-value).

1.3 Earned Benefit Cost Formulae

At each progress review, calculate

Benefit Cost Variance = Equivalent Benefit Cost – Actual Cost

Benefit Cost Performance Index = Equivalent Benefit Cost / Actual Cost

Example

Remember the formula for Earned Benefit:

Your programme is aiming at 3 Benefits (B1, B2 and B3). The way in which the components (C1 to C6) contribute to them is shown below in the normalised Component-Benefit table.

Earned Benefit and Percent Complete

Your current stage is the first stage and contains components 1, 2 and 5

C1 is 50% complete

C2 is 25% complete

C5 is complete

There are no other components active

The benefits B1, B2 and B3 are valued in the business plan at €100K, €200K, €300K

In the last entry, we used the component-benefit matrix above to calculate

1) the Earned Benefit,

2) the % Benefit realised for the stage and

3) the % Benefit realised for the programme

We got the following results:

Extending the Example: Benefits Performance Index

In addition to the information above, you have the following planning information for the first part of the programme: (ignore the dates along the top and consider each subdivision [S, M, T, W, etc.] to be a month, to be more realistic).

So, the Planned Value of the programme is based on

  • C1: 50%
  • C2: 50%
  • C5: 100%

So PV is € 104,167.- for an EB (from previous exercise) of € 91,667.- so that BPI = 88% and

the Benefit Variance BV = -€ 12,500

Benefits Schedule Delay

The delay is the difference between the data date and the date at which the current Earned Benefit was planned to be achieved: in the current case, the date at which the Planned Benefit should have reached € 91,667.-. can be estimated as follows

From the worked result above, per unit planning time:

  • C1 contributes €7,500.- to the total benefit (1/10 of €75,000.-)
  • C2 contributes €12,500.- (1/4 of €50,000.-)

So the planned benefit in the time p before the data date was increasing by €20,000 per unit time.

Our Benefits Schedule Delay is therefore: -BV/€20,000- = 12,500/20,000 = .625 or just over half a time unit.

Looked at another way, in 6 time units, we have earned the benefits planned for 6-.625 = 5.375 units.

From this we can define a Benefits Schedule Performance Index (BSPI) of 5.375/6 = 90%

 

How the life cycles of programmes and of benefits management can be dovetailed together

Here we return to the concepts explored in the article in order to explain how the life cycles of programmes and of benefits management can be dovetailed together in order to provide a consistent management framework. This allows the activities and responsibilities explored during each phase, to be used as the basis for a consistent and effective methodology.

Approach

The approach taken here is the opposite to that taken in the PMI Standard: we will start with the Benefits Realisation Management life cycle: benefits should drive programmes not vice versa, since programmes are run in order to deliver benefits.

Note also, that that goal is not to define the entire life cycle of managing benefits, but only the part that the programme is concerned with – i.e. the realisation of the benefits, their creation and transition into the operational environment. The longer-term delivery and exploitation of these benefits are the responsibility of the organisation, and is outside the scope of a programme.

The result of the analysis in this document is shown in the following diagram and is then explained in detail below.

Roles

We will consider the organisation to be composed of five levels of focus:

  1. Strategic focus
  2. Business focus
  3. Benefits focus
  4. Programme focus
  5. Project focus

For the strategic focus, the Executive Manager [EM] provides the vision. With the business focus, it is the Business Manager [BM] who ensures viability. The Business Change Manager [BCM] ensures that value is achieved in the benefits focus. The Programme Manager [PgM] creates the benefits and co-ordinates and ensures governance of the phases, subphases and stages. Finally the Project Manager [PjM] is delivering capabilities.

 

Benefits Realisation Management Phases

In order to align as well as possible with the PMI Standard for Programme Management, the diagram from that document will be used as a starting position. The responsible roles are also included (in order of importance for the corresponding actions).

1.1 Benefits Identification

This phase is launched when a vision has been elaborated.

It is then up to the business change manager to help translate the vision into a set of benefits to be achieved in order to achieve the vision. There are two main steps:

1.2 Develop Mission Statement [BCM, EM]

The first step however, which is not mentioned in the PMI life cycle is to translate the vision into a more concrete description of the organisational change required in order to achieve the vision. This is the responsibility of the business change manager and will take the form of a mission statement.

1.3 Identify Benefits [BCM, BM]

The goal of this step is to determine the relevant benefits that contribute to the overall goal, as well as their interdependencies and any “dis-benefits” that could occur as side-effects. This can be developed in the form of an “outcome relationship model”

1.4 Assess Benefits Qualitatively [BCM, BM]

At this point there is not enough hard data for the viability (i.e. the business case) to be assessed. However a qualitative analysis can be carried out in order to decide whether the idea is sufficiently promising to pursue. This is the draft business case and is used as input to the Initiate Programme process. If it is decided to carry on, the qualitative analysis is accepted and the following phase launched.

2. Benefits Analysis and Planning

This would be better as two (sub)phases:
• Benefits Analysis
• Benefits Realisation Planning

These will be explained in turn.

2.1 Benefits Analysis

The goal of this phase is to develop the first part of a business model: a numerical estimate of the benefits.

This requires the following steps to be carried out:

  • Derive components [PgM, BCM] o This entails deciding on the projects and non-project work that is needed in order to achieve the organisational change described in the mission statement
    • This related to the “component analysis” tool in the Develop Programme Infrastructure process [4.3] of the PgM Standard
  • Map benefits [PgM] o Provide the interdependency diagram between components and benefits
    • Develop the component-benefit matrix
  • Define units [PgM] o Benefits can only be measured if the criteria and the corresponding metrics (i.e. the “yardsticks”) are defined
  • Derive metrics [PgM] o Define completion criteria and the value of completion with respect to the relevant units
  • Estimate component costs [PgM] o Develop order of magnitude estimates for the costs of each component
  • Quantify business case [PgM, BM] o At this point the quantified benefits can be added to the draft business case to provide a financial feasibility analysis.
    • This is the basis for approval of phase completion and the go/no go decision for the next (sub)phase [EM]

2.2 Benefits Realisation Planning

The goal of this (sub)phase is to produce the benefits realisation plan. This is built up as follows:

  • Determine component interdependencies [PgM] o Some components may need to use artefacts created by other components
  • Prioritise components [PgM, BCM] o Based on a chosen set of criteria such as time, value, etc.
  • Derive initial roadmap [PgM] o This gives the sequencing of components and the benefits milestones
  • Establish benefits realisation plan [PgM, BCM] o Link the roadmap to the component duration, cost and value estimates
    • This plan allows the cumulative benefits curve to be developed
  • Establish benefits realisation monitoring [PgM] • This defines how Earned Value, Earned Benefits and the cumulative benefits curve are applied for the specific programme
    o This document is the basis for the go/nogo decision to start to create the capabilities and realise the benefits [EM]

3. Benefits Realisation Plan Review

The PMI® does not mention any benefits-specific phase gates. Once the life cycles have been aligned, the review of the benefits realisation plan should form part of the ‘Programme Set-up Phase’. This is critical to ensure an ongoing and effective link between the management of the programme and the management of the business. That is why the key responsibility for accepting the business realisation plan is the Executive Manager.

Approved Benefits Realisation Plan

The programme has reached the point at which the benefits realisation plan has been approved by the Executive Manager, and the corresponding resources have been made available for deployment in accordance with the plan.

1. Benefits Realisation

This phase is composed of one or several, serial, overlapping stages, each of which delivers incremental benefits.

The steps in any stage are as follows, in overlapping cycles:

  • Authorise stage to open [PgM] o This is linked to the benefits roadmap
  • Develop stage component charters [PgM, BCM, PjM] o The basis of this was done in Derive Components above
  • Authorise corresponding component to start [PgM] o There is a lot of work connected with this:
    • Setting up budgets, obtaining resources, etc.
    • If there are many parallel projects, the PgM may also need to designate a “sustaining sponsor”
  • Track and consolidate component progress into benefits realisation reports [PgM, BCM, PjM] o Using the approach defined in an earlier phase
  • Report progress [BCM, PgM] o The EM is more interested in the benefits than in the process
  • Authorise end of component [PgM, PjM] o And update the various reports
  • Authorise stage closure [PgM, BCM] o This depends on administrative and business-related criteria
    • All “transitioning” component actions must be complete
  • Revalidate business case [PgM, BCM, BM, EM] o This is normally carried out at the opening and/or the closure of a stage.

2. Benefits Transition

In theory, once the final stage reaches completion, all of the integration and transitioning actions will have been carried out. However, since programmes can be large and complex, they need a specific focus on ensuring that the final result has reached a stable operating state and no longer needs support from the programme team.

The actions are:

  • Audit consolidated benefits [BCM] o If necessary, this may lead to corrective consolidation actions
  • Audit operational environment [?] o If necessary this may lead to corrective actions in the transfer of responsibility
  • Identify and document lessons learned [PgM, BCM, BM]
  • Review outcome against business case [EM, BCM, PgM, BM] o The result of this review should be authorisation to close the programme.

This phase completes with the official approval for programme closure.

  • Programme closure (the benefits management life cycle is complete)
    o All resources, etc. need to be released
    • The programme steering committee reviews all of this and provides …
    o Approval for programme closure

Reconciling the Life Cycles

1. The Two Versions of the Benefits Realisation Life Cycle

The following diagram shows the top-level differences – which appear minor at that level.

The main differences are:

  • The Benefits Identification phase has been renamed since the goal is to delver a qualitative assessment of the potential benefits
  • The Benefits and Analysis phase has been subdivided into two phases
  • Some of the content of the phases has been modified or re-offered, to provide a more logical and manageable flow of control.

2. Benefits Realisation and Programme Management Life Cycles

The proposed changes in the benefits realisation management life cycle have the effect that the phases, as well as the corresponding phase gates, can be aligned with those of the programme management life cycle. The lack of a phase-end gate at the very end of the programme management life cycle is made still more obvious by this alignment.

 

The revised Benefits Realisation life cycle puts the focus of programme management back where it belongs: into managing the realisation of the required benefits. It also helps to explain the main responsibilities of the key roles in the programme.

A complete programme management methodology can be based on this consolidated life cycles by defining in detail for each phase and stage, the:

  • Roles and responsibilities
  • Tools and techniques
  • Checklists and reviews

Although different environments will have different constraints and objectives, the framework shown above is universally applicable in its broad lines.

There is always more to learn or understand about programme and benefits management.

Here we provide a recipe for implementing the Earned Benefit approach explained previously.

Cooking steps – from a to z

1 First, definition and planning steps. You need to

a) identify the benefits; number them sequentially for identification.
b) define the measurement systems for quantifying the benefits (initially assume that all stakeholders can agree on a single way of measuring)
c) evaluate the benefits numerically: this provides the “benefits value vector” (bvv)
2 Now we know what we are working towards, so create the measurable plan:


d) decide on the programme components (sub-programmes, projects) required in order to achieve the benefits and number them sequentially for identification.
e) create a component-benefits matrix (CBM) as follows:
f) each cell contains a number indicating the contribution the component makes to the corresponding benefit (since a component can contribute to several or non of the components)
g) normalise this matrix so that each column sums to 1
h) multiplying the bvv by the CBM will give a “component benefit value” vector. This can help prioritise the implementation order of components.
i) develop the component implementation schedule.
j) for each planned review date, calculate the Planned Value of each component (normal project Earned Value method) (“component planned value vector” cpvv)
k) calculate the “planned benefits vector” for each review date as CBM times the cpvv for that date
l) at any date, the value of the Planned Benefit (PB) is the sum of the components of the “planned benefits vector”
m) plot the Planned Benefit values against time: this is the Cumulative Benefit Curve.
3 We have completed the planning; now, for tracking


n) At any point in time, take the earned value of each component to create the “earned value vector”, (evv)
o) calculate the product of CBM times the evv; this is the “earned benefit vector” (ebv)
p) the programme Earned Benefit (EB) is the sum of the values of the ebv.
4 You can now do all of the usual Earned Value calculations on Earned Benefit
q) BSPI = EB/PB
r) % complete = EB/(total planned benefit)
s) I like to calculate Benefit Schedule Variance as ([date on which we had planned to have achieved the EB] – [data date])
5 If you want to do the same with costs


t) For each review date, calculate the Programme Planned Value (PPV) as the sum of the component PVs
u) plot EB against PPV: this gives the Programme Cost-Benefit Curve
v) you have the EB from (p) above. Look up the equivalent PPV (EPPV) on the Programme Cost-Benefit Curve
w) calculate the programme actual cost as of the data date (PAC) as the sum of the component actual costs at that date
x) calculate: BCPI = EEPV/PAC
y) Benefit Cost Variance as (EPPV – PAC)
z) etc.

If you enjoyed this post, make sure you subscribe to our RSS feed!

About Kik Piney

Kik Piney

Crispin Piney, an instructor with ESI International, has developed and deployed technically advanced—and culturally complex—capabilities and services in both research and business environments for large multinational companies, advising on project management expertise enhancement throughout such organizations.
Mr. Piney is well known for his ability to link the theory of project management to practical examples taken from his work experience and from everyday life. He is a lively speaker who generates enthusiasm and interaction in his audience. He has a bachelor’s degree in mathematics from Imperial College, London, and is anAssociate of the Royal College of Science, London. He is certified as a Project Management Professional (PMP®) by the Project Management Institute (PMI®) and is a member of the PMI® France chapter. He is bilingual in English and French.

%d bloggers like this: