Assumptions and Risks. What is the difference?

Assumptions and Risks. What is the difference?

by | 11 Mar, 2021 | Blog

In a project management language, an assumption is an “event” with a probability of over 50%. If the probability of the event is also less than 100%, it is a risk!!!

An assumption is something that you assume to be the case, even without proof.

While there is a clear relationship between assumptions and risks, they have different point of view:

  •  If the risk event happens then, the project is affected.
  •  If the assumption event doesn’t happen, then the project is affected.

Example:

Assumption:

We assume that critical resources are going to be available when required.

Risk:

If the critical resources are NOT available when required, then there is a certain event that will cause an impact.

Key Points to Remember:

  • Risk associated with an assumption (as any other type of risk) has a probability and an impact.
  • Risk associated with the assumption has low (<50%) probability. However, it doesn’t mean that impact is also low.
  • Some of the assumptions may have 100% probability. In this case, these are facts, not risks. It is still important to document them if there is a chance that not all project stakeholders are aware of these facts.
  • Unless it is possible to prove that an assumption is a fact, it is better to assume that it is a risk.
  • Assumptions could be managed in a risk register or in an assumption register. In that case, two registers need to be integrated.
  • Risks with low probability and low impact often have “Accept” mitigation strategy. Assumptions are also often just accepted and don’t have a mitigation plan. However, if the risk associated with an assumption has a medium or high impact, the “Accept” mitigation strategy may not the best mitigation strategy.
  • A risk associated with an assumption also may have a positive effect. In this case, it is an opportunity:
  • If the threat event happens then, the project is negatively affected.
  • If the opportunity event happens, the project is positively affected.
  • If the assumption event doesn’t happen, then the project is positively or negatively affected.

Example:

We assume that Australian borders are going to be closed till the end of 2021. Opportunity: if borders are opened earlier, we may be able to conduct a conference earlier (in December 2021).

Types of Dangerous Assumptions

Unrecognised

Assumptions are made “automatically” by an individual, without even realising it.

Unstated

Some assumptions could be obvious for someone, and this person doesn’t see a need to communicate this assumption to the rest of the team. Other project stakeholders may not have the same knowledge or information. They would act differently if they would be are aware of these uncommunicated assumptions.

Unquestioned

Assumptions that are “pushed” without an open conversation. A project team member may be aware of the high risk associated with this assumption but doesn’t feel comfortable to raise the concerns.

Naive assumptions

Some assumptions are based on lazy or unimaginative thinking.

Productive

Pragmatic assumptions that may be obviously untrue but designed to motivate positive behaviour.
The assumption is that the project manager is skilled enough to deliver the project.

Unrecognised & Unstated assumptions are not documented, and project stakeholders are entirely unaware that someone is “making things up”.

Dangerous assumptions may have a high (>50%) probability of risk associated with the assumption!

As a result, the project team could get in a serious trouble , as a proper risk response is not prepared, and risk not mitigated.

Alex Lyaschenko

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

Planning vs Scheduling

Planning vs Scheduling

by | 4 Mar, 2021 | Blog

Are you aware that the majority of projects develop a schedule but actually don’t have a plan?

Often projects produce a version of a project plan which covers both planning and scheduling. They are not able to differentiate one from another when required. 

 

How is project planning different from scheduling? What are the best practices in project planning today?

The difference between planning and scheduling is that planning addresses what will be done and how it will happen, while scheduling addresses who will do it and when.

How to apply this in practice? How could we develop a project plan without start and end dates?

The best practice is to develop a project plan as a DYNAMIC PROJECT DELIVERY MODEL (DPDM) and then to apply different techniques to schedule activities.

Project Delivery Plan

A planner builds a project delivery plan as a dynamic project delivery model (DPDM).

The model defines:

  • Project scope breaking into manageable pieces (tasks, activities, deliverables, user stories, etc.). Let’s call them ‘activities’ in this post
  • Characteristic for each piece (skills, volume, limits, materials, etc.)
  • Project constraints (logic, committed dates, resource, material and financial limits)
  • Deadlines
  • Project Risks & Opportunities

The model doesn’t define:

  • Assigned resources
  • A target sequence of work
  • Target start and end dates of activities

Project Schedule

A scheduler assigns resources (based on supply, demand and priorities), adds actuals, and calculates the start and finish dates for outstanding activities.

Schedulers use different techniques to find out the best combination of resource assignments.

Schedulers are often limited by a scheduling tool they have to use. This tool often determines a possible level of schedule optimisation. Advanced scheduling tools are able to calculate Resource Critical Path and identify the earliest delivery options.

Durations

The project delivery model defines the type of required skills but doesn’t have any specific resources assigned yet. Available resources are usually grouped by their skills and listed in resource pools.

Activities in a DPDM model don’t have target durations, except when this is required by a technology process. Duration of activities is only calculated when a resource(s) assigned!!!

Start and Finish dates

Planning defines technological constraints:

  • Logic between activities: you must be pregnant before giving a birth
  • Skills: you need to be a woman to be able to deliver a baby
  • Technological limits: 2 women can’t deliver a baby in 4.5 months

Scheduling defines current limits & priorities:

  • Resource & material limits: SMEs are limited, etc
  • Financial limits: allocated budget, executive contingency, etc
  • Priorities: values

A sequence of activities depends on:

  • Technological constraint
  • Current limits
  • Duration of activities

The start and finish dates of each activity depend on the sequence and durations of activities.

Also, there are some other items to consider while planning & scheduling:

  • A resource may have different skills and to be assigned to different resource pools. Also, a resource may have a different productivity rates in different skills:

Resource Alex has skill “X” with productivity 100% and skill “Y” with productivity 50%

Resource Julia has Skill “X” with productivity 50% and skill “Y” with productivity 100%

Resources Alex and Julia assigned to Resource Pool “X” and Pool “Y”

  • Some activities could be completed more than one way or with a different type of resources:

 We could dig a trench with a bulldozer or a spade.

  • Type of resource may have different productivity rate:

Bulldozer – 1 km/h, spade – 0.1km/h

  • Some activities could be performed as a team only:

Car and driver

  • Resource assignments, a sequence of work, start and end dates of activities are dynamic characteristic of the project plan. However, sometimes it is useful to fix assignments and dates, even though the better option is available. 
  • It is useful to store resource characteristics (cost, skills, productivity) in corporate reference books and reuse them for different projects. Project actuals could be used to review and adjust the corporate norms.
  • Fragments of DPDM could be reusable for different projects and significantly speed up a project development process.
  • DPDM could be developed as a single version or may include more than one scenario (sequence of work).
  • An ideal scenario is based on unlimited resources, realised opportunities and mitigated risks and defines the earliest delivery dates. The probability that the project will be completed as per the best scenario is close to zero but it is useful to understand theoretical limits. Better results could be achieved only with a change of scope.
  • The quality of DPDM depends on methods to collect and maintain project data, features in a planning tool and the skills of a planner to develop the plan.

A low maturity schedule could be developed without planning and used for tracking project activities.

However, if a project needs to have a high maturity schedule, that can be used for analysis and decision making, then the Dynamic project delivery model is the best approach. It allows performing “what-if” analysis very quickly without a need to rebuild a schedule every time when changes required.

Alex Lyaschenko

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

Next-Gen Project Risk Management Technologies

Next-Gen Project Risk Management Technologies

by | 11 Feb, 2021 | Blog

Mature project management is critical for innovations. At the same time, innovative technologies could also be applied for project delivery. This would speed up technology development and implementation even further. Next-Gen technology platform for Project Risk Management could completely change our view of Project Management in the near future. Are you ready for this change?

In episode N S3E55 of Project Chatter podcast two experts discussed “How Technology is driving Next-Gen Project Risk Management”.  

Project Chatter Podcast

Both presenters have perfectly described various challenges in taking existing systems for project risk management to the next level. I don’t think they have mentioned though that such “intellectual project management systems” already exist and even widely used in some parts of the world, especially for major infrastructure projects. I am also very passionate about this topic and would like to discuss this a bit further.

There are the key challenges and ideas that I’ve captured from the podcast episode:

  • Standardisation of project management data is the most critical constraint now. We have a lot of historical data, but it is hard to reuse.
  • There is no feasible progress in risk management functionality in Primavera and, even, there are no expectations of having any valuable improvement soon.
  • Construction, comparing to the Oil & Gas industry, is not mature in risk management.
  • New methods to manage project risks expected from AI systems.
  • Risk management has to be integrated with a scheduling platform to embed results of the schedule risk analysis back into the schedule.
  •  It is hard to educate students and PMs to apply risk methods correctly as Risk platforms are too expensive.
  • Next-Gen systems are going to support us with Risk identification process (based on historical data).
  • Role of schedulers could be significantly different after such systems implemented.

Let’s review how the above challenges addressed in the “Next Gen” project management tools and where this could take us in the future. I am going to use Spider Project, project management tool, as an example. This tool has the most mature schedule risk management and very sophisticated authorisms, but there are other tools on the market, which could offer similar solutions.

Standardisation

  • Majority of project schedules are duration or effort driven. It makes data standardisation process very difficult.
  • Duration in many project activities depends on assigned resources, their current availability, practical quantity and productivity.
  • Activities in different projects may have the same type of work but have different volume of work which also has an impact on activity durations.

Data standardisation has to be volume-based

Corporate norms (or standards) usually include all aspects of project management:

• Standard WBS(es);
• Types of work;
• Type of resources (people & equipment);
• Skills;
• Resource productivity;
• Material norms;
• Cost per unit;

Activity durations in different projects are calculated based on a volume of work and available resources. 

It is a dynamic characteristic, not a fixed type of data.

If the volume of work or resources demand/supply is changed, the system could automatically re-adjust durations, offer the best sequence of work and recalculate resource critical path.

Risk Database

Additionally, corporate norms should include “historical risks” based on the lesson learned from previous projects. Enterprise portfolio corporate standards include not only estimates of the typical process, activity, resource, and assignment parameters but also project templates.  Risks are converted into “scheduling fragments” with a list of mitigation and/or action plan activities. 

Probability of each risk estimated initially for each project with historical data taking into the account.   

This library of schedule templates is not just used for risk identification but also allows schedulers to develop schedules for new projects much quicker.

Risk analysis methods

Existing challenges in project risk simulation addressed by high-technology systems.

Project risks and uncertainties usually managed to determine:

  • Project risks that require maximum attention
  • Achievable project targets with sufficient probabilities
  • Contingency reserves to meet the project targets
  • Current probabilities of meeting these targets
  • Resources required for the reliable achievement of project targets
  • Project activities that require maximum attention

Project risk optimisation systems need to support: 

  • Activity ranging (to manage uncertainties);
  • Advanced resource assignments;
  • Schedule and risks integration;
  • Risk evaluation methods;
  • Schedule optimisation methods;

The common risk simulation method is the Monte Carlo technique that simulates project execution many times, each time with new, randomly selected initial data, based on the expected probability distributions. In my view, Monte Carlo analysis, as a good mathematical method. It gives a reliable result but has two disadvantages:

 

  • It is very sensitive to the quality of risk data;
  • Monte Carlo simulation has high accuracy but low precision if the number of iterations is not sufficiently large.

Alternative schedule risk analysis methods which are less sensitive to the quality of risk data and size of schedule are more practical and are easier to use. I believe in the future we still could use MC method for some type of projects but mostly as an exception, not the rule.

 If you interesting more in Risk Analysis Challenges, there is very good presentation to read:

Risk Analysis Challenges

Training

Spider project has fully functional demo version with some limitation on a number of tasks. This version is free and is used by many education providers and not just to show the tool’s functionality but, what is more important, how to apply advanced risk methods and techniques correctly.

Spider Project Demo

Processes

The Next-Gen risk management systems are also going to change portfolio and project management processes.

 

  • A project prioritisation process is going to be build based on organisational bottlenecks (resources, skills, processes), not just based on strategic themes and available funds.
  • Integration of different type of projects (Waterfall, Agile & Hybrid) in a single dynamic model allows includes portfolio level risks into the analyse.
  • Ability to present information from different points of views will change project analysis process.

Scheduling Role

Presenters in the podcast have also discussed whether a scheduling role will be redundant soon and how new technology could change schedulers role and responsibility.

We actually could look into the future!!! The data standardisation helps to simplify schedule development & maintenance processes. Organisations that have already implemented advanced systems in project risk management have reduced a number of schedulers but require highly analytical skills. Schedule optimisation algorithms offer the most optimal solutions to schedule analysts. Armed with such powerful systems, the analysts now play the role of “analytical centre” in the project portfolio. Their recommendations support portfolio managers with critical portfolio decisions.

Industry Standards

While many of us are expecting dramatic changes in Project Delivery in the near future, such changes are impossible without mentality shift. We are able to learn much more from the previously delivered projects but only if we start using structural project delivery approach. The good news is that we do not need to be pioneers anymore. We could learn from industries and countries which already adopted their project delivery to the new standards.

Spider Project is the most popular tool for Project Management Delivery in Construction and Oil & Gas industries in some European, Asian and South American countries. Corporate norms, volume-driven and risk-driven scheduling are absolute standards for companies in these industries now. Thousands of projects, from small renovation projects to Olympic Games portfolio applied corporate norms and risk-driven methods. This generates a lot of structural project management data, which is used for project analytics and helps to improve schedule optimisation algorithms even further.

Alex Lyaschenko

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

Schedule Quality vs Schedule Maturity

Schedule Quality vs Schedule Maturity

by | 2 Feb, 2021 | Blog

Very often project participants mix up project schedule maturity and schedule quality concepts. While these two aspects are interdependent, misunderstanding the difference is often causing conflicts between a project manager, a scheduler and a PMO team.

Target schedule maturity level defines:

  • Scheduling tools
  • Processes
  • Methods and
  • Techniques

for schedule development, maintenance, optimisation and reporting. It also helps to define skills and capacity requirements for schedule development and maintenance.

Schedule Quality is a set of metrics to measure the critical parameters of the scheduling model.

Project performance indicators used to measure project progress (EVM, Success Probability Trends, Schedule KPI, etc).

Schedule maturity defines:

  • Methods that are going to be used to measure project progress and performance
  • Tools that support these methods
  • Data points required for these methods
  • Minimum required quality thresholds of these, or related, data points

Schedule quality defines the reliability of performance indicators.

Let’s consider what may happen when schedule quality is measured without defined schedule maturity. Many of PMOs and master schedulers do understand that poor schedule quality leads to low project performance and they are keen to address this issue by implementing schedule quality assessment.

However, if the required schedule maturity level is not defined, they actually don’t know what to measure. Some would recommend to use DCMA 14-points schedule assessment to measure schedule quality, as it is a well-recognised approach.

Well, firstly, they are not able to explain how the standard defined to control CONTRACTORS schedules in DEFENCE industry in USA is actually applicable for their type of projects, industry and country.

DCMA Metric N4: Total number of activities with Finish to Start (FS) logic links >9

If some projects in a portfolio by nature should have more than 10% of SS, FF or SF type of dependencies the metric is not just incorrect, it is actually misleading. Projects with incorrect logic will be shown as green and project with correct logic shown as red.

Secondly, they are not aware that DCMA 14-points schedule assessment is not a schedule quality assessment. 3 out of 14 metrics measure project performance and not quality of a schedule.

Lastly, the required schedule maturity defines which of the schedule quality metrics are applicable.

In one of my engagements, I have seen how a master scheduler forced all schedulers to populate resources for each activity based on DCMA metrics N10 (all incomplete tasks should have resources assigned), even for vendor driven activities. The schedulers spent a lot of effort just to make sure that the metric is green. Also, some of these schedules had missing critical dependencies (as a result had incorrect critical path). However, Metric N1 (the number of activities with missing a predecessor, successor or both should not exceed 5%) shows that logic is “green” as missing dependencies haven’t exceeded 5% of activities.

  • In many cases schedule quality could be just controlled via a set of filters implemented in a scheduling tool and would not require any additional expensive tool. Schedule optimisation, in opposite, often could not be completed in just in Primavera or MS Project, without a schedule optimisation tool applied. (Link to tools post)
  • A project must have a fit-for-purpose schedule maturity level to achieve desired targets. A lower or higher than required level of the maturity would move away the focus from project delivery to some none critical project activities.

The target level of maturity defines what a “good quality” schedule actually means. Without such a definition schedule quality reviews are full of arguments and subjectivity.

Alex Lyaschenko

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

“B” for Bottlenecks

“B” for Bottlenecks

by | 15 Jan, 2021 | Blog

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