Project-Portfolio Management Snails

Project-Portfolio Management Snails

Project-Portfolio Snail

A typical Project Portfolio environment echoes the “fractal” form of the common garden snail’s shell.

A small organisation may only have ad-hoc projects managed independently, and a large corporation portfolio of projects is subdivided into “sub-portfolios “, each of which is managed as a portfolio in its own right. The same applies to program and project levels.

A definition of each fractal level is required for effective communication, but applied definitions are soft and vary between organisations and government bodies. The boundaries between levels are arbitrary and determined individually as well.

Two organizations carrying out similar projects may have significant differences between levels (or even the presence of levels), but the overall nesting from large to small is constant: groups of projects always consist of many interrelated tasks performed by project resources. What would fall under the definition of a project in one organization may be a program or even a portfolio in another.

Also, companies may use different delivery methods or even develop their terminology but the ‘fractally increasing’ principle applies.

Also, companies may use different delivery methods or even develop their terminology but the ‘fractally increasing’ principle applies.

The current establishment of a project management discipline relies solely on experiential records and opinions rather than a sound logical or theoretical foundation. Ideally, there is a need for a universally accepted and testable set of fundamental principles in project management. These principles would serve as a common reference point for a set of ‘generally acceptable practices,’ aiming to facilitate the creation of successful products. ‘Project-Portfolio Snail’ is one such principle.

A program-centric portfolio has many types of ‘snails’ that look the same but are not. It is challenging to mature such a portfolio as project people in the same portfolio don’t speak the same language. 

Even within a project, the language barrier may not be recognised. Project people move between organisations and even industries, and it is usually assumed that team members can easily speak the same PM language. They can’t, and they don’t understand that they can’t!

It is easy to recognise a gap for a new term. However, when a common project management term, like ‘stream’, has a slightly different meaning, it is incorrectly assumed that the whole team applies the term in the same way.

It is better to assume that a project team don’t have a common language. It opens an opportunity for PMOs to develop custom-made training where project management terminology is clarified and made mandatory for project stakeholders, from a project coordinator to an executive team, to attend.

Alex Lyaschenko

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

Artificial Activity Split Problem. Resource Levelling Challenge

Artificial Activity Split Problem. Resource Levelling Challenge

In previous discussions, we explored the benefits of employing Volume Lag and Point-to-Point dependencies for emulating activities that shift in parallel. However, due to the limited support for these features in many planning tools, some planners have suggested the utilisation of artificial activity splits as an alternative. It enables the application of Finish-to-Start dependencies without introducing lags between parallel activities. While this workaround resolves one issue, it potentially creates others.

Artificial Activity Split may cause two planning problems:

  1. Splitting of activities that must be performed without interruption into separate segments can end in undesired results after resource levelling.
  2. If parallel activities have duration uncertainties, Artificial Activity Split makes the result of the Monte Carlo Simulation unreliable.

Resource levelling Challenge

Let’s review a scheduling fragment with six activities. All dependencies are Finish-to-Start.

Activities A and B have a volume of 80 units (10 units per day). Activity B can run in parallel with activity A after 40 units are achieved. There are different ways to simulate such a scenario. Ideally, if a planning tool supports ‘volume scheduling’ and ‘point-to-point dependencies’, multiple point-to-point dependencies could be applied:

Start-Start (40v, 0v) and Start-Start (80v, 40v).

If a planning tool only supports duration lags, it could be simulated with two dependencies:

  • Start-Start + Lag (4d) and Finish-to-Finish + Lag 4 days. Technically it takes 15 days to deliver the work package.
  • This fragment requires the same ‘Resource 1’ for Activities A and D for the same days (Day 3-5). So, if there is only one ‘Resource 1’, resource levelling is required.

With limited resources, it takes 20 days to deliver the work package.

Now let’s review the same example but with Artificial Activity Split applied.

Activities A and B are split into two 4-days activities. It allows the application of Finish-to-Start dependencies without lags. Technologically activities (A1 and A2), (B1 and B2) must be performed without interruption. Due to the resource constraint (same as above), resource levelling is required.

A good levelling algorithm can find an opportunity to perform activity D ahead of activity A2 and deliver the fragment in 18 days instead of 20 days! This schedule meets all the specified planning conditions, but practically it is not feasible since activities A and B must be carried out without interruptions.

Splitting activities that must be performed without interruptions into separate segments is not a good idea as it can lead to undesirable results when resources are limited and resource levelling is required.

The second challenge associated with Monte Carlo Simulation we will review in a separate post.

Alex Lyaschenko

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

Indirect Resource Dependency

Indirect Resource Dependency

In the previous posts, we reviewed Volume Lags and Point-to-Point dependencies to demonstrate that assigned resources may impact activity and lag durations. This is also an excellent example to demonstrate indirect resource dependencies.

We reviewed a scheduling fragment with two activities and one dependency. It is easy to imagine real examples when activity A performs preparation for activity B and must be continuously ahead with defined Volume: 20m, 10m3, 10 items, etc.

Technologically, without considering resource requirements, this example looks SIMPLE. Resource assignments add dimensions to the complexity of planning and execution of this fragment. 

Practically to be able to complete this work, it is essential to know:

Demand
• Volume of Work (We know that already: both activities are 100m)
• Technical dependency constraints (We know that already: SS + lag & FF + lag)
• Volume lag (We know that already: 40m)
• Required skills (equipment, people)
• Required materials (if any)
Technological resource constraints: minimum & maximum quantity, minimum % workload, teams, shifts, etc.
• Space constraints (if any)
• Activity Calendar constraints (if any)

Supply
• Resource quantity limits
• Resource Productivity Rates (For each skill)
• Resource Calendar Constraints
• Cost components (If cost has a high priority in planning this work)

Resource Dependencies
• Direct resource dependencies
• Indirect resource dependencies

These parameters and correlations between them are relatively easy to understand, document and add to the project delivery model. Of cause, if the project delivery tool allows that. All except Resource Dependencies. Direct Dependencies add a new layer of complexity, indirect another one. Let’s review how.

Scenario 1: (Without Resource Dependency)
• Activities A & B require the same skill S1
• Resources (R1) with skill S1 have productivity of 2.5 m/h
Two identical resources are available
• Each activity requires a minimum of one resource
• Maximum one resource could be assigned to each activity
• Activities & Resources have 5d*8h calendar

Work takes 7 days, and there is no opportunity to accelerate delivery.

Scenario 2 (Direct Resource Dependency)
The same as above, except:
• Only one resource is available

Work takes 10 days, and there is no opportunity to accelerate delivery.

Scenario 3 (Indirect Resource Dependency)
Activity A
• Activities A requires skill S1
• Activity A requires a minimum of one resource
• Maximum one resource could be assigned
• Two resources with skill S1 have productivity of 2.5m/h (R1) and 5m/h (R2)

Activity B
• Activities B requires skill S2
• Activity A requires a minimum of one resource
• Maximum two resources could be assigned
• All resources with skill S2 have same productivity of 2.5m/h (R3)

• Activities & Resources have 5d*8h calendar

Scenario 3a
Resource R1 and one resource R3 are assigned to activities A & B.

Work takes 7 days, the same as in scenario 1. Is it an opportunity to accelerate delivery now?

Scenario 3b
Resource R2 is twice more productive as resource R1. Let’s replace them!

While the duration of activity ‘A’ is reduced to 2.5 days, the overall duration is reduced by 1 day only. This is due to the reduced duration of the SS lag. Refer to Volume Lag post for details.

Scenario 3c
The previous scenario doesn’t give us the expected result. Let’s add additional resource to activity ‘B’ instead.

While the duration of activity ‘B’ is reduced from 5 to 2.5 days, the overall duration of work hasn’t changed. It is still 7 days. This is due to the required FF lag between activities.

Scenario 3d
The additinal resoucre assigned to activity B also doesn’t give us the expected result. What if we combine scenarios 3b and 3c: replace R1 with R2 and add additional R3 resource?

It gives acceleration bigger than two scenarios applied separately (one day in scenario 3b and zero days in scenario 3c)! Appling together, the duration of work reduces to 3.5 days!

Yes! 1+0=3.5

Project planning is more complex than simple math. 

Visible Resource Dependencies

These scenarios demonstrate that technological resource requirements and supply constraints impact the schedule in several ways:
• R1 & R2 resources have the same skills with different productivity rates. It impacts the duration of activity A (scenario 3b).
• R3 resources have the same productivity rate. Activity B can be performed with a different quantity of R3 resources, It impacts the duration of Activity B (scenario 3c).
• The resource constraint (scenario 2) doesn’t impact the activity durations but creates additional Resource Dependency.

There are all visible dependencies that are relatively easy to identify and analyse. Relatively, as we only analysed the impact of two activities without the context of the overall project. If analysed resources are required to perform other activities at the same time when this work is planned, it may trigger further changes.

Hidden Resource Dependencies
In scenario 3d we identified indirect dependency. There is no visible dependency between Resources R1/R2 and R3. These resources have different skills and are assigned to different activities.
However, work was significantly accelerated only when the correlation between these resources was identified. These resources are dependent indirectly.

Project acceleration
Resources may have direct and indirect dependencies with other resources in the project in many other ways. A small change in one assignment may trigger a ‘domino’ effect and cause significant delay. This is one of the main reasons why projects are late.

However, the effect works in both ways! The project may have an acceleration opportunity through direct and indirect resouce dependencies, but it is not easy to identify them manually. Applying a project delivery tool with advanced scheduling methods and good resource levelling algorithms could significantly accelerate project delivery and reduce project cost.

Alex Lyaschenko

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

Point-to-Point Dependency

Point-to-Point Dependency

In the Previous Post, we discuss the advantages of volume lag.

For example, when activity A performs preparation for activity B and: 20m, 10m3, 10 items, etc.

The proposed solution was to use: Start-to-Start + Volume lag.

The ‘Volume lag’ eliminates the problem when activity B can’t commence on time due to lower than expected progress of activity A. However, there is one more challenge: activity B not only has to start when the required volume is achieved, but also this Volume must be continuously achieved ahead of activity B.

As a quick fix, both activities may have an additional Finish-To-Finish + Volume lag dependency:

It guarantees that the completion of Activity B is ahead of Activity A but doesn’t fix the problem. If the progress of Activity A may not be stable project delivery model must reflect it. The proper solution is to apply multiple Point-to-Point Dependencies to implement additional checks.

A ‘Lag’ is a shift from the Start (or Finish) date of the Predecessor activity.

Point-to-Point dependency represents shifts from a predecessor point AND a successor point simultaneously.

Each P2P dependency has two lags: Lag Out (traditional) and Lag In:

Where:
• Lag 1 – predecessor lag
• Lag 2 – successor lag
• Both lags could be Duration or Volume based
• Volume could be defined in units or as Volume %

Alex Lyaschenko

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

Volume lags

Volume lags

At times, there may be two project activities that have the potential to be carried out simultaneously, but the second activity can only begin after a certain delay following the initiation of the first activity. The minimum required delay is usually defined by the technological process.

Traditionally, such delays are represented in a schedule using Start-to-Start plus Duration Lag (SS + Lag) logic.

However, this approach has a significant planning issue. If activity ‘A’ has started but is not progressing as expected, the schedule incorrectly indicates that activity ‘B’ can start as planned, when in reality it cannot. 

The delay could be due to external factors or lower than expected progress.

Activity ‘B’ only can start after the planned volume of work is achieved, which is in 3 working days.

An alternative approach is to use VOLUME as the primary measure of activity and calculate the duration based on the productivity of assigned resources. This method offers several advantages, including the accurate simulation of activity lag duration.

Task A:

  • Volume: 100 meters
  • Resource productivity: 20 meters per day
  • Duration: 5 days

Task B:

  • Volume: 100 meters
  • Resource productivity: 20 meters per day
  • Duration: 5 days

In this case, lag is defined as the minimum required volume between activities based on the planned or actual progress of the predecessor activity.

Lag

  • Volume: 40 meters
  • Duration: 2 days

If the first activity has started but has not reached the planned volume, the start of the second activity will be automatically rescheduled.

Furthermore, if a resource with a different productivity rate is assigned to the work, the scheduling system should recognise that both the activity duration and lag duration differ from the original plan.

Task A
• Volume = 100 meters
• Resource Productivity = 40 meters per day
• Duration = 2.5 days
• Lag = 40m
• Lag Duration = 1 days

When using Duration Lags in scheduling, there is a significant risk that the overall duration will not be accurately calculated. This is because the planner must remember that the lag duration depends on the assigned resource and manually make adjustments every time there is a change in the assignment.

Volume lag can be beneficial for various scenarios, not just for (SS + lag) dependencies. For example, it can also be used for (FF + lag) dependencies.

 

Also, Volume Lag is applicable to Negative Lags (Leads).

Volume lag could be measured in volume units or as % of overall volume.

Not all activity lags can be measured in terms of volume. There are situations where lags are directly defined by duration. However, when a technological process specifies a lag based on volume, but the schedule represents the lag using duration as the primary measure, it becomes difficult to simulate the schedule scenario accurately.

By incorporating volume lag, it becomes possible to calculate the duration of the lag correctly, and it can also be dynamically adjusted based on resource assignment and activity progress.

Alex Lyaschenko

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