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

Agile as an Excuse?

Agile as an Excuse?

by | 22 Apr, 2021 | Blog

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

by | 8 Apr, 2021 | Blog

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

How to visualise WBS out of MS Project?

How to visualise WBS out of MS Project?

by | 12 Dec, 2020 | Blog

Work Breakdown Structure (WBS) is a very powerful view to represent project scope in a hierarchical way.

  • It allows to validate scope and identify potential gaps.
  • WBS is a key input into the schedule development process.

Ideally, use a scheduling tool that supports multiple WBS, as it allows to review project scope from different dimensions. However, if you only have MS Project and Visio available, it might be still sufficient enough to develop a “fit for purpose” version of WBS.

As MS Project supports a hierarchical structure and Visio is a good tool for data visualisation, applying these two could be a strong combo.

There are different methods for this kind of integration. One of those is to utilise Visual Reports feature in MS Project. Just apply this 3-stage approach.

Stage 1: Develop a hierarchical structure in MS Project

1.1 Workshop with stakeholders and teams to decompose project scope into manageable, clearly and comprehensively defined components.

1.2 Capture workshop outputs in MS Project hieracihacl view.

Stage 2: Export data in Visio via MS Project Visual Reports

2.1 Go to MS Project Report Tab > Visual Reports

2.2 Turn off Microsoft Excel samples (as we are only interested in Visio Reports)

2.3 Select Task Status Report > click View

Stage 3: Customise Visio WBS Graph

3.1 Rename Report

3.2 Remove Default Legend

3.3 Select Top Box Shape and go Tasks: Tasks to bring the desired level of WBS

3.4 Go to Design Tab > Re-layout Page to Hierarchy

3.5 Untick Cost and Work in Pivot Diagram properties settings (Pivot Diagram Tab)

3.6 Right-click on Top Box Shape > Data > Edit Data Graphic

3.7 In Edit Data Graphic set up the Fields you like to be visible and their formats

If you like you can save this version as a WBS Visio Template for future use (instead of the MS Project default Task Status Report sample mentioned above).

Just remember, when selecting a template in MS Project, tick on the box “include report templates from:” the location where your customised WBS Visio Template was saved!

Some alternative methods to create WBS:

* Spider Project supports multiple WBS views for the same project.

* Primavera has a single WBS Chart view.

* WBS Schedule Pro can be used as a standalone tool to develop WBS or can be integrated as an add-on to MS Project to visualise WBS.

Julia Lyaschenko

PMO | Program Planning & Delivery Specialist | PRINCE2© Practitioner | SAFe© Agilist (SA)

Start-to-Finish Dependency

Start-to-Finish Dependency

by | 11 Dec, 2020 | Blog

Perhaps every project practitioner is aware of 4 basic types of project dependencies and two types of activity delays.  Unfortunately, their knowledge is often limited by these two facts. If they don’t know how to apply these correctly, it will impact the quality of project delivery model (aka schedule), which could drive wrong business decisions. I am going to publish a series of posts to explain the correct application of dependencies and delays.

Dependency Types

• Finish-to-Start (FS)
• Start-to-Start (SS)
• Finish-to-Finish (FF)
• Start-to-Finish (SF)

Types of delays
• Positive (Lag)
• Negative (Lead)

Let’s start with the most difficult type of dependency. Start-to-Finish relationship is so hard to understand that some companies even recommend avoiding it. However, dependency does not disappear only because it is not in a schedule. This is a real life scenario but the schedule is just not going to reflect it and will not be reliable any more. 

Start-to-Finish dependency

Start-to-Finish is a logical relationship in which a successor activity cannot finish until a predecessor activity has started.

Stop!!! Read this again. And again. Have you already racked your brain by trying to understand how it’s even possible? Don’t worry. You will have a clear understanding of this by the end of the post.

Let’s start from a simple example:

Have you ever watched an Olympic game relay-race? My favourite race is 4 by 100 meters.

Have you noticed that a next runner could start running before the previous runner finished the run? Even more: it’s critical that both runners run in parallel until the next runner runs in full speed and holds a relay pole. Sometimes the previous runner needs to run longer than expected.

In projects  some activities also must overlap.

In other words, we apply Start-to-Finish (SF) dependency when we can only finish Task A once work on Task B has started.

Unfortunately, many project practitioners use Finish-to-Start (FS) dependency with negative delay (lead) instead of using SF dependency. This approach often causes wrong business decisions and project delays. Let’s review how it may happen:

Example
The project has two overlapping activities: Task A could not be finished until Task B is started (1 day overlap). There are two ways to model such a scenario:

a) One PM uses (SF + 1 day) dependency between Task B and Task A.

b) Another PM decided to use (FS- 1 day) dependency between Task A and Task B instead.

Both schedules look similar: all activities have the same start and end dates and both projects could be completed in 10 days. So, what is the issue, then?

Let’s continue…

Task B has additional FS dependency from Task C. The second schedule (with FS logic) shows that Task B and Task C has three days of contingency (total float/total slack) and the second PM has agreed to delay these activities by three days:

The project could still be completed in 10 days.

However, have you noticed that both Task A and Task B don’t have required 1-day overlap anymore? The project plan doesn’t represent reality (!!!). It is very, very hard to notice such issues in the real schedule with many activities and complex logic.

If Task C starts with three days of delay, the whole project will take 13 days!!! This is correctly represented in the first project schedule:

I hope this example not just demonstrates the application of SF dependency but also shows how critical it is to have a schedule which could model realistic project requirements by applying correct activity and logic.

There are also other examples when SF type of dependencies could be applied in a project but a “handover” is the most common application.

Important to remember:

Use SF as Predecessor not successor for handover activities!
In our example Task A is dependent on start of Task B. So, the (SF + 1 day) is PREDISSESOR dependency (not a successor) for the Task A and SUCCESSOR dependency for Task B. There are three conclusions from this rule:

Conclusion N1:

It is theoretically possible that Task A will not have any successor.

It happens when the handover is completed and the predecessor stream doesn’t drive any other activities in the project. It is still good practice to link the activity to completion milestone.

Conclusion N2:

It is theoretically possible that Task B will not have any predecessor.

It happens if the activity is driven by event or availability of resource. It is still good practice to link the activity to commencement milestone.

Conclusion N3:

Task B has to have a successor dependency to another activity apart from Task A.

Otherwise Task B is not required for project.

Could you think about a case in your project when your Start-to-Finish relationship is appropriate?

Alex Lyaschenko

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