≡ Menu

Managing across a Portfolio of Projects & Programs

If you have a number of projects running, with potentially some linkages between them and with some sharing of resources – even if, for example, the shared resource is only limited funding, the interactions between the projects and their resources leads to management control complexities which can result in undependable deadline performance.

Managing across dependencies simultaneousy.

For high levels of management control across a portfolio of projects or programs, the factors below need to be brought into the equation.

The big challenge is, that those factors need to be considered simultaneously.

For each of those factors…

Task dependencies within projects – is conceptually the easy bit and will be familiar to all project managers.

It’s the identification of those tasks which really are reliant upon the completion (usually) of an earlier task (usually!) before they can begin. Yes, there are variants on that sequential ‘Finish-to-Start’ theme. Those variants include: Start-to-Start, Finish-to-Finish and so on. Although this is the easiest part, many project plans are longer than necessary because sequential dependencies between tasks have been assumed, whereas in reality, tasks can often be concurrent.

Task dependencies between projects – where activities in one project are dependent, in the same way as above, but upon tasks in a separate project. Which means, that slippage in one project can cause delays in other projects where they are awaiting completion of that task. On the subject of slippage, we should bring in the wider subject of variability in the times it can take to complete a task.

Resource dependencies between projects – is where it starts getting challenging for many organisations.

This is where some type of resource is needed across more than one project (or task) at the same time… and there ain’t enough of that resource to ‘go round’.

Effectively managing this situation entails… firstly foreseeing it, secondly, prioritising the use of that resource. If you have unlimited resources, you won’t need to prioritise their use.

However, in the real world where resources within a given time period are often limited, prioritisation of resources is an important mechanism but by no means the only one.  And then thirdly, sequencing and synchronising the tasks and projects around how that shared/scarce resource is actually going to be used, leads on to…

Resource Availability & Allocation – another aspect of resource dependencies. It involves monitoring the current and planned commitments of a resource, and making decisions on how best to allocate it according to criteria such as… what your organisation is trying to achieve.

Resource Constraints and Overloads – it may already have struck you; resource constraints, which could also be called bottlenecks, are created rather than god-given.

They are created as direct consequences of our objectives. That is, we decide we want to achieve a certain aim. We then realise we will need certain resources to achieve that aim.

If we had no aims; we would need no resources. As soon as we have aims to achieve in finite time scales, we start to encounter resource limitations… that’s unless we’re lucky enough to be well resourced, or have very modest aims!

If we want close control over project delivery dependability, then we need to foresee those resource constraints and plan with them in mind. Foreseeing the overloading of a resource, is foreseeing that the current plan is unrealistic. An overloaded resource is the signal that at least one of the projects trying to use that resource is in trouble!

Rework Elimination/Defect Avoidance – why is this here? This subject is not usually mentioned in project or program management discussions. But it is closely linked to resource dependencies, to resource constraints and to the unnecessary consumption of resources.

For example, if you are running projects and you need to make use of a key resource that is regarded as in limited or constrained supply, the last thing you would want is for that constrained resource to be burning-up time in working on putting some other job right (rework) because defects have arisen which now need to be corrected.

Rework – that is, correcting a piece of work in order to make it satisfactory – wastes resources, which reduces productivity and causes disruptive delays. It is also surprisingly common.

In business processes within multinational corporations, I have measured the losses to productivity caused by rework as greater than 50%. That is, 50% of the productive resources are lost to rework activities. For management control of project delivery reliability, rework elimination is a very powerful mechanism.

{ 0 comments… add one }

Leave a Comment