Is Missing Logic an illusion of schedule quality?

Is Missing Logic an illusion of schedule quality?

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.

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

    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

    Scheduler in a Project Team Structure

    Scheduler in a Project Team Structure

    Scheduling is a “skeleton” of project control. It connects time, cost, requirements, resources, benefits, risks & interdependencies. Scheduling not only supports project managers to plan work and collect actuals, but also to perform “what-if” analysis and report project progress. 

    • Project scheduling can be performed by a delegated person or can be shared amongst the team.
    • The title of scheduling role varies between countries, industries and organisations. The most common advertised roles are: “Scheduler”, “Master scheduler” and “Planner”.
    • While there is a clear distinction between planning and scheduling, both roles are often performed by the same person.

    Lack of standardisation and variety of experience in a project team often creates different expectations and may cause internal conflicts. It is important that the roles and responsibilities of a scheduler are documented and communicated to the rest of the team.

    Each project team should choose the most appropriate team structure based on project requirements.

    There are 4 main structures that could be applied:

    Team Structure 1

    A project manager performs a project scheduling role. A project manager collects scheduling data from the project team, analyses the schedule and prepares scheduling reports.

    Team Structure 2

    A project manager collects scheduling data from the project team and provides it to a scheduler. The scheduler then analyses and optimises a schedule and produces scheduling reports for the project manager.

    Team Structure 3

    A scheduler collects scheduling data from the project team. The scheduler performs analysis on this data, optimises a schedule and provides a status report to the project manager.

    Team Structure 4

    A project manager assigns an activity owner for each activity in the project. Activity owners collect schedule data from project team members and provide this information to the scheduler. The scheduler analyses and optimises a schedule and provides scheduling reports to the project manager and activity owners.

    Schedule Maturity Planning

    Regardless of team structure, it is highly recommended to perform Schedule Maturity Planning and agree on a required level of schedule maturity. The Schedule Maturity Planning is part of the Schedule Planning Process and has to be performed BEFORE a project schedule is built, not after. 

    The schedule maturity includes scheduling processes, tool, methods and techniques. Also, it defines required scheduling skills and capacity.

    Schedule Maturity Planning has to involve all key stakeholders: project and program managers, scheduler, PMO manager, stream lead. Together they need to decide a target level of schedule maturity and which of the structure above would suit the project needs the best.

     

     

    Alex Lyaschenko

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