
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:
- Primavera supports more than one dependency between the activities, and Microsoft Project doesn’t;
- ‘Deadline’ in Microsoft Project impact Total Float calculation, Primavera doesn’t store ‘Deadline’ dates;
- Primavera and Microsoft Project have different types of activity constraints;
- Microsoft Project supports ‘% duration lags’, and Primavera doesn’t;
- Spider Project takes into the calculation activity AND resource calendars, Primavera activity OR resource calendars;
- Spider Project supports ‘Volume’ and ‘Duration’ types of activity, Primavera and Microsoft Project support only ‘Duration’ type;
- Microsoft Project allows to link activities and summary tasks (WBS), Primavera only creat links between activities;
- Primavera and Microsoft Project support Levell of Effort / Hammack activities, but this feature is implemented in a totally different way;
- Primavera support the ‘WBS Summary’ type of activity, and Microsoft Project doesn’t;
- Spider Project supports ‘Conditional’ scheduling, Primavera and Microsoft Project don’t.
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.
Alex Lyaschenko
PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma
