2014 Aurecon recruitment banner


How does programme management differ from project management?

In late 2012, Aurecon held a leadership workshop at its Gauteng office in South Africa where colleagues from across the business took time to discuss critical issues, developments and trends in Programme and Project Management.

The objective of this roundtable was to capture global, regional and industry specific insights and experiences which would form the basis of a suite of thinking papers. Over the coming months, we will publish various papers resulting from these discussions.

You can read the first paper "Delivering programme excellence" here.

In this, our second thinking paper focussing on programme management, we discuss the differences between programme and project management and what is required to deliver programmes effectively at the highest level.

How does programme management differ from project management and what skills are specifically required to manage a programme well?

Graeme McKenzie, Technical Director, Environmental & Advisory Services: It’s important to make the distinction between a project and a programme, as while the two are clearly interdependent, the management approach for each is very different. By my definition, a project requires a discreet effort, which is largely independent of other projects. This being the case, the outcome of the project should not have any major influence on subsequent efforts or activities, because a project has an end goal and will stand or fall based on the success of its delivery.

When you get into programme management, you are dealing with a large collection of interrelated projects that somehow have to work in a collaborative way to realise a positive and common outcome. You are also working in a much closer relationship with the client and the various stakeholders to the programme, so skills such as strategy definition, communications and stakeholder management become more critical.

So, with programme management, we’re looking at a much bigger picture. We are looking for trends and consequences arising from specific actions at the project level that may negatively or positively factor in the overall outcome of a larger programme.

Dennis Plockmeyer, (Previous) Technology Director, Coalition Provisional Authority Program Management Office, Iraq, Office of the Secretary of Defense, USA: To deliver a successful programme, managers and their teams need to understand the complexity and challenges they face. To do this successfully, I believe a critical challenge is to keep the programme manager focused and working at the appropriate management level.

Programme managers must not get lost trying to manage details at the project level. If this occurs, they lose sight of their programme objectives and become focused on the pieces of the larger process. This goes to the importance of standard operating and reporting procedures, good visibility of the programme baseline and progress, robust reporting and a clear understanding of programme objectives, so that people can understand what affect a slippage or cost overrun on a particular project will have on the programme itself.

By way of example, look at programme risk and cost management. You must look across the full programme if you have a cost overrun on a project, where are you going to make that cost up? If you have a schedule overrun, what are the ramifications? Are you going to experience a delay in subsequent projects because preliminary work wasn’t finished on time? This is why it is critical to keep the programme manager operating at the higher level, looking at the entire picture and not letting that person manage at a project level.

Does that person have to understand the metrics and the performances at a project level? Yes, because sooner or later if a project starts to look like it’s about to “jump the track”, we as the programme managers will need to step in, take some direct action to get that project back on course; either to drive teams to a solution, to realign the project with the preferred methodology, or actually implement a solution and force teams into something that they may not necessarily agree to.

Nova Vida, AngolaPieter De Wet, Service Leader, Programme Management: One of the fundamental differences, as far as project and programme managers are concerned, is that a project manager tends to be aware of everything that is happening on their project. However, within programme management, at the senior levels, it is management by exception. To effectively manage programme level relationships, as Dennis says, you don’t want the programme manager becoming too involved at a micro level, unless it is absolutely necessary.

Although projects normally deliver distinct and tangible outputs, programmes normally look at wider outcome driven goals and how to deliver and pull together the project benefits for the good of the overall programme. If the programme manager loses sight of this driver, the benefits may not be delivered or optimised.

Graeme: On a programme, you’re working more closely with the client. We touched on this earlier; it’s the close alignment with the client. The client is normally focused on a particular outcome and the programme management team needs to be fully aligned in order to achieve it.

John Mason, Global Programme and Project Leader: An example of this was the West Coast Route Modernisation in the UK. It was a very challenging programme and experienced significant change but was ultimately successful. However, the programme went through a lot of iterations and had to learn lessons the hard way.

The client was ultimately looking for a particular train performance level between London and Scotland but also wanted to maintain service levels during construction. To achieve these outcomes, a whole series of projects were proposed which had to be delivered in parallel, creating a series of complex interfaces which had to be managed. These included track access constraints and a shared supply chain, which meant that the individual projects couldn’t be delivered in isolation but had to be managed in a coordinated way.

Whereas, you could say, the Proof House Junction outside Birmingham New Street (one of the busiest railway stations in the UK), was a discreet project in itself, it had significant impacts on the adjacent railway and the train paths through the region, so had to be planned in conjunction with other projects. So as you can see the dynamics are very different at a programme level to a project level – even though they are interrelated.

Danie Wium, Former Industry Leader, Government: In South Africa, one of the major programmes we’ve been involved with over the last ten years has seen the government spending about between 10 and 15 billion Rand per year on municipal infrastructure. This equated to around three to four thousand projects per year, with the ultimate goal of improving service delivery within towns.

What we find is that just to deliver a service at a particular level, there’s a consultant doing planning, a contractor building it and then probably someone taking it to fruition and operating it. So the linkages between the different projects within a programme, as well as their different phases, can be critically important.

By way of example within the South African market you cannot deliver water at the local level unless you have bulk supplies. If someone is going to design a dam and water treatment works, you need to design all of the associated reticulation works. So while all these are different individual projects, they are all inexorably linked to one another and together they govern the success or failure of the overall programme.

To achieve successful programme outcomes, there is an absolute need for integrated whole of life management systems, as well as proper coordination between the planning, design and construction phases. This must take place between different disciplines, or sectors, types of projects and throughout the life cycle which, at the end, creates high quality service delivery outcomes. So it’s integrated planning, integrated monitoring and critical elements all coming together under the umbrella of a programme.

John: I totally agree. The independencies between projects are much more significant at a programme level, just by virtue of the complexity and shape of the delivery environment. Two examples of how the shape of the delivery environment can impact on a programme are Crossrail and London 2012.

Crossrail in the UK is a major new railway under London and it’s essentially a linear job which touches on existing infrastructure throughout its length, including civil, rail systems, electrical, mechanical and power related infrastructure. It also has to interface with existing operators and bring together a myriad of different interrelated elements, including rolling stock, to create a joined up, fully functional and safe railway. In these cases the number of “external” interfaces and stakeholders can be huge.

If you look at “campus” type programmes, such as London 2012, or say the Terminal 5 programme at Heathrow Airport, the delivery environment is even more acute, because here everything is effectively delivered within a highly constrained site, so has to be highly coordinated with the impacts of one project on another being more significant.

For both types of programme the supply chain is likely to be large and diverse.

Pieter: ... and in both cases operational service normally has to continue while you’re trying to deliver both the projects and the programme.

Graeme: That’s a critical point. Clearly with projects you get operational interfaces but again, at a programme level, because of the magnitude, you are more likely to come across a larger number of these operational interfaces and often they are interrelated.

John: I can think of three programmes in the UK, on the West Coast Route Modernisation, on the London Underground Upgrades and the Jubilee Line where the ability to deliver the programme and the constituent projects were heavily influenced by the operational environment.

Pieter: These drivers can seriously affect the programme delivery strategy. On the Heathrow Terminal 5 programme, you had one of the busiest airports in the world and one of the projects they had to deliver was a new air traffic control tower. The team planned for a very long time to deliver this part of the programme without causing any impact to operational service levels and the subsequent timing of the works had major implications for other interrelated projects.

This illustrates how critical it is to consider the operational environment within which the programme will take place, the constraints that this environment will have on delivering the programme and the effect that the programme will have on that operational environment.

John: We’ve already talked about the impact of multiple stakeholders, but programmes are usually much more visible than projects and the challenges more significant because they are often undertaken within the public realm.

Novorail, AustraliaDennis: For me, an obvious example of this is the Iraq re-construction programme that I was involved with. This was a large dollar, very politically attuned programme with objectives from both the United States and Iraqi Governments. There was a push to make things happen quickly and a programme scope that that was greater than the amount of the money available.

This programme highlights the need to have a professional approach to communications to ensure you deliver messages and provide relevant and accurate reporting. Data integrity is another critical issue when you’re reporting up into the political hierarchy, such as to Secretary of the Army or Secretary of Defence, on how you’re executing your programme. It’s critical to make sure that the information you’re reporting week to week is consistent and accurate. The last thing you want is have to explain to someone at that level that your data was flawed and you actually started fewer projects than you thought you started.

In this case, a lot of people who weren’t directly involved in delivering the programme struggled to understand why it was so hard to physically get from “point A to point B”. However, on the ground, this may have been because of narrow roads, no roads, security issues, checkpoints, lack of fuel, the things that impact the outcomes that you expected but aren’t visible on a reporting screen. These are factors that you never thought would be major impacts, major influences on the outcome of the programme.

The other thing we ran into was that while our programme and sub programmes were very large, the benefit of interdependencies between projects may not have been there, but they all served to reach a common goal. For example, finding a way to increase the total electricity available for the national grid. If you have 16 power plants and one is four times as big as all of the other plants, from a programme perspective, you would obviously want to get the biggest plant you have online in the quickest time.

However, the bigger the plant, the longer it was going to take to get there because the technology was different to what we had previously known or maintained. We had people asking, “Why are we spending all this money in this location?” Typically, you’re executing a programme based on a specific direction and this sometimes gets “lost in the mix” because the people authorising the programme don’t always do an effective job of conveying to the public what the objectives of the programme actually are.

Graeme: In terms of operational or service interfaces, looking at health or correctional services, the outcome or objective is often to increase the number of beds or something of that nature. You can’t go into an operational facility necessarily and extend, refurbish or build new facilities without having to decant existing operational wings. Often those patients or inmates will end up being relocated to another facility altogether which requires activity there. So there’s definitely significant operational interfacing required to ensure successful outcomes.

Danie: I think that the operation interface, especially why you’re actually changing existing facilities, can be quite a challenge at times. It’s critical to get this right.

Pieter: To me, project solutions are generally quite obvious. There maybe one or two routes you can take towards the solution. But at the outset programmes often have vague solutions and myriad ways of getting to them. It’s the problem and solutions statements that are the issue. On a project, you generally know what the problem is and everybody’s usually agreed on trying to find the appropriate solution. So discussions tend to be around the solution itself.

With a programme, the situation can be such that even the problem and solutions statement may be viewed differently by different stakeholders. Therefore, if you can’t agree on the actual problem that you’re trying to solve, you can imagine how complex the programme environment can become. We find that the stakeholder groups may have different views of what the actual problem is and what we are attempting to remedy.

John: Exactly. If you look at Crossrail, in essence this is a programme to deliver a new railway across London. Actually the programme objectives are far broader than that. Crossrail is about providing a level of rail service, which is the fundamental programme driver, but it is also about improving the quality of life for people around the new railway in the East End of London and leaving a human legacy as well as a physical asset.

So the drivers were as much around social engagement, about the benefits that the scheme would bring, about urban renewal, as well as creating apprenticeships, delivering training and leaving a supply chain legacy. These attributes and social issues often become much more significant at a programme level.

Pieter: These are the kind of things you do not necessarily find in a single project and “change”, often within the programme environment itself, can be a very complex issue to address.

The benefits the programme will deliver are also important to define. This isn’t always straightforward either. Although the programme might be in a specific location, there could be significant political drivers that aim to make sure that people who are relatively remote from the scheme itself are seen to derive some benefits from the programme’s delivery.

Danie: I think what’s important is to look at the philosophy and culture of the programme. Sometimes, we focus on the technical side and the need to integrate all the various stakeholders. But the actual physical benefits that emanate from a particular programme might not be followed through to their ultimate conclusion.

I believe we have to strengthen engagement with all of the economic, political and social drivers around programmes and the people that actually facilitate this engagement, be they government or the private sector. It’s actually about extending the programme’s scope far beyond just the physical thing that is actually being constructed.

Graeme: This leads to a requirement for a higher level of flexibility within a programme. Sometimes the hard and fast elements such as the engineering may be relatively easy to define. However, the social or soft issues which will impact upon the programme don’t always become so obvious until you’re well into the programme, so a programme management team needs flexibility to be able to react to these issues and respond appropriately.

John: I think this goes to Aurecon’s real strengths. Our ability to work in integrated teams with the client and other supply chain partners, to understand the dynamics around programmes, such as environmental and social community impacts and our ability to bring a whole of life perspective to delivery strategy whatever stage the programme is at, from programme definition through planning, design, delivery, operations and maintenance.

In the end programme management is about addressing all these issues to achieve tangible benefits and a common outcome, often using skills that blend “art and science”. With a programme it’s just as much about human, social and change management issues as it is about delivering specific tangible infrastructure outcomes.

Unfortunately, you are using a web browser that Aurecon does not support.

Please change your browser to one of the options below to improve your experience.

Supported browsers:

To top