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