Scheduling Tools Comparison Analysis. Data Identifiers.

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:


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.

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.


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.


    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.


    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

    Program vs Portfolio Centric Scheduling

    Program vs Portfolio Centric Scheduling

    There are two main perspectives to manage projects and programs in any organisation: Project/Program centric and Portfolio centric.

    Program centric approach

    This approach relies on an experience and knowledge of a program team. Schedule maturity and quality defined by program stakeholders, especially by PMO manager, Program manager and Master scheduler/planner.

    Portfolio centric approach

    This approach recognises that while each program is unique, all of them operate in the same environment and need to follow the same critical processes (project gating, procurement, reporting, etc.). Therefore, this approach focuses on templates, corporate norms and the implementation of project practices that support all types of programs.

    Advantages of program centric approach include:

    • Easier to address program-specific requirements and meet stakeholder’s expectations by implementing fit-for-purpose program delivery methods & techniques
    • A master scheduler usually has wide-ranging control over all schedules in the program and can implement practices that would too complicated to be used at the portfolio level
    • Easier to manage dependencies between projects within the program
    • Easier to manage program resources
    • Fewer requirements for scheduling tools, as a manual workaround could be an option

    Disadvantages of program centric approach include:

    • It is difficult to mature portfolio management if scheduling data is not centralised and programs use different scheduling practices
    • Historical information and lessons not utilised in future programs properly
    • Activity durations and dependencies are less reliable
    • Harder to mature portfolio interdependency management
    • More difficult to optimise resources across Portfolio
    • Programs may be aware of potential enterprise constraints (funds, resources, equipment, corporate services, change management, etc) but don’t have a complete picture to mitigate related risks appropriately

    Points to consider

    • It is often a challenge to find a balance between implementing consistent scheduling practices across all projects in a portfolio and keeping a level of flexibility to support program scheduling.
    • Program centric delivery may have portfolio stakeholders (EPMO, portfolio schedulers, etc) but their influence is usually not that critical and a program master scheduler has enough flexibility to implement relevant scheduling practices.
    • It is easier for a program to avoid portfolio scheduling requirements if scheduling and schedule reporting tools are not integrated, as it is challenging to control the maturity and quality of each individual schedule without a centralised portfolio scheduling tool.
    • Most consulting companies provide scheduling services as a  “body shop” to support program centric scheduling. Usually, their scheduling consultants have profound knowledge of essential functions in scheduling tools to support program delivery but have quite limited experience in a portfolio centric environment.
    • If a master scheduler moves to another program, it is likely that scheduling practices are going to be revised. Each master scheduler understands “Best scheduling practices” differently. The impact may vary from the rollout of new quality filters to the complete change of a scheduling tool.
    • When a scheduler moves from program scheduling to portfolio scheduling, often they consider their portfolio just as a ‘large program’ and try to apply program scheduling practices at a portfolio level.

    Resource Management

    Program centric delivery defines resources (people, financials, equipment) and materials requirements (skillset and time) and comes up with the solution to secure them. A project plan is usually built based on the assumption that resources will be available when needed. Portfolio prioritisation is usually performed based on strategic priorities and financial limits without taking non-financial constraints into account.

    Portfolio centric delivery defines corporate resource norms (skills, productivity), fragments of work (templates) with loaded skills, and portfolio resource and material constraints. Portfolio prioritisation is based on strategic priorities, financial and non-financial limitations.


    Scheduling Tools

    The most popular scheduling tools (P6, MS Project, Spider, Asta, etc. ) have different features to support Program and Portfolio centric delivery.

    Some features could be critical for program delivery but not relevant for portfolio scheduling and the other way around.


    Alex Lyaschenko

    PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

    Agile as an Excuse?

    Agile as an Excuse?

    It seems that Agile is too often used as an excuse to avoid careful planning and preparation. In this post we are going to review the root cause of this phenomenon.

    Project Allocations

    The majority of large government agencies and non-government organisations operate based on the annual financial cycle. It means that each year their portfolios receive a financial allocation.

    The allocation means that the funds are held for a particular part of the portfolio (sometimes called sub-portfolio), a program or a project. Carry-over projects are usually able to use funds straight away but new projects and programs are still required to go through an approval process. Access to the yearly budget is very important for portfolio managers as without it they won’t be able to deliver critical changes.

    The challenge here is that during the prioritisation, which typically happens 2-6 months prior to commencement of a new cycle, portfolio managers have only a rough idea of how much they would be able to spend based on known inflight and pipeline projects profile. However, they are aware that significant overspend or underspend of funds in a current financial year is likely to influence the prioritisation results. If this happens it could be very hard to increase the allocation of funds in the future. Financial prioritisation is always a big political game in large organizations.

    Project Budgets

    is npt Also, the top-down approach would be based on reported portfolio performance, which often has a level of optimism bias.

    There are two main approaches to manage planning for project budgets and prioritise allocation: top-down and bottom-up.

    Organisations with a mature scheduling level are able to complete bottom-up planning and manage project prioritisation based on corporate constraints:
    • Critical resources;
    • Interdependencies;
    • Corporate services;
    • Enterprise risks;

    However, if the level of maturity is not quite at the required level yet, the portfolio managers could only rely on the top-down approach which typically has much lower accuracy and also brings the following challenges:

    • The top-down approach is normally based on some unique models/spreadsheets that a Portfolio manager would bring to an organisation. Whilst it is possible to align individual spreadsheets, it is could be  very hard to track changes if there are not in the corporate standards.   
    • Also, the top-down approach would be based on the reported performance of projects, which not linked to delivery schedules.

    Project Initiation

    After the allocation is approved, the next critical step for portfolio managers is to initiate pipeline projects as soon as the financial year commenced. It guarantees that the allocation would be locked against these projects. Usually, in case or reprioritisation, in-flight projects have higher priority against pipeline initiatives.

    After formal approval is granted these projects and programs are sometimes put on hold or progress very slowly. Program managers often hesitate to baseline schedules despite the fact these projects already have formal commitments. They just don’t have a reliable delivery schedule at this time yet. In some cases, schedule development even commences after the approval, not before.

    Then, around the third quarter of the financial year, it becomes clear that projects forecast accuracy is not at the expected level. Some of the programs have significant underspent, others – report overspent. Portfolio managers are lucky if these underspends and overspends could compensate each other. However, more often project delivery delays result in overall portfolio underspend. When it is discovered it is too hard to spend the planned allocation. Even though the portfolio has pipeline initiatives, typically the expenditure at the initiation and planning phases of delivery is quite low and these projects are likely to consume next year’s budgets rather than solve this near horizon issue.

    Once, one of my colleagues, a senior project manager, complained that he was assigned to a new project at the end of the financial year. After initial discovery, he realised that the main target for this project was to find a way to spend outstanding allocated funds. What was going to be delivered was a secondary priority. I also have seen a similar pattern in some portfolios. When after a first quarter there was a high risk of portfolio overspend, in second quarter funds were levelled and in a third quarter, a significant risk of underspent was discovered.

    Organisations are looking for solutions to solve this challenge.

    Portfolio Predictability

    Generally speaking, there are two main ways to improve financial predictability: to mature existing approaches or to implement fundamentally new delivery methods. Often it is translated as to mature Waterfall delivery or to implement Agile, as an alternative.

    Interestingly, non-mature Agile may cause many issues but would solve allocation challenges as Agile usually has an almost flat spent curve.

    Let’s review specifics of Agile delivery in the context of the challenge we just discussed:

    • Agile projects don’t have a baseline against which the results could be measured;

    • Project delivery is based on non-quantitative “values” rather than quantitative benefits.

    While these two points actually present a disadvantage of Agile delivery, the underperforming portfolios are now able to use Agile as a “shield” and explain that original commitments haven’t been delivered as the priorities have changed. They measure portfolio success only based on expenditure with much improved results.

    If Agile is able to solve the allocation challenge, then the simplest Agile framework is likely to be chosen as an alternative to Waterfall. Scrum, which was never designed for project delivery, seems to be the most popular Agile method as it could be implemented relatively quickly and is quite sufficient to be used as the “shield”.

    Many projects using Scrum today don’t have real needs or opportunity to deliver changes every week or even every month. They just use it as an excuse to avoid careful planning and preparation.

    Acknowledgment of a Problem is the first Step towards its Solution

    Not all portfolio managers choose Agile just to solve the allocation issue. They consider Agile as a better alternative to Waterfall for other reasons. There are quite a few reasons why Agile could improve project delivery but it seems that many organisations are just confused by consulting companies promoting Agile. The companies promise improvement of delivery by comparing non-mature Waterfall with mature Agile. In reality, if an organisation wasn’t able to reach the desired level of project delivery with Waterfall methods, it is very likely that they also could not reach mature Agile. In fact, Agile requires a higher level of discipline.

    As a result, many organisations landed with a “Hybrid” model, despite the fact that “Hybrid” project delivery frameworks have not been thoroughly developed yet. Let’s take this gap into consideration and stop ignoring it. “Hybrid” should not be just used as an excuse to avoid careful planning and preparation for allocation challenges.

    If a portfolio needs to improve projects delivery, not just solve the financial challenges, consider implementation of best planning and scheduling practices instead of avoiding them!

    Alex Lyaschenko

    PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma

    Agile is for IT Projects. Myth or Reality?

    Agile is for IT Projects. Myth or Reality?

    There is a general acceptance that Agile delivery is good for IT projects and many IT departments in various size organisations are considering or have already started adopting Agile frameworks.

    At the same time, I’ve heard that some of the IT project managers complained that Agile is not quite applicable to their projects and it would be much more effective to use Waterfall delivery approach instead.

    So…”Agile is for IT projects” statement – is it a myth or reality?

    Agilist might bring an argument that Agile is applicable not just for IT projects. It is also good for other types of projects like marketing, legal, electronic, construction, etc. They are correct, but…

    Whilst the Agile Manifesto was originally developed for software development, if we would just replace the word “Software” with “Product” we can find that many product development projects may definitely benefit from Agile delivery approach.

    So, Agile is good for both, IT and product development projects, right? Not quite.

    Not all IT projects deliver product development or enhancement

    IT departments typically have two types of engagements with a business: 

    • Project driven by IT
    • Business project with IT component.

    Examples of IT projects:

    • Software development
    • Software enhancement
    • Software upgrades
    • System replacement
    • Security
    • New equipment/refreshes
    • System backend changes
    • Network infrastructure changes
    • Office moves

    Not all of the projects above could be categorised as product development or enhancement.

    In my observation, in large non-software development companies, IT is typically responsible for less than 20% of projects but is engaged across 50%-80% of the portfolio.

    Not all IT projects are urgent and have unclear requirements

    • Not all IT projects are urgent.
      Some products DO NOT need to go-on-market and release new features for customers as soon as possible.
    • Not all IT projects have changing requirements and environment. A lot of IT projects are delivered without a single change request.

    If a business has a clear goal and enough time to accomplish a project, the business should consider an alternative to Agile development methods.

    Some of projects have to be predictive

    Agile delivery has quite a few benefits and the main one is a rapid delivery of product changes to the customers. This implies many project releases. IT project managers could give many reasons why multiple releases could not be possible, or not effective:

    • Limited implementation windows;
    • Large marketing campaign;
    • Regulatory deadlines;
    • Cost of retesting;
    • Security approvals;
    • Expensive or Risky parallel run (systems replacement);
    • Limited time to implement changes;
    • Hardware upgrade;

    The implementation approach could be a critical factor that defines the best project delivery method.

    Some companies have implemented Agile delivery methods but are not able to afford a continuous release-based approach. They use sprints to develop new features/enhancements but release changes into production only 2-4 times per year. In this case, the business should consider the multi-release Waterfall method instead.

    Points to remember:

    • Agile is good for product delivery, including but not limited by software products
    • Not all IT projects related to product delivery
    • IT departments should implement Agile delivery as a potential alternative to Waterfall, not a replacement
    •  During a project initiation stage, it is critical to understand if the project could be delivered by continuous releases, multiple releases or only with a Big Bang approach
    • Multi-release Waterfall is a great alternative to Agile if frequent delivery is not possible

    Alex Lyaschenko

    PMO | Portfolio Planning & Delivery | PMP | P3O Practitioner | AgilePM Practitioner | Six Sigma