Monday

Tag Archives: WPM

WPM for Lean & Distributed Projects

The core concept underlaying the Critical Path Method (CPM) is there is one best way to undertake the work of the project and this can be accurately modelled in the CPM schedule. This premise does not hold for either distributed projects, or projects applying Lean Construction management. These two types of projects differ, lean is a management choice, whereas distributed projects are a physical fact:
–  Distributed projects are ones where the physical distribution of the elements to be constructed means significant amounts of the work can be done in any sequence and changing the sequence when needed is relatively easy.
–  Lean construction is a project delivery process that uses Lean methods to maximize stakeholder value and reduce waste by emphasizing collaboration between everyone involved in a project. To achieve this the work is planned and re-planned as needed by the project team focusing on optimising production.

In both cases, the flexibility in the way the detailed work is performed and the relative ease with which the sequence can be changed means CPM is ineffective as a predictor of status and completion.

Our latest article WPM for Lean & Distributed Projects looks at how Work Performance Management (WPM) can be used to assess both the current status and the projected completion for these types of project, regardless of the number of sequence changes made to the overall plan.

Download WPM for Lean & Distributed Projects from: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-Dist

See more on WPM as a valuable tool to add to you project controls system: https://mosaicprojects.com.au/PMKI-SCH-041.php#Overview

Agile’s Hidden Secret!

The two fundamental questions standard agile metrics cannot answer consistently are:

1.  How far ahead or behind schedule are we currently?

2.  When are we expected to finish?

Most of the tools and techniques used to manage Agile projects are good at defining the work (done, in-progress, or not started) and can indicate if the work is ahead or behind a nominated planned rate of production, but there is no direct calculation of the time the work is currently ahead or behind the required production rate, or what this is likely to mean for the completion of the project. A full discussion of this topic is in Calculating Completion.  However, most project sponsors and clients need to know when the project they are funding will actually finish, they have other people that need to make use of the project’s outputs to achieve their objectives. At present all Agile can offer is an educated assessment based on the project teams understanding of the work.

Work Performance Management (WPM) has been designed to solve this challenge by providing answers to these questions based on consistent, repeatable, and defensible calculations.

WPM is a simple, practical tool that uses project metrics that are already being used for other purposes within the project, to assess progress and calculate a predicted completion date by comparing the amount of work achieved at a point in time with the amount of work needed to have been achieved. Based on this data WPM calculates the project status and the expected completion date assuming the rate of progress remains constant.

Our latest article, WPM for Agile Projects identifies the cause of this information gap in Agile project management, explains the inability of current tools to accurately predict completion and demonstrates how WPM will effectively close this critical information gap.
Download WPM for Agile Projects: https://mosaicprojects.com.au/Mag_Articles/AA040_-_WPM_for_Agile_Projects.pdf

For more on the practical use of WPM, free sample files, and access to the tool see: https://mosaicprojects.com.au/PMKI-SCH-041.php  

Using WPM to augment CPM predictions

We all know (or should know) that when a project is running late, the predicted completion date calculated by the ‘critical path method’ (CPM) at an update tends to be optimistic, and this bias remains true for predictions based on simple time analysis as well as schedule calculations made using resource leveling.

There are two primary reasons for this:

  1. The assumption in CPM is that all future work will occur exactly as planned regardless of performance to date. The planned durations of future activities do not change.
  2. The burning of float has no effect of the calculated completion date until after the float is 100% consumed and the activity become critical.

For more on this issue see Why Critical Path Scheduling is Wildly Optimistic!

Having an optimistic schedule for the motivation of resources to perform in not all bad – the updated CPM schedule shows the minimum level of performance needed to stop the situation deteriorating. The problem is more senior managers also need a reliable prediction of when the project can realistically be expected to finish and CPM cannot provide this. A more realistic / pessimistic view is obtained by apply the principles of Work Performance Management (WPM) to a CPM schedule, using ‘activity days’ taken from the CPM schedule as the metric.

Our latest article, WPM Solves CPM Optimism, uses a simple CPM schedule to demonstrate the differences in the calculated project completion dates between CPM and WPM. The value of WPM is stripping away the optimism bias inherent in CPM scheduling (particularly early in the project), thereby providing management with a clear indication of where the project is likely to finish if work continues at the current levels of productivity. These predictions are not a statement of fact, change the productivity and you change the outcome! A similar approach can be used to assess projected completion dates based on a simple manual bar chart.

To download the article, and see more on augmenting CPM with WPM to enhance controls information: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-CPM

Work Performance Management (WPM)

Work Performance Management (WPM) is a new project controls tool that is being developed by Mosaic Project Services. WPM is designed to calculate the current status, and predicted completion date for any project in a consistent, repeatable, and defensible way. It is primarily intended for use in projects, applying Agile or Lean Construction management approaches, where traditional CPM scheduling cannot be used effectively, but will add value on most projects. The types of projects where WPM can provide an effective controls tool include:

  • Relatively small projects requiring a straightforward controls system
  • Large projects with a single primary deliverable that is easy to measure
  • Large projects using CPM where there is a need to overcome the CPM optimism bias[1]
  • All project applying Agile[2] and Lean Construction approaches where the project team determine the sequence of working
  • Distributed projects[3] where CPM is inappropriate, and management has chosen not to use the ES extension to EVM.

WPM is an easy to use, robust, performance measurement system. The two requirements to implement WPM are:

  • A consistent metric to measure the work planned and accomplished, and
  • A simple but robust assessment of when the work was planned to be done

Based on this data, WPM can calculate how far ahead or behind plan the work currently is, and based on this information, the likely project completion date (assuming work will continue at the current rate). Recording the status and expected completion at each update provides reliable trend information. This means there is no longer any excuse for, a project team, senior management, and/or the organization’s governing body, ‘not to know’ how the work of each project is progressing.

For a more detailed overview of WPM, see: https://mosaicprojects.com.au/PMKI-SCH-041.php#Overview

Or download Overview of WPM: https://mosaicprojects.com.au/Mag_Articles/AA037_-_Overview_of_WPM.pdf


[1]     For more on WPM and the CPM optimism bias see:
https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-CPM

[2]     For more on applying WPM to Agile and Lean projects see:
https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-Agile

[3]     For more on applying WPM to distributed projects (and a definition of distributed projects) see: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM-Dist

Project Controls Dilemma

The purpose of project controls has been defined as: Project controls are the data gathering, management and analytical processes used to predict, understand and constructively influence the time and cost outcomes of a project or program through the communication of information in formats that assist effective governance and management decision making[1].

The question posed in this short post is how can we fulfil this objective when different processes calculate completely different completion dates for the same set of project data?  The options for the calculated project delay for the simple project outlined above are:

–  CPM using progress override calculates a 3 week delay.

–  CPM using retained logic calculates a 4 week delay.

–  WPM and ES calculate a 16 week (4 month) delay.

Which option is correct or are all of the options correct and project managers are free to choose the delay they prefer to report?  Full details of the various options are included in Calculating Completion: https://mosaicprojects.com.au/PDF_Papers/P217_Calculating_Completion.pdf

My suggestion is a realistic prediction of completion needs more than a simple CPM update that assumes all future work will miraculously be completed as planned. WPM (Work Performance Management) has been developed to apply a similar approach to EVM, ES and ED, based on understanding the ratio between work performed and work planned and applying this factor to the future incomplete work to assess the likely completion date if nothing changes.

For more on WPM see: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM  


[1] See Project Controls – A Definition: https://mosaicprojects.com.au/WhitePapers/WP1093_Project_Controls.pdf

Classifying Projects


In a recent paper, Scheduling Challenges in Agile & Distributed Projects, we developed a classification framework of project characteristics to help define the potential usefulness of CPM scheduling:

1. Physically constrained – there is only one viable work sequence – The CPM paradigm is ideal for this type of project.

2. Practically constrained – management has agreed the one best work sequence. The CPM paradigm is ideal for this type of project.

3. Overarching constraints – there is a required overall sequence of working, with a degree of flexibility in the way the detailed work is performed to achieve the overall objectives. The CPM paradigm may be useful at the high level in a Class 3 project, but has significant limitations at the detail level.

4. Arbitrary constraints – there is no required sequence of working (as in Class 1 or 2), but management has decided to impose a detailed sequence of work as a matter of choice. The CPM paradigm is imposed for little or no practical benefit. Should be managed as Class 3

Building on from this starting point, in the paper we identified two general types of project in Class 3, ‘soft projects’, typically managed using Agile methods and ‘distributed projects’ where the work consisted of a set of deliverables dispersed over an area with no (or limited) real constraint on the order the work is accomplished. Both Agile and Lean offer methods for optimizing the work on Class 3 projects, but when you are applying adaptive work processes how do you assess completion and deal with claims for delay and disruption?

The answer to assessing status and predicting the current expected completion date for Class 3 projects appears to be solved by the concept of Work Performance Management (WPM) offers a simple, robust tool for assessing status and calculating the expected completion regardless of the actual sequence work is being performed.

WPM looks at the quantity of work produced, compared to the quantity planned to be produced. Provided you know what the project has to produce, and have a means of measuring the production, WPM works!  If management does not know what has to be produced and has no way of defining this, it is questionable if the endeavour is a project.

For more on WPM see: https://mosaicprojects.com.au/PMKI-SCH-041.php#WPM

The next challenge will be developing a protocol for assessing delay and disruption in Class 3 projects, more on this later.