About Us

P2 Consulting was started by a group of award winning consultants who recognised the opportunity to build a global consultancy firm that had clients’ needs at its heart. We understand the challenges clients face – the pace of globalisation, technology change and increasing regulation – and the pressure they are under to respond to these changes rapidly and efficiently.

What We Do

We work on some of the largest transformation programmes in the corporate world and the public sector. Partnering closely with our clients, we help them deliver successful business change. Our reputation as a consultancy is built on excellence in portfolio and programme management, business architecture and design, testing and quality assurance and implementation.


Understanding the challenges that keep our clients awake at night is essential. In this section we demonstrate our expertise at solving your problems. We have deep insight into the business and technology issues facing all sectors.

Join Us

Are you looking to join a company where a challenge is welcomed, change is anticipated, and expertise is expected? Then have a look at our job listing and please get in touch.


Being able to see the obstacles facing your organisation is one thing. Being able to navigate those challenges and work through an effective solution is another.

Success Stories

We’ve worked with clients across a range of sectors and gained excellent results – but don’t just take our word for it. Have a browse through some of the work we’ve done.

Programme and Project Dependencies: Why so formal?

Steve Clark, Consultant in PMO and Portfolio Management, P2 Consulting


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.


P2 Consulting has a different approach to managing dependencies

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 [email protected] or call +44 (0) 20 7099 0803.




Get in touch

Click Here