Scheduling Tools Comparison Analysis. Data Identifiers.
This post is a part of series of posts that explains the unique features and constraints of the most popular scheduling tools: Primavera, MS Project / Project Online, Spider Project and Project For The Web.
While each of the scheduling tools provides a lot of features to manage project delivery, it is hard to imagine a tool that covers all needs for any project, program or portfolio. The ability to integrate a scheduling data with other systems, in my opinion, is a critical function that supports (or limits) the maturity of project delivery.
This post provides a detailed review of data identifiers. Data identifiers are critical for user experience (UX) and also used for data integration within a tool or to external systems.
Systems for integration
Scheduling tools are often required to integrate with other non-scheduling tools. The most popular non-scheduling tools that utilise scheduling data are:
Excel
It is hard to find a project manager or a scheduler who never copies scheduling data to Excel for analysis or reporting.
PPM tools
Scheduling data is a critical part of any PPM (Project Portfolio Management) system. Each scheduling tool included in this review is already a part of its own PPM system and also has the capability to be integrated with some other external PPM solutions.
Primavera has integration with Unifier, Oracle PPM solutions. Project Online is a base for any PPM solution developed on the SharePoint platform. Spider Project is powerful project portfolio management optimisation software. Project For The Web is a scheduling component of the new Power Platform. would have built-in integration with any PPM system build based on this platform.
However, it could be a requirement to integrate scheduling data with an external PPM system. For example, some programs and portfolios include technology and infrastructure projects and may have more them one scheduling system rolled out.
Reporting tools
Tableau, Power BI and some other reporting systems are extremely popular now. These tools consume scheduling data for reporting and analysis to support project and portfolio decisions. These tools are not only able to represent data in a better way but also combine scheduling snapshots for deeper analysis and governance control.
Financial systems
Some organisations need direct integration between scheduling and financial systems.
Integration types
There are three methods for data integration:
• Screen manual copy-past;
• Export via different formats (xls, csv, xml, etc);
• Direct access to data tables also known as “backend access”.
Data identifiers
Project and schedule progress is a fundamental aspect of monitoring project performance over a specified reporting period. Progress is measured by completing a schedule comparison over two points in time. The schedule, as a system, needs to identify the same data points (projects, milestones, activities, etc) and compare data attributes (dates, status, etc) from two comparison points or snapshots.
It is not reliable to use names (eg project name, activity name, resource name, etc.) as they are likely to change during the life of a project, so all tools have coding systems that are used as an “identifier” for data integration and comparison purposes. There are three types of data identifiers that users should be aware of:
1. Codes
A Coding system gives a user the opportunity to manually set up and manage scheduling data. Data codes are unique and editable.
2. System identifier
System identifiers are automatically created and are unique but not always accessible to users. While the main function of system identifiers is to ensure data integrity, it is often useful to get access to these identifiers as they could be used for data governance control.
Example:
A user by mistake swaps two activity codes. A slippage from the previous month would not be calculated correctly as incorrect data points used for the calculation, and it is hard to notice. If activities haven’t been recreated it is possible to generate an exception report based on a system identifier (if available) that shows such a problem.
3. Screen identifiers
Screen identifiers simplify the user experience by showing activity orders on a screen. While it is convenient to use the ID within a system it is not reliable to use it outside of the system for data comparison as it is likely to change.
The lack of consistency in implementing identifiers and applied terminology between scheduling systems causes confusion and may lead to incorrect analysis & reporting.
Let’s review the capability of each scheduling system included in comparison analysis.
Primavera
1. Codes
Primavera has a built-in coding system at project (Project ID) and activity levels (Activity ID). The system automatically controls the uniqueness of data in each record.
2. System identifier
Unfortunately, Primavera doesn’t provide access to project and activity system ID via front ends (client and web). However, the system IDs are available via the backend. Also, there is a trick to access them via XER file but this is a manual and time-consuming process.
3. Screen identifier
Primavera doesn’t have screen identifiers.
Project Online
1. Codes
Unfortunately, Project Online doesn’t have a built-in coding system.
2. System identifier
MS Project provides front-end and backend access to system identifiers at the activity level (UID) and project level (Project ID)
3. Screen identifier
MS project has very convenient screen identifiers and uses them not only to display record numbers but also predecessor and successor columns. It makes MS Project more user friendly but also creates challenges to control data quality as screen identifiers are not stable.
Workarounds
There are two workarounds usually applied to solve the lack of a coding system. Each of them has pros and cons.
UID: Unique but not editable.
Some users use activity level system identifiers (UID) and project level system identifiers (Project ID) instead of codes. However, if a user recreates an activity or uses a copy of the schedule (after what-if analysis) the IDs are going to be different.
Custom field: editable but not unique.
MS Project allows to set up custom fields on both, project and activity, levels. The custom fields are editable, so users are able to recover changes but the uniqueness of values must be controlled manually. This may be not an issue for small schedules and ma be quite a significant challenge for larger program and portfolios.
Spider Project
1. Codes
Spider Project has a built-in coding system in all project tables including a list of projects and activities. The system automatically controls the uniqueness of all codes.
2. System identifier
Spider Project provides front-end and back-end access to system identifiers.
3. Screen identifier
Spider Project has screen identifiers and shows codes (not screen ID) in predecessor and successor columns.
Spider Project also has a built-in version control. It is possible to save a new version of the schedule manually or it’s saved automatically when project as actual project data is added.
Project for the Web
1. Codes
Project For The Web doesn’t have a built-in coding system.
2. System identifier
Project for the web doesn’t provide front-end access to system identifiers.
3. Screen identifier
Screen identifiers are viewable on screen but have no export facility.
Recently Microsoft implemented the “custom fields” feature and now it could be used as a workaround. However, the uniqueness of values must be controlled manually.
Summary
The four scheduling tools examined here all have different capabilities to integrate scheduling data with other systems and each provides a different user experience.
Primavera has a built-in coding system that controls the uniqueness of scheduling data (activities, schedules, resources) but doesn’t have screen identifiers nor does it provide access to system identifiers.
MS Project, on the other hand, doesn’t have a built-in coding system but does have screen identifiers and offers access to a system identifier (UID).
Project for the web only provides a screen identifier, although does have a backend system identifier.
Spider Project has a built-in coding system that controls the uniqueness of scheduling data (activities, schedules, resources), has screen identifiers and provides access to system IDs.
System IDs are always accessible via the backend for portfolio solutions.
All of this ultimately enables true integration with PPM and other tools requiring schedule data.
Alex Lyaschenko
PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma
