MS Project vs Oracle Primavera: Understanding the Gaps and Functionality

Craig Relyea
Understanding the limits of Microsoft Project and identifying some of its major user issues is important in defending a move to a more equipped scheduling tool, like Oracle Primavera P6. Project managers and new schedulers need to understand the differences between MS Project and Oracle P6, so the right tool is chosen for each project.

When assisting clients with scheduling efforts, we are often asked about the differences between a Microsoft Project (MSP) or Oracle’s Primavera P6 (P6) schedule. Other than cost, what are the distinctions between these two scheduling software platforms?

MSP is an adequate tool for some owners and smaller contractors and is used by various government organizations. It’s cost effective and easy to use. For large, complex projects, P6 is widely preferred due to its feature-rich capabilities. If you’re a P6 user, understanding the limits of MSP is very important for schedulers when an owner requires it for a contract. Here, I try to provide a bit of support should you need to justify moving to a more robust scheduling tool, like P6, for a more complex project requiring a high level of detail.

Limitation Number One: Lack of Rules

To appeal to a non-scheduling user base, Microsoft removed scheduling rules from MSP to enable people with minimal scheduling experience to create spreadsheet-based schedules. However, the absence of rules results in irregular schedules that do not pass integrity checks and cannot be accurately tracked and progressed.

For example, MSP allows logic ties to Summary Tasks (Level of Effort or LoE), which is not a good scheduling practice. It also does not follow the recognized CPM calculations. P6 considers every activity in the schedule when computing the critical path based on the “data date”, where MSP does not require a “data date” and instead uses the project start date. It disregards that some activities may have started or finished, and in some cases, shows the actual start or finish in the future, generating a flawed schedule.

Limitation Number Two: Inadequate Logic Ties

There is also a limitation when creating logic ties in MSP where only one relationship is allowed between any two activities. In many instances, functional project schedules require a greater level of detail and need to account for the overlap of two activities by tying together both the start and finish to correctly represent the logic of how the work will be executed. Without this functionality in MSP, an expanded and more cumbersome schedule is required.

This creates an even larger issue within the system. While MSP maintains the maximum number of activities the software can manage is up to 400,000, in practice most users find that anything more than 2,000-3,000 activities becomes unstable and the data tends to be unreliable in the stand-alone format. This is partly because all MSP work is performed within the computer’s memory, where changes are only saved when you ask an operation to be performed. By contrast, P6 is a relational database tool, which allows for a greater number of activities to be inserted without conflict—changes to activities occur each time the “enter” key is pressed.

Limitation Number Three: Lack of Security Function

Unless you are using the server-based version of the software, MSP doesn't allow multiple users to simultaneously work on a single project. Even within the server-based version, there are limitations that may result in unexpected changes to the project file when multiple users work on it at the same time.

P6, however, is a relational database tool; therefore, there are no issues with multiple users working on the same file, at the same time, in a shared environment.

P6 provides internal security functionality where specific features can be assigned to or removed from an individual user; taking it a step further, these security settings can be adapted across multiple schedules. This security is essential in a shared user environment. To overcome the security control limitations of MSP, we often find that the master schedule must be sub-divided into individual files that are managed separately.

This, of course, eliminates the advantage of having a single master schedule in the first place: the simultaneous integration of the work across the whole project. Using this approach, the relationships among the sub-schedules become tenuous and if the files are being maintained in separate locations, the complexity of managing those relationships becomes difficult.

Limitation Number Four: Capturing the Original Planned Duration

MSP has no functionality to capture the original planned project duration as the schedule is revised, other than saving the schedule as a separate file. Updating progress within the schedule as the project progresses permanently changes the value in the duration field. Performing a comparison in MSP to evaluate the difference between planned original duration and actual duration requires the use of third party software or exporting the data to Excel and creating a manual comparison tool. When updating progress in MSP the calculation function that moves uncompleted work to the right side of the data date uses constraints to do so. This automatically overwrites any existing constraints. You lose the ability to easily see what has changed.

Although a generally well-constructed schedule has minimal constraints, there are occasions when they are necessary; sometimes users need the ability to constrain both the start and finish dates for an activity. This is not possible in MSP.

An MSP baseline is a partial snapshot of the schedule and this means:

  • All baseline variance measurements are versus the early dates
  • The baseline does not store logic, float, or constraints
  • You cannot recalculate any of the stored information
  • It cannot convert back into a fully functional schedule
  • The Late Start and Late Finish dates are not stored

P6 allows storage of up to 10 baseline schedules, allowing for various types of time analysis and comparisons to the original baseline to easily show changes from the earlier reports. In addition, P6 baselines stores all logic, float and constraints, as well as the late dates. These can also be easily copied to perform a “what if” Time Impact Analysis for project changes in scope or execution.

Limitation Number Five: Not Intended for Multiple-Project Use

In P6, multiple projects can be opened simultaneously for viewing and editing. This allows for relationships to be established among activities in different projects (for example, multiple projects located on a single site for the same client) when inter-dependencies exist. This can be done in MSP as well, but since this function is not intended for multiple-project use, it doesn't allow actions such as:

  • Multiple project tracking
  • Multiple project or work breakdown structure (WBS) comparisons
  • Cost and unit calculations

In P6, the WBS is created separately from activities. Once it has been created, activities can be added within each WBS element. The separate creation of the WBS in P6 allows in-depth specification of WBS elements, with ease and as much detail as possible. Whereas in MSP, activities are indented to make them look like the WBS (summary activities). MSP has non-fixed activity IDs that change, compared to P6, which has a smart ID feature, always linked to the same activity allowing for robust comparisons.

Limitation Number Six: Useful Tools of P6  

MSP lacks the feature of tracking project issues or risks. In P6, issues and risks can be recorded at the activity, WBS or project level.

The “steps” feature in P6 allows the user to create sub-activities (Steps) of an activity, effectively creating a “to-do” list for discrete progressing. Each step has a weight that can be used to drive Physical % Complete for an activity as the Steps are marked off as completed, thereby removing the subjectivity in determining Physical % Complete. The additional P6 Step Template allows this feature to be used for common repeatable processes that appear often among projects. It is very efficient and helpful to use Steps to represent Earning Rules (Rules of Credit) for an activity for Earned Value tracking. This is very useful and another powerful feature missing in MSP.

In conclusion, one must also be aware that due to its extensive capabilities, P6 can create a “walled garden” as it is not as user friendly as MSP, making it harder for a non-scheduling professional to understand. P6 does real critical path calculations, where MSP does not, and provides for better output and analytics. However, there are times when MSP is the right tool. It’s very user-friendly, has decent graphics and works well for simpler, shorter duration, minimal risk projects with lower activity counts, and where resource tracking is not an issue. There are ways to work around the MSP functionality gaps, however, it requires more work and one must be diligent to avoid misrepresenting the projects status to the client.

Understanding the functionality differences between MSP and P6 is key to maximizing the use and development of your project schedule to guide your project to its most efficient and successful completion.