Is Missing Logic an illusion of schedule quality?

Is Missing Logic an illusion of schedule quality?

by | 7 Aug, 2021 | Blog

Scheduling consultants often mention “Missing Logic” as an obvious schedule quality check.
I believe it is not as obvious as it seems. This check may create an illusion of good quality of dependency data and hide critical issue(s) that may cause project delay.

The rule of thumb is “Each activity, except first and last activities, must have a predecessor and successor”. It is logical to have a metric that verifies if this rule is followed. This metric is known as the “Missing Logic” or “Open ends” metric. If a schedule has open-end activities, it requires  attention.

However, if there are no activities without a predecessor and a successor, it DOES NOT mean there are no “lost” or “broken” dependencies in the schedule.

Even more, the “lost” dependency may impact the critical path and reduce the duration of the schedule, but the “open ends” metric still would be “Green”. It creates an illusion that the schedule doesn’t have issues with dependencies and no additional check is required. The “lost” and “broken” dependencies would not be identified until it is too late, and the project delivery dates are impacted.

Broken Dependency

A“broken” dependency is a dependency with incorrect characteristics (type, lag, ect).

Path Convergence & Path Divergence

Any schedule is likely to have activities with multiple predecessors and/or successors. It is possible that after a critical dependency has been removed, the schedule still doesn’t have open ends activities.

Path Convergence
A relationship in which a scheduled activity has more than one predecessor.

Path Divergence
A relationship in which a scheduled activity has more than one successor.

Original schedule:                                                                                                         

Critical Path: A B D E G

“Missing Logic” check: Green

Then a scheduler by mistake deleted one critical Dependency between D and E activities. Now the schedule has a new critical path and shorter duration, but the “Missing Logic” metric is still “Green” as all activities (except first and last) still don’t have open ends.

This example shows that we need another approach to manage the quality of dependencies.

The only way to check the quality of dependencies is to compare the list of dependencies against Corporate Norms or any other reliable set of dependencies, for example, in a baseline schedule.

As Primavera and MS Project users don’t have direct access to a list of dependencies, one of the options could be to load the schedule into the tool that has this capability.

Spider Project provides access to a list of all dependencies with all dependency characteristics: predecessor and successor codes and title, dependency type, lag, lag units, lag type, lag calendar, etc. Dependency quality analysis could be performed within the tool, or dependencies could be exported to Excel or BI tools.

Conclusion

“Missing Logic” metric is a required but not sufficient metric. It may create an illusion that the schedule dependencies are in good shape.

Dependency quality analysis have to be performed against reliable dependency data and incorporate analysis of both “lost” and “broken” dependencies.

Alex Lyaschenko

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

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