We are delighted to announce that our senior consultant Alex Lyaschenko, will be a speaker at the Construction CPM Conference 2023, Orlando FL:
Construction CPM Conference
Where Professional Planner Schedulers Gather
to Discuss and Improve Critical Path Method Analysis Knowledge
One of the important questions, when a schedule quality analysis is performed, is: “Is the schedule review up-to-date?”. There are a few metrics that could help find the answer to this question and identify activities with potentially invalid dates. Some of them could be performed based on the current schedule and others require a comparison to the previous schedule snapshot. Identified issues may indicate that project has gaps in a schedule maintenance process that must be addressed.
The status of each activity is defined by Project status date (data date), Start & Finish dates and ‘% Complete’. There is a correlation between these data points.
Incomplete activities in the past.
All activities with start and/or finish dates in the past have to be actualised (100% complete) or rescheduled.
Started or Completed activities in the future.
All activities with actual dates in the future have to be unactualised (0% if not Started and <100% if In-Progress) or actualised dates updated to the past.
Activates with a start date in the past and finish in the future but with 0% or 100% of progress.
In-progress activities have to have the start date in the past, the finish in the future, and ‘% Complete’ between 0% and 100%. All In-progress activities with 100% or 0% of Completion have to be reviewed. Dates or ‘% Complete’ need to be updated.
When a milestone indicates completion of the event, the milestone has only to be marked as “Completed” when all predecessor activities are completed and, on the opposite, if all predecessors are completed, the milestone has to have a “100% Complete” status.
Actualised milestones with open predecessors.
Completed milestones with the “Not Completed” predecessor(s).
The status of the milestone and the status of predecessor activities have to be reviewed and updated.
This issue may indicate that the milestone has a strict dependency that must be removed.
Not Completed milestones with complete predecessors.
Not Completed milestones with ALL Completed predecessors.
This issue indicates that the schedule may have missing activities or dependencies.
Status, Start and Finish dates of already Completed activities should not change from version to version.
Unactualised activities
Activities that previously were reported as “Completed” but the status has changed to “In-progress” or “Not Started”.
Justification for each activity previously reported as completed, but not completed now must be provided.
Historical start and dates changed
Activities that previously were reported as “Completed” with changed Start and/or Finish dates.
Justification for each activity with changed actual start and/or finish dates must be provided.
The last two metrics are particularly important when a quality analysis of a contractor schedule is performed. Constant issues are a good indication that the contractor needs to mature their schedule maintenance process.
Also, projects with such issues may have a “double counting” issue when the same activity (or deliverable) is counted as being completed a number of times.
GAO Schedule Assessment Guide, Planning & Scheduling Excellence Guide (DCMA-14) and NASA Schedule Management Handbook have metrics to identify invalid dates but they include only metrics to identify invalid activities in the past and the future, the first two checks in this post.
There is a philosophical question what to do when a schedule status update is not received?
Should a project team assume that all activities in past have not been started (or completed) and automatically push the activities to the earliest possible date: Project Status Update (known as Data Date) or they should assume that some of them may have started (or Completed) and not be updated dates until the clarification is received?
Probably developers of scheduling tools have different views on what is the correct answer to this question.
Primavera and Spider Project have the “Data Date” feature to automatically push activities with dates in the past to the Data date. Microsoft Project doesn’t have a such feature. In my observation, projects managed in Microsoft Project more often have “Incomplete activities in the past” issues and projects that are managed in Primavera more often have “Historical start and dates changed” issues.
PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma
Would the project dates calculated based on the critical path method be the same regardless of the applied scheduling tool? Not always!!!
Some time ago one large Telco company in Australia decided to replace their existing PPM system with ‘CA Clarity’. Clarity already was implemented in the organisation but used only as a corporate timesheeting system. The previous custom-made PPM system allowed to import Microsoft Project schedules and automatically retrieve dates for project status reports.
Clarity has integration with Microsoft Project, so the tool looked like a good alternative to the old PPM system. The portfolio initiated a project, which was a big disaster. The project manager made a dangerous assumption: “As both tools are based on the Critical Path Method, the schedules calculated in these tools are going to have the same dates”.
This was not the case. Imported and recalculated schedules had different delivery dates!!! The reality was even worse: the schedule imported back to Microsoft Project had different dates compared to the original schedule developed in Microsoft Project, even if the schedule was recalculated in Microsoft Project again!
In theory, the Critical Path Method is a well-defined method and a schedule calculated in any scheduling tool that supports this method should be the same.
In practice, projects consist of components: activities, calendars, constraints, dependencies, lags, resources, etc.
Scheduling tools have different features to manage and integrate project components. The way these features are implemented impacts the Critical Path Calculation.
When a schedule is imported between the tools some information could be completely lost as the new tool doesn’t have data fields to store this information.
In the described example, at that time (not sure if it is still the case) Clarity supported only resource calendars, not activity calendars. So, during the import, the information in activity calendars was lost and when the schedule was imported back to Microsoft Project, the project dates were different. Later, when I supported one of the Australian banks to intergrade Microsoft Project and Clarity, I found other differences between systems that impact schedule calculation.
Primavera, Microsoft Project, Spider Project and other project management tools support the critical path method they have unique features. The way these features are implemented may impact the Critical Path calculation!
Some examples of such features:
Principles of the Critical Path Method could be explained based on a small simple schedule and calculation of such schedule in any scheduling tool should give the same result.
Real-life projects are much more complex. They have different calendars, hard and soft constraints, lags and leads, other than ‘Finish to Start type’ types of dependencies, etc. Implementation of these features impacts the way the critical path is calculated.
Some scheduling tools have methodological issues. Project’s real-life scenarios could not be properly simulated due to technical constraints. It is important to learn these constraints, find work-arounds or maybe replace the tool.
PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma
