Projects are very rarely conducted within a vacuum. Strong dependency management is often the key to successfully managing complex programmes. However, this can often be overlooked; being difficult to formulate and agree in the absence of reliable plans, or found to be too restrictive, acting as a straitjacket preventing the sensible movement of milestones and design scope.

Before we continue, let’s look at the definition of an inter-project dependency:

A formally agreed arrangement between two projects that is fully scoped and given a delivery date where Project A will deliver the agreed, to Project B so that Project B can continue work and complete their deliverables. Project B is therefore ‘dependent’ on Project A.

It is not difficult to see how this process can fall down. Within traditional waterfall environments, outlining ‘fully scoped’ and ‘formally agreed’ constraints around a dated agreement can be difficult as one moves further down the timeline. In today’s Agile world, it can be argued that documenting requirements further out than the next few sprints is either not truly agile or not strictly possible, not to mention the inevitable confusion caused when one side of the dependency is employing Agile and the other a waterfall approach.

So what’s the answer? Well let’s take a step back and re-evaluate what we are trying to achieve; ensure a programme or project is fully interlocked and chronologically aligned so any variance in forecast completion of tasks and any associated impacts are fully transparent across the organisation.

Fig.1 Dependency Formality Scale

P2 Consulting has been employing a more agile way of managing dependencies, allowing for a less defined scope and definition providing the wiggle room required in modern project management.

Rather than thinking of the vehicle for programme and project interlock solely as a fully constrained, scoped and formally agreed dependency from one project on another, think of it as a sliding scale of formality of inter project relationship. The current formal dependency process is absolutely part of this and sits at the very top of the Dependency Formality Scale, with inter relationships becoming less formal and less constrained lower down the scale. Relationships lower on the scale would for example, consist of Project B simply needing to know Project A had completed a task or a process had been put in place, potentially affecting how they do their work moving forward – in effect, a much more informal dependency

This model is implemented in the first instance, by breaking the Dependency Formality Scale into levels relevant to the programme or project, with governance around each level set for clarity. The product owners and project managers then agree common points of interest within their schedules and assign a level to each of them depending on its required formality.

If your programme has a lack of agreed dependencies or is experiencing a feeling of being stifled or overly constrained as part of its dependency process you may want to consider this method.

The next stage would be to agree an ‘owner’ or ‘donor’ of the common relationship, similar to the current dependency process. These would have responsibility over the finish date of the common activity. Finally, a date when the activity will be finished should be agreed by all. From experience, this process acts as a valuable alignment exercise in itself, with projects generally gaining a much better understanding of their colleagues’ schedules. These common task points, their levels, donors and dates should be captured and documented.

The benefits of this in an Agile world are clear to see. The flexibility over formality of relationship allows Agile practitioners to gain some understanding of where they should be in the future, without being constrained to a formal agreement, allowing sprints to be planned accordingly. Traditionalists also have the ability to know exactly where they will be at a point in time with the tighter, higher level of formality.

In a live environment the register of the inter-project relationships can be held within the PMO and once the common points are embedded and adequately highlighted within all the project and workstream plans, they can be reported against as part of a normal milestone reporting process. The donor would supply their forecast finish date and any variances can be highlighted and disseminated throughout the programme or project creating a fully cohesive, transparent and interlocked plan that is reportable and monitorable.

If your programme has a lack of agreed dependencies or is experiencing a feeling of being stifled or overly constrained as part of its dependency process you may want to consider this method.

For further information please email steve.clark@p2consulting.com or call +44 (0) 20 7099 0803.