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

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

Project Dependencies Types

Project Dependencies Types

by | 25 Nov, 2020 | Blog

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 analysis. 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

Agile & Waterfall Integration. Vendors

Agile & Waterfall Integration. Vendors

by | 14 Oct, 2020 | Blog

Some companies complain that vendors don’t support them with “Agile way” of delivery.

The reality is that many companies are only able to engage vendors on a fixed price (FP) type of contract. However, the companies are expecting the vendors to work in a Time & Materials (T&M) style instead. This is riskier for the vendors and, if they agree with this type of approach at all, they would have to compensate this risk by increasing their price for service.

Volume of Work (VoW) type of contact could be a good solution to this challenge. (Link to website)

If your Agile project delivery teams don’t have required skillsets and you need to engage a vendor to feel in the gaps, find out if your company policy permits (and your vendor accepts) T&M type of contract. If not, you may need to consider alternative options. One of the options could be a Volume of Work (VoW) type of contract.

For Volume of Work:

  • Identify missing critical skillset to deliver defined user stories;  
  • Estimate the required level of vendor support (in story points) based on current priorities;

The sum of Story points could then be considered as volume of work and converted into effort (and duration) based on the productivity rate of a resource assigned to deliver tasks.

Productivity Rate = Story points per resource per Sprint / Days in Sprint;

Cost of engagement = Story points  * Productivity Rate * Resource Daily Rate;

A vendor may be able to offer required skillset with different Productivity rate, Daily rate and Available capacity. If resources with different productivity available, the cost of the engagement should reflect that.

In this case, the Story points definition would have to include the productivity rate as well.

For example, if resource 1 is assigned, then the task is estimated at 5 story points. If resource 2 is assigned, then the task is estimated at 8 story points.

Another option could be to estimate story points based on the resource with the highest productivity, and then to adjust the velocity of each sprint when resource with lower productivity needs to be assigned.   

Cost of engagement = Story points (R1) * R1 productivity rate * R1 daily rate + Story points (R2) * R2 productivity rate * R2 daily rate;

This proposed VoW type of contract would allow to sign a Fixed Price contract based on planned volume of work (based on planned story points), but would support Agile delivery with periodic reprioritisations.

Vendors should be able to receive payments based on the completed volume of work (delivered story points) after each sprint or a number of sprints.

The contract may also include earlier exit conditions for a vendor, in case the project is put on hold.

As the risk in VoW contract is shared between a project and a vendor, the vendors would be ready to supply resources at a lower rate comparing to the Fixed Price Contract. 

Alex Lyaschenko

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