ProjectFlightDeck

Concept: Some project topologies degrade the reliability of ES metrics early in a project’s timeline. ES Longest Path (ES-LP) alleviates the difficulty.

Figure 1

Practice: Use of Earned Schedule-Longest Path (ES-LP) on real-life projects requires tool support.  Such tools must provide reports on LP metrics, in particular, ES (L), LP SPIt, and LP’s Independent Estimate at Completion (IEACt). The IEACt should include not only the nominal value but also the statistical high and low values. The Independent Estimated Completion Date (IECDt) can be included for convenience—Project Managers generally focus on completion dates, rather than the durations that entail them.

ProjectFlightDeck’s LP Analyzer is an example of an ES-LP tool. It presents LP metrics in both graphical and tabular form. In our experience, the different forms meet different needs. A recent project illustrates how the reports are used to manage the schedule. (See Figure 1.)

Graphs are especially useful for the following functions:

• Communication: Graphs are effective ways to portray the status of the project to team members and to management. The visual representation makes it quick and easy for participants to grasp how things are going on the project. In Figure 1, the dramatic improvement in performance during August is clearly visible in both the Burndown and Index charts.
• Trend Identification: Graphs are also good at making trends evident. The LP SPIt line shows a gradual drop from its August high through the intervening months.  That trend adds a cautionary note to the otherwise rosy picture painted by the steadily rising ES(L). In short, performance
  efficiency is slowly declining even though schedule is continuously being earned.
• Cross Project Comparison: Where multiple projects are in play simultaneously, graphs make it easy to compare progress across projects. We have found this especially useful on large programs with inter-dependent projects. Exceptions to general performance are easy to detect by scanning graphs for constituent projects.

Tables are especially useful for the following functions:

Figure 2  

• Threshold Tracking: We often leverage tabular values by comparing them to thresholds. In Figure 2, we added a formula to check the LP SPIt value and the IEACt values against thresholds.* The resulting colour-coded “chicklet diagram” makes threshold breaches obvious.  Note that the IEACt Low values are consistently red-flagged.
• Metric Comparison: As also illustrated by Figure 2, the matrix of LP metrics makes it easy to compare measurements: over time for the same metric and across metrics for the same time period.  For example, August is the start of a trend. For about 6 months, all but one indicator is within project thresholds. The IEACt low, however, breaches its threshold. That may well indicate that the plan over-estimated the time required. In other words, the other metrics look good because the baseline was overly generous.
• Detailed Analysis: For day-to-day schedule management, we go directly to the tables. Graphs are great at creating an impression, but the detailed values are better at telling the story behind the picture. The details enable us to observe not only variation but the quantified amount of variation.  Thus, we know not only that schedule efficiency declined after August, but also that it declined at a rate of about 10% each month.  We could then assess whether the drop would be sufficient to threaten the estimated completion date. (It was not.)

Taken together, graphs and tables make it easy for us to interpret LP reports and thereby evaluate schedule performance.

Notes: 
 *ProjectFlightDeck’s LP Analyzer places its reports into MS Excel spreadsheets. Users can tailor the reports by incorporating thresholds unique to each project.

Concept: Some project topologies degrade the reliability of ES metrics early in a project�s timeline. ES Longest Path (ES-LP) alleviates the difficulty.

�
Figure 1

ES-LP is sensitive to Down Time (interruption of Planned Value) and Stop Work (interruption of Earned Value). Before explaining how to address work interruption, the terms need to be clarified.

Down Time is the period(s) for which no work is planned. No Planned work implies no Planned Value. For work (and hence Planned Value) to be interrupted, it must have begun. Consequently, lead time prior to the Baselined Planned Start of a task is not considered Down Time. Periods after the Baselined Planned Finish of a task are also excluded as Down Time. Thus, Down Time is book-ended by the Baselined Planned Start and Baselined Planned Finish of a task.

Stop Work is the period(s) for which execution is suspended. No execution implies no Earned Value. For actual work (and hence Earned Value) to be interrupted, it must have begun. Consequently, lead time prior to the Actual Start of a task is not considered Stop Work. Periods after the Actual Finish of a task are also excluded as Stop Work. Thus, Stop Work is booked-ended by the Actual Start and Actual Finish of a task. It is important to note one further exception: there can be periods in which no value is earned, but execution is still underway. Such periods are not considered to be Stop Work.

There are two ways to schedule Down Time (DT) and Stop Work (SW): semantically and syntactically.

DT/SW Semantics

Many scheduling tools have no way to express work interruption using built-in attributes or features. In short, there is no synatx for DT or SW. The only way to express work interruption is by setting up a task that is named or flagged in a unique way. It is only by understanding the meaning of the name or the flag, i.e., the semantics, that the task is known to express work interruption. Semantics are notoriously difficult to capture algorithmically.

DT/SW Syntax

By contrast, some scheduling tools have syntactical expressions for work interruption. Syntactical representations are more amenable to automation, as they use built-in features that are shared across instances of the scheduling tool. MS Project, for instance, offers Split Tasks. In the words of MS Project documentation, "If you need to interrupt work on a task, you can split the task so that part of it starts later in the schedule."*

When DT or SW is embedded in a task, a standard Split Task can be used. (See Figure 1.) The MS Project version of the LP Analyzer automatically detects the work interruption and factors it into the calculations.

Sometimes, work interruption needs to be expressed independently of specific tasks--for instance, if work interruption occurs between the end of one task and the start of the next. (See Figure 2.) In such cases, DT and SW must be implemented in specified ways to ensure that DT and SW are correctly factored into LP calculations.

Figure 2

The Split Task period must be identified in such a way that MS Project recognizes the split, preserves the split, and does not automatically adjust the desired start date, finish date, and duration. To achieve this there are two approaches, each with constraints.

1) PV and EV equal zero:

If PV and EV equal zero throughout the DT and SW period, use these steps:

1. Create Down Time task (Auto Scheduled).
   
2. Assign resource(s) associated with the Down Time.
   
3. Set Start Date to start of DT Set Duration to 2d.
   
4. Split the task so that part 1 is the DT start and part 2 is DT finish.
   
5. Baseline the task.
   
6. Constraint: Both PV and EV must remain 0 throughout the DT/SW period.

2) PV or EV not equal to zero:

It is possible for EV to accumulate during a DT period. It is also possible to have SW during a period in which PV is accumulating. For such a fine level of control, the procedure is more complex.

Note that PV (aka, BCWS) and EV (aka, BCWP) cannot be directly updated in MS Project (except via program code which is not recommended). Thus, the Work and Actual Work fields must be used to manipulate PV and EV. Here are the recommended steps to implement DT and SW when values are present in the DT or SW period:

1. Create DT/SW task (Manually Scheduled).**

2. Assign resource(s) associated with the DT/SW.

3. Set Start Date to start of DT/SW.

4. Set Duration to 2d.

5. Split the task so that part 1 is at the DT/SW start date and part 2 is at the DT/SW finish date.

6. Enter values into the first day of part 1 and the final day of part 2. This sets the boundaries of the split. Admissible values for PV and EV are specified below.

7. Input PV values next. Admissible values follow..

i. As a default, set the Work value to .01 on the first day of part 1 and the last day of part 2
ii. If PV values need to be reflected in the split period, enter the amount of Work required to produce the desired PV into the period in which it is planned the PV values override the default values if they are present.
iii. Constraint: You must ensure that at least one day between DT start and DT finish has 0 Work, otherwise you will collapse the split into a single, continuous task.

8. Baseline the task.

9. Once the task is baselined, input EV values (if desired). Admissible values follow (note that default values are not required for EV).

i.  If EV values are required, enter sufficient amounts of Actual Work to generate the required EV.
ii. Enter Actual Work into each period in which value was earned.
iii.Constraint: You must ensure that at least one day between DT start and DT finish has 0 Actual Work, otherwise the split will automatically collapse into a single, continuous task that will not be visible to the LP algorithm .

10. After updating values, ensure that the period still reflects the desired DT/SW period

Although complicated, the approach outlined ensures the accuracy of the LP calculations.

Notes

Concept: Some project topologies degrade the reliability of ES metrics early in a project’s timeline. ES Longest Path (ES-LP) alleviates the difficulty.

Practice: Without automation, ES-LP cannot be practically applied to managing project schedules.  The reason for this is the complexity of the LP calculations. Consider the steps required to produce LP metrics:

• Exhaustively identify all serial paths.
• For each series, identify and remove void periods.
• For each series, calculate the ES and SPIt.
• For each series, calculate the LP duration forecast.
• For each series, factor into the forecast void periods.
• For each period, select the longest forecast from among all of the paths.
• Identify anomalies and replace them with non-anomalous forecasts.

In real schedules, the complexity in any one of these step makes manual calculation for the project infeasible.

At this point, there is only one commercially available tool that performs ES-LP calculations: ProjectFlightDeck’s LP Analyzer.* The following posts use the LP Analyzer as the example of how to use an LP tool to manage schedules.

Project managers (PMs) need the ability to tailor LP analysis to specific projects.  Parameter settings in the user interface give PMs this control. (See Figure 1.) Typical parameters and common settings follow.

• Time Increment: The parameter sets the length of the time period used in calculations and reports. For many projects, weekly reporting gives a “fine grained” reading on schedule performance. Such a reading supports quick problem identification and correction. Large, long-term projects often use monthly time increments, as the reporting cycle is generally longer.
• As-Of Date: The parameter identifies how many periods are reported. Although calculations are performed on the whole project span, reporting is limited by the As-Of Date. This keeps the focus on current metrics. The PM’s preferred format for dates is displayed to ease data entry.
• Confidence Level: For statistical analysis, two of the most commonly used confidence levels are 90% and 95%. We have found the 90% level most useful on our projects, but there are situations in which the tighter interval is appropriate.
• Performance Path Analysis: Ordinarily, the results of intermediate calculations are invisible. There are circumstances, however, when they need to be exposed. For instance, a particular dependency series might need to be investigated. Or, a researcher might need to verify that the LP ES and IEACt calculations are being performed correctly. To accommodate such needs, the PM can turn on dependency-path reporting. Path reports can extend  the run time, especially for large projects. So, they need to be used advisedly.

The next two parameters are specific to MS Project.

• Earned Value Source: The parameter addresses a peculiarity in the way MS Project (MSP) calculates the Budgeted Cost for Work Performed (BCWP). By default, MSP distributes earned value evenly over the days allocated for the task, up to the current date.** Sometimes, PMs prefer to have the BCWP accrue to the time period in which it is actually earned.*** When PMs need to track BCWP in this way, they enter Actual Work in the period when it is performed, and the LP Analyzer calculates the BCWP by period.
• Split Tasks: LP analysis is sensitive to void periods. One type of void period is work interruption, commonly termed Down Time (interruption of BCWS) or Stop Work (interruption BCWP). Down Time and Stop Work can be represented by Split Tasks in MS Project. Depending on how much control PMs need, the Split Task set up can get complicated (see the next post). To ensure that Split Tasks are factored into the LP analysis correctly, PMs indicate that they have used them to represent work interruptions.

Notes