Scheduling Tools Comparison Analysis. Data Identifiers.

Scheduling Tools Comparison Analysis. Data Identifiers.

by | 8 Jul, 2021 | Blog

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

    Program vs Portfolio Centric Scheduling

    Program vs Portfolio Centric Scheduling

    by | 5 Jun, 2021 | Blog

    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 is for IT Projects. Myth or Reality?

    Agile is for IT Projects. Myth or Reality?

    by | 26 Mar, 2021 | Blog

    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