“B” for Bottlenecks

“B” for Bottlenecks

Majority of projects/programs manage critical project-related live data via project registers, known as DRICA, RAID, etc.

Each letter represents a type of project metadata: R – risks, I – issues, A – assumptions (or actions), D – dependencies, C – change requests, etc

The list of registers varies based on:

  • Nature of the portfolio
  • Type of project
  • PM delivery methodology
  • PPM tool
  • PMO experience

Apart from traditional registers there are other types of registers which could add value to each project team…

Project Registers
If your Sponsor asks you to speed up your project and complete it earlier, could you present a list of project limitations and explain how the project could be sped up if additional resources and/or financials are available? If not, you may consider this additional type of register to manage your project.

“B” for Bottlenecks

Project bottlenecks is a list of project limitations which prevent the project from earlier completion.

Project bottlenecks could be build based on project resource critical path.

“Bottleneck” register typically includes the following fields:

 Activity

Name of project activity on resource critical path.

Duration
Physical duration of the activity.

Limited by: process/resource/contract/financial

If applicable, “Resource” limit type could broken-down to:

  • People
  • Equipment
  • Material

Resource: resource name (or role)

Critical skill: type of skill

Fast-tracking:
Is it possible to apply fast tracking technique? If yes, how many days (hours) could be saved?

DRAG:
Amount of time that an activity or constraint on the critical path is adding to the project duration.

FLEX:
Amount of time that could be saved by optimising resource allocation.

Project bottleneck optimisation recommended best practices:

  • Ideally, we want all bottlenecks to have technical or contract types. It means that project resources are fully optimised. In that case project resource critical path and project critical path will include the same activities.
  • Not all bottlenecks are bad. Some projects use planned bottleneck to smooth project delivery. For example, we do not want to spend all funds until the next financial tranche is available. Or we limit the number of changes per release.
  • Activity DRAGs help to select the best way for the schedule crashing while activity FLEX helps to optimise project resource assignment. 
  • DRAG can be positive or negative. Negative DRAG shows the amount of time that could be saved if activity duration is increased. 
  • FLEX can be positive or negative. Negative FLEX shows the amount of time that could be saved if the number of assigned resources is increased.
  • It is valuable to understand vendors bottlenecks and whether they could be removed by additional funds.
  • Agile projects always have bottlenecks, otherwise, the whole backlog could be delivered in one sprint. Usually, Agile projects are constrained by a particular type of skill. Often it is not obvious as everyone is working hard which creates an illusion of productivity.
  • Some project managers prefer to keep an eye on near critical path activities and to be aware of a type of resources which could be critical. 
  • Some projects use criticality index in their “bottleneck” register or directly in the schedule (if their scheduling tool supports it). Criticality index takes into account project risks data. It informs how often a particular activity was on a critical path during risk simulation calculation. Non-critical activities may have a higher chance of becoming critical during project execution and need special attention.
  • DRAG, FLEX and Criticality index for Primavera and Microsoft Project schedules could be calculated with a schedule optimisation tool, like Spider Project. Spider Project supports resource critical path, DRAG, FLEX and Criticality indexes.
  • Project “bottleneck’s optimisation” is a repetitive  process. After the current project bottlenecks removed, the analysis gets repeated until all possible and desired “bottlenecks” optimised.

Alex Lyaschenko

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

Project Success Criteria (PSC)

Project Success Criteria (PSC)

In project constraints golden triangle, which of the criteria is more important: Time, Cost or Scope?

If your project is behind the schedule and you have an opportunity to speed up project delivery by applying extra resources to complete testing earlier, what would you do?

  • Spend extra budget to bring the project back on schedule? (Time over Cost)
  • Stay on the existing plan: be on budget but late? (Cost over Time)
  • Descope part of the project to reduce the duration of testing? (Time over Scope)
  • Take a risk to descope some test cases to reduce the duration of testing? (Time over Quality)

The answer to this question depends on how each component of the project golden triangle impacts project Benefits (financial and non-financial).

However, it is hard to make a decision as we need to compare incomparable measures: time, cost, scope, benefits and, sometimes, quality. So, what do we do?

Project Success Criteria (PSC)

Project Success Criteria
The best practice is to implement “Project Success Criteria” (PSC) – a single criterion that could connect all of these measures together and become your Safety Net.

Let’s consider this simple example:

Example: 

Assume that project financial benefits are based on two outputs (sub-projects/ releases/sprints/ets). Let’s also assume that projects outcomes could be achieved in the same time when the outputs are delivered.

If the Output N1 is delayed:
• The first two months of delay will reduce benefits by X$ per month, then Y$ per month.

If the Output N2 is delayed:
• A delay within the financial year wouldn’t have any negative impact but if it slips to the next FY, the impact would be Z$ per quarter.

In this example the “Project Success Criteria” could be calculated in Dollars by linking scope, cost, time and benefits.

The PM could perform “What if” analysis and check how the “Project Success Criteria” would change.

Of course, projects may have none-financial benefits or more than one type of benefits. In that case the “Project Success Criteria” could be measured as a virtual parameter, which combines the golden triangle with all types of project benefits.

As traditional scheduling tools (Primavera and MS Project) don’t support project income and benefit integration, a schedule optimisation tool, like Spider Project, has to be applied.

Spider Project Project Success Criteria
In Spider Project, it is easy to configure a “Project Success Criteria” by using custom fields.
Custom fields support:
• Advanced formulas;
• Project Data integration;
• Project Expenses and Profit integration;

So, “Project Success Criteria” could be a simple proxy or very detailed complex parameter.

“Project Success Criteria” could be used as the main optimisation creation for project schedule calculation.

 

This technique allows PMs to present proposed project Optimisation options to Sponsors and Steering Committee to enable weighted and informed decisions.

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?

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

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

3-Points Estimation Technique

3-Points Estimation Technique

The most useful scheduling technique which, in my opinion, has to be used in each project is 3-Points estimation technique. It is simple to use, it improves team productivity and project performance.

As projects complexity level keeps growing, projects become less predictable and project plans are usually built based on expert opinion, rather than accurate historical data. Very complex projects are so unpredictable that companies move from Waterfall to Agile delivery methods, where 100% of activity estimation is based on expert opinions.

Regardless of a delivery method, when team members are forced to provide a single estimation (duration or story point) for each activity, they have to include a “risk factor” as a hidden contingency. This is leading to a number of challenges:

• PM is not aware of activities with a high-risk factor
• PM doesn’t control contingency
• Opportunities to complete activities earlier decreased due to Parkinson’s Law
• Risk to activities delay increased due to Student Syndrome

Parkinsons’s Law

Parkinson’s Law
work always expands to fill the time available for its completion.

Some team members will use allowed durations even if the risk is not actualised.

Student Syndrome

Student Syndrome
An activity owner is likely to delay a start of activity as “hidden contingency” creates an illusion that there is still enough time to complete this activity on time. However, if the risk is materialised there is no sufficient time to complete the activity on time as hidden contingency has already been spent.

3-Point Estimation

3-Point Estimation:

When activity estimation is based on an expert opinion, it’s always preferable to capture three estimations to understand potential variance of durations

a) What is the BEST possible (optimistic) scenario to complete the activity?

b) What is the WORST possible (pessimistic) scenario to complete the activity?

c) What is the MOST LIKELY scenario to complete the activity?

• It doesn’t take much longer to capture 3 numbers instead of 1, but it enables immediate understanding of activities with hidden risks;

• It is important to capture BEST and WORST estimations before the MOST LIKELY estimation. It forces an estimator to think about potential issues before MOST LIKELY duration is provided;

• Activity TARGET duration could be calculated based on 3 estimations. PERT formula could be used as an initial proxy.

• The key project delivery dates could be calculated with two different approaches:

a) based on TARGET durations;
b) based on OPTIMISTIC durations with overall contingency bucket;

• Regardless of a target approach an activity owner has to plan an OPTIMISTIC duration as his own target, but not to be punished if it takes longer to complete the activity.

• It’s always useful to run analysis on the deviations from optimistic and target durations. Usually after 20% of project progress is achieved, as normally there is sufficient data to understand if target dates of outstanding activities need to be adjusted.

• Activity owners always appreciate 3 points estimation technique, as it takes pressure from them.

• The method is a great alternative to story points technique in Agile projects.

• 3 estimations are also a base for more advanced scheduling methods: Monte Carlo Risk Analysis, 3 Scenarios Method, Probability of Success.

Target Durations

A target activity duration could be calculated with or without a weighted factor:

a) Triangular technique recommends using average of three estimations:
Target = (O + ML + P) / 3

b) PERT technique recommends using a weighted approach:
Target = (O + 4 * ML + P) / 6

PERT = Program Evaluation and Review Technique

I prefer PERT, as it gives a more accurate prediction. Optimistic and Pessimistic scenarios may occur but usually, it doesn’t happen as often as Most Likely scenario and PERT address it.

Example: Travel to office

In an ideal scenario with all green lights and no traffic, I can reach my office in 25 minutes. In very bad traffic it’s never been longer than 60 minutes. Typically, it takes 35 minutes.

O = 25 mins
P = 60 mins
ML = 35 mins

Target travel time (average): (25+ 60 + 35) /3 = 40 mins
Target travel time (PERT): (25+ 60 + 4* 35) /6 = 37.5 mins

Analysis

PERT formula is a good proxy if there is no actual data available. However, after ACTUAL completion dates become available for analysis, the formula could be adjusted to address specifics of the project, organisation or even experience of an estimator. Some estimators are too optimistic, others are too conservative.

For example:
T = (2 * O + 5 * ML + P) / 8

In some cases, I had to revise outstanding target dates for the whole project, in some for end of current phase and in some just for one or two estimators.

Scheduling Tools

Huge advantage if this technique is that TARGET estimations could be easily calculated in Excel. However, it is very convenient to use a scheduling tool instead. It saves time, support “What if analysis” and could be used for more advanced risk evaluation methods.

MS Project versions 2013 support PERT analysis. Target durations could be calculated based on PERT formula or the formula could be adjusted.

MS Project version 2016+ doesn’t support PERT (!!!). However, Project 2016 PERT Add-in is available.

 

Primavera doesn’t support PERT analysis. Target calculation has to be completed in Excel and then entered as planned durations.
However, external tool – Primavera Risk Analysis (previously known as PERTMASTER®) has integration with Primavera and could be used for PERT or Monte Carlo analyses.

Spider Project has built-in 3 points estimations and supports advanced risk methods: Monte Carlo Risk Analysis, 3 Scenarios Method & Probability of Success method.

For more mature projects Spider Project allows to link Optimistic, Pessimistic and Most Probably versions of a schedule together. The versions could vary not just with different activity durations but also with different activities and different logic between activities to address risk contingency and risk management plans.

Spider Project has a free fully-functional version limited by 40 activities. This version could be used to develop a fragment of a schedule with 3 points estimation. The fragment then could be exported to Primavera or MS Project.

Spider Demo version:

A lot of 3rd party tools available for PERT and Monte Carlo analysis.
Acumen Risk is quite popular enchantment. Especially for scheduling tools, like Primavera, which don’t have built in risk management.

Agile

I will write a separate topic on how to enhance Agile delivery with 3 points estimation technique. As a simple alternative ask to provide 3 durations and calculate Story Points based on these estimations. It gives much better visibility of a risk factor and improves team performance.

Summary

• When activity estimation is based on an expert opinion, it’s always preferable to capture three estimations instead of one.

• Project may continue to use only Most Likely estimations but knowledge of Optimistic and Pessimistic scenarios should improve project performance as “Parkinson’s Law” and “Student Syndrome” issue are going to be mitigated.

• Target durations are more accurate comparing to Most Likely option as it takes risk and opportunities into account. Target durations could be calculated based on 3 estimations. PERT analysis could be used as a good proxy to start from.

• More advanced risk methods could be applied to use 3-points estimation data.

Alex Lyaschenko

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

Project Dependencies Types

Project Dependencies Types

Some companies define project interdependencies as “Hard” or “Soft” based on a type of constraint in their scheduling tool. In other situations, project interdependencies indicate a level of risk as probability, impact or risk exposure. Some project management practitioners define Hard vs Soft based on a level of contingency in a provider or receiver schedules. This inconsistency in project interdependency definitions sometimes creates real confusion amongst project managers.

It is quite common to have a different management approach to Soft and Hard dependencies as they  have different risk levels. With such definitions, it is easy to miss a point when a dependency changes it’s type from Soft to Hard.  And since a Hard project interdependency often sits on a critical path, this situation turns into an issue that leads to the whole project delay and sometimes even generates “a domino effect” across the entire Program or Portfolio.

A dependency type is supposed to be a stable characteristic, which supports Project managers in their agreement on whether their projects are dependant or not.

SDPD Interdependency Management Framework defines three types of dependencies: Hard, Soft and  Virtual based on the nature of dependency. These types are stable, mutually exclusive and support project managers in dependency identification and risk analsis. Also, a PMO could develop appropriate solutions to manage each type of dependency.

Hard Dependencies: A -> B
Project A (Provider) is providing a deliverable to Project B (Receiver). Project B (Receiver) would not be able to deliver all its capabilities successfully if Project A (Provider) delays or does not provide a required deliverable to Project B (Receiver) within agreed time and quality.

Soft Dependency: A~>B
Project B (Receiver) dependant on Project A (Provider), but Project B (Receiver) would be able to deliver project capabilities even in a case when Project A (Provider) is delayed or cancelled.

Virtual Dependency: (A,B,C)
A virtual dependency is a dependency when different projects operate in the same environment and impacting each other. A virtual dependency doesn’t have Provider and Receiver project.

Often, but not always, Hard dependency is associated with a project risk and Soft dependency relates to opportunity. Virtual dependency could be a risk or an opportunity and is not always associated with an event or a deliverable. Often it requires visibility of project activities and is less stable.

Examples:

Hard:
• Project A provides a design to project B and project B is not able to progress without the design. 

Soft:
• Project A delivers a new PPM tool, but project B could use old PPM if the new system is not available on time.

Virtual:
• Two projects need the same critical resource during the same period of time
• Three projects need the same test environment during the same period of time 
• Two projects deliver training to the same group of people during the same period of time
• Benefits could only be realised when two outputs delivered by different projects.

SDPD Interdependency Management Framework also includes some other critical dependency characteristics, methods and tools which support Programs and Portfolio delivery optimisation.

Alex Lyaschenko

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