Common Schedule Quality Assessment Metrics
Project Schedules must be checked for common problems that may affect a deterministic plan and/or a risk analysis prior to baselining. Every work programme needs to be reviewed carefully and evaluated schedule quality including but not limited to following metrics:
Schedule constraints have a significant effect on risk analysis results. They should be used sparingly, and only when the constraint reflects reality. Constraints to be particularly aware of are:
For a schedule risk analysis to be meaningful, it is important that tasks' dates are set by logic (e.g. Finish-to-Start links) rather than constraints. This is so that the risk analysis will recognize the knock-on effect of delays. An open-ended task is one that does not have at least one predecessor and one successor – it indicates a possible lack of logic. Consider closing open-ended tasks:
Out of sequence updates ("broken logic")
The logic in a plan can be broken when tasks have started or finished before their predecessors. It is recommended that any broken logic is removed or corrected to ensure the project schedules as expected. For example, if task A has a Finish-to-Start link to task B, but B has been started (by giving it an Actual Start date), this is broken logic. It is not clear whether B's remaining work should wait for task A to finish, or start straight away. Consider fixing the broken logic by either removing the link or removing the actual dates. Also consider using the retained logic / progress override options on the Scheduling tab of the Plan | Options dialog box.
Lags longer than zero (0)
A lag is a gap in the logic between two tasks – a delay between the dates of two tasks that are linked together. Lags cannot have risk or uncertainty. In reality it is likely that the lag represents either work or a delay, whose duration is uncertain. This is particularly significant for long lags. Consider replacing the lag with a task, so that uncertainty and risks can be assessed against it. Use the Convert Lags to Tasks tool when a project contains a large number of long lags.
Negative lags ("leads")
A negative lag is an overlap in the logic between two tasks – often it is used to represent a task starting earlier, with sufficient time allow some other work to happen. Lags cannot have risk or uncertainty. In reality it is likely that the negative lag represents an necessary overlap, whose duration is uncertain. Consider replacing a negative lag with another kind of link that does not need the lag. For example:
Positive lags on Finish-to-Start links
A lag is a gap in the logic between two tasks – a delay after one task finishes before the next one starts. Lags cannot have risk or uncertainty. In reality it is likely that the lag represents either work or a delay, whose duration is uncertain. Consider replacing the lag with a task, so that uncertainty and risks can be assessed against it. Use the Convert Lags to Tasks tool when a project contains a large number of long lags.
Start-to-Finish links are used deliberately very rarely, because they have the unusual effect that the successor happens before the predecessor. Consider whether this logic might be a mistake, especially if it is between tasks that are not milestones.
Lags between tasks with different calendars
A lag is a gap in the logic between two tasks – a delay between the dates of two tasks that are linked together. When the two tasks have different calendars, it is not clear which calendar the task will use – whether it is the preceding task's or the succeeding task's calendar. Consider replacing the lag with a task, so that its calendar can be explicitly defined. Use the Convert Lags to Tasks tool when a project contains a large number of long lags
Links to / from summary tasks
Many people prefer not to put predecessors or successors against summary tasks, because other project management tools (such as Oracle Primavera P6) do not support them. Consider removing logic on a summary task, by using a milestone to represent the start or finish of all the tasks in the summary heading, and putting the link on the milestone instead of the summary task.
Critical Path Length Index (CPLI)
The Critical Path Length Index (CPLI) represents the measure of the efficiency necessary for completing a project on assigned time. CPLI evaluates the integrity of the overall network logic and measures how much realistic of completing a project successfully. It is preferable that the CPLI equals 1.00, which means that the project must be completed within the planned time. A CPLI that is below 1.00 indicates that the project is inefficient, while a CPLI that is above 1.00 shows that the there is a schedule margin which means that the project may be finished earlier than planned.
Activities with Actual Dates > Data Date
Activities actual dates should be synchronized with Data Date and must not enter unrealistic made-up actual date entries.
Baseline Execution Index (BEI)
The Baseline Execution Index (BEI) is an early warning indicator that a schedule is in trouble of not meeting the required finish date. Most scheduling software doesn’t have a BEI variable, but it is possible to compute the ratio yourself by checking "Variance Baseline Project Finish Date" column in P6. The BEI sums up how many activities are ahead or behind schedule against the baseline. BEI value equals to 1.0 means that the schedule is on the right track.
Duration uncertainty distribution shape
Tasks identified where: Maximum - Most Likely duration divided by the Most Likely - Minimum duration is greater than 2. The validation is only applied to the following distributions:
The check also tells you whether the numbers entered for Min, Most Likely and Max create a valid distribution. A task's duration can have a "skewed" three-point estimate, which means it is not symmetrical. Usually three-point estimates are skewed on the "pessimistic" side, where the maximum is further away from the most likely than the minimum. The ratio of (Maximum - Most Likely) to (Most Likely - Minimum) is used to measure this skew. When the skew is significant (for example minimum = 1, most likely = 10, maximum = 100), this may be an indication that there are low-probability events that cause this pessimism. Consider using the risk register to represent these risks events, and reduce the amount of skew on the task's uncertainty.
Who is Akim Engineering | Oracle Primavera Experts Team
KIM Engineering is a team of professionals. Every member of our team has spent many hours polishing professional skills and earning a unique experience in the ocean of Oracle Primavera, project management and planning, technical support etc. We enjoy the process of creating a project with Oracle Primavera from its start to its end - from a draft excel task list, all the way through building work breakdown structure, activities, relationships, resource and resource assignments to the approved baseline schedule, and then still on and on, providing our customers with superior support and guidance on the progress update and reporting process.