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