Which projects deliver benefits?

Which projects deliver benefits?

Determining which project deliver benefits is not always a straightforward task due to the following factors:

Project-driven portfolios

Project-driven portfolios use projects to generate benefits by delivering products or services to their customers.

  • Non-mature portfolios only focus on managing project timelines and income generated, lacking knowledge about the project expenses. Unplanned project expenses affect revenue, making it difficult to assess the benefits.
  • Mature portfolios integrate benefits into project delivery plans and have a clear understanding of how delays/accelerations, income and expenses impact benefits. Not many project delivery systems support such integration.

Project-dependant portfolios

Project-dependent portfolios utilise projects to bring about desired changes that generate financial or non-financial benefits. While organisations recognise the importance of benefit management, accurately tracking these benefits can be challenging. Measuring benefits in such portfolios may require different methodologies.

  • The presence of multiple projects aiming to deliver similar benefits can complicate the assessment of individual outcomes. It can be difficult, or even impossible, to determine whether a specific project delivered the intended benefits.
  • Even when the desired outcomes are achieved, it does not guarantee that all projects delivered benefits as planned. Some projects might exceed expectations, while others may fall short.
  • To prevent double-counting, the organisational unit responsible for benefit management must exercise caution if different projects claim the same benefits.
  • Internal and external factors can influence the realisation of planned benefits, but measuring the impact is often challenging.

Alex Lyaschenko

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

Project Delivery Tool Ideas: WBS Review level

Project Delivery Tool Ideas: WBS Review level

Scheduling tools usually provide users with an opportunity to extend/collapse schedules to a certain WBS level. However, schedules usually have activities at different levels, and when a scheduler needs to update the schedule it is not possible to extend the schedule to the “WORKING” level.

In this example, activities are on levels 2, 3, 4 and 5, and to update them schedulers need to do many clicks. 

It will be convenient to have an opportunity to extend the schedule to the “working level”. Collapse  all WBSs with all completed activities and extend WBSs with ‘Not Started’ and ‘In Progress’ activities:

Another good option could be to extend only WBSs with “In Progress” activities but consider an activity be in progress based on planned (Start and Finish) dates, not % Complete:

If  (Start <= Status Date) and (Status <> “Completed”)  then  RealActivityStatus = “In progress”.

In some scheduling tools, it is possible to develop a filter and completely hide completed activities and WBSs. It is not convenient as:
– Users need to see ‘In Progress’ activities in the overall context;
– Be able to expand any WBS to review logic between activities;

Such WBS views save a lot of time for schedulers.

Alex Lyaschenko

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

Resource idle time and cost

Resource idle time and cost

For effective project delivery, control over idle time is critical but not easy. It requires appropriate methods, techniques and tools.

Projects may have a situation may arise when, for example, full-time (hired) specialists of the company or equipment go to the site, and for some reason, there is no scope for work for them to contribute to the main tasks. The reasons for this work disruption could be both objective (risks) and subjective (planning errors). As a result, the company incurs losses, since payment for working hours is mandatory, even if specialists or technicians do nothing through no fault of their own. It is almost impossible to quickly transfer specialists to other types of work as labourers or a complex team.

Resources with a rare skill (installation specialist) and equipment (mobile crane, drilling rig) are expensive but cannot be used for other work as they were hired for specific tasks.

It is essential to identify such scenarios, but it is not easy to simulate them in a schedule correctly. It is even more complex when resources are replaceable (3 bulldozers) and have different costs and productivities.

Activity assignment
If we assign these resources to the relevant activities, we can see the correct workload and can identify idle time. However, the cost of resources will not be calculated correctly as the project has to pay for these resources regardless of workload.

Hammack assignments
If, instead, we assign these resources to a Hammack (Level of effort) activity, we can see the correct cost of these resources but can’t identify idle time and cost.

Activity and Hammack assignment
As a workaround, it is possible to duplicate resources (with and without cost). Assign resources without cost to the activity and with cost to a hammock task. It solves overall project cost but doesn’t allow calculation cost of idle time.

Also, the cost of these activities and work packages will be incorrect.

Variable Activity and Hammack assignment
The ideal solution is to use a hammock task with variable assignments. Assign resources to relevant activities and automatically move idle resources to the hummock task.

Only advanced project delivery tools, like Spider Project, can simulate such scenarios correctly.


The project requires installation specialists for six activities. There are ten specialists with a rate of 100$ p/h each. What would be the idle time and cost for this skill?
The required quantity specified in resource assignment and workload is calculated:

Resources are also assigned to the “Idle Time” hummock task but the available quality is automatically calculated as the difference between all resources (10 installation specialists) and assigned (activities 1 – 6) resources!

Idle time and cost could be calculated in the hummock task or presented as a diagram.


  • This approach provides an opportunity to manage critical resources and calculate (resource, skill and overall project) idle time and cost, and understand the idle rates.
  • When project conditions (demand, supply, delays, etc.) are changed, resource assignments, cost and idle time could be recalculated with minimum effort.
  • This approach works for resources with different cost and productivity rates.
  • Advanced scheduling systems could calculate not only idle time and cost but could also recommend optimal assignments to minimise the required quantity (with start and end dates). Such optimisation minimises the duration of work and idle costs.

Advanced project delivery systems, like Spider Project, help to optimise critical resources to accelerate project delivery without compromising project cost and quality.

Alex Lyaschenko

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