In late 2012, Aurecon held a leadership workshop at its Gauteng office in South Africa where colleagues from across our business took time to discuss critical issues, developments and trends in Programme and Project Management.
The objective of our 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 continue to publish various papers arising from these discussions. You can read the first paper "Delivering programme excellence" and the second paper, “How does programme management differ from project management?”
Pieter De Wet, Service Leader, Programme Management: There’s one critical aspect here for me and it’s the different level of exposure that we have when it comes to managing a programme versus a project. Programme risk can be immense and the impacts can be highly visible and so significant that they can quickly move the programme into very challenging political, stakeholder or technical territory, especially if you’re looking at large undertakings in the resource, transport or major public infrastructure sectors.
If something goes awry, such as a serious project level incident involving members of the workforce or the public, we could have to address disruptions to delivery and operations across the whole programme with large cost, schedule and commercial impacts through a “domino” or “ripple” effect. Risk exposure on a programme is one of the key elements we need to manage very closely and remain focused on throughout the life of the programme, along with health and safety, as these things go hand in hand.
Dennis Plockmeyer, (Previous) Technology Director, Coalition Provisional Authority Program Management Office, Iraq, Office of the Secretary of Defense, USA: Understanding the ripple effect is a real challenge. For example, the consequences of a variation from baseline in one schedule and how it ripples through to the next. A dashboard that shows a project is “fast” or “slow” may not truly reflect the magnitude of the problem because the effect nearly always ripples outward.
If it’s a cost overrun, what are you going to cut out of the next project to stay within budget? Or if you have a delay in one project, how many other projects are going to be delayed? Then there are the ways proposed to accommodate these issues. For example you can delay work on the associated projects but the downside here is, that if you do delay these project, you’re going to have to pay for stand-downs while people wait to re-engage and then ramp up costs when the projects restart.
I think we’re back to the art and science of programme management. The art is to be able to take a step back and to look at the whole picture and understand intuitively that if this project goes red, what else be impacted. It is critical to be able to identify where problem areas are occurring and the consequential effects across a myriad of related and less obviously related areas. There is a critical need to watch the whole programme and controls plays a major part in being able to do this, but there is also a danger of the dashboard providing too great a focus on one particular discreet point on a discreet project. So all in all it’s really tough from a metrics perspective.
John Mason, Expertise Leader, Programme & Project Management: Where programmes get into difficulties, it can often be attributed to the client and the programme management team losing sight of the programme’s ultimate objectives, roles and responsibilities and the programme baseline. Unless you have a common understanding of what the programme objectives are, who is responsible for what and when and what the baseline is in terms of scope, requirements, schedule, budget and risk, it’s very, very difficult to measure and manage change and to get the programme back on track.
When you face the myriad of challenges that always come up, be they technical changes, variations to scope and delivery related impacts in all forms, you need to have confidence that your baseline is solid because then you can manage change against this and know that you are still driving towards the programme’s ultimate objectives. With clear roles, responsibilities and interfaces you can then also ensure that actions required will be carried out effectively.
So for me, the challenge a lot of programmes face is that they lose sight of their objectives, who is responsible for what and what the baseline for the programme is.
The answer to all these is to take a step back. Be brave enough to look and say, right this is where we’re at, where are the issues and how can we fix them? So baseline definition and maintenance for me would be a critical challenge.
Danie Wium: Former Industry Leader, Government: John, I reflect on a programme I was involved in a couple of years ago and the key question there was why are some of our clients not spending the money that they have allocated?
They had their budgets but were not spending it. When I looked at the types of projects where there were issues, I realised that they had no planning, no design experience and only construction projects on their books. This said to me that if you don’t plan, you can’t design and if you don’t design, you can’t build.
If you just look at it from a baseline perspective, you may be at 90 per cent spend, as 90 per cent of the money is for construction and 10 per cent is for design. However, a lack of spending on design will have a dramatic impact on the years’ hence, when it comes to associated construction spending.
This brings to the table the issue of leading indicators and prioritising those indicators that really must be tracked. These don’t always reside within the lifespan of the programme and may continue well after the programme is completed. For example, a simulation extending beyond the current baseline could allow you to track where you are going to be say five years into operations and maintenance. For me, there is a real need to constantly sharpen the sophistication of the tools used to track and predict performance on a programme and its whole of life impacts, not only during delivery but also afterwards during operation.
John: This is an important point, if you look at what the operation of the asset will look like after the programme is completed, you can better define what you’re trying to achieve through the programme by working back from that point through delivery and into planning. While working on the High Speed Railway Line in the UK, we undertook the works in a largely sequential manner, focusing first on the civil engineering aspects, then the railway systems and finally the operations. This gave focus but also led to some challenging interface issues.
What’s happened over the past ten to 15 years is that, particularly in the transport business in the UK, everything has been completely turned on its head once the initial programme has been defined. Now when determining delivery strategy, programme requirements and baseline scope/schedule/budget, programme management teams look at the operation of the asset and how the programme infrastructure is going to work and be maintained. Then as part of an iterative scheduling process they look at the construction programme, procurement packaging and the timing and packaging of detailed design.
Graeme McKenzie, Technical Director, Environmental & Advisory Services: In terms of the lack of clarity on the information flows that exist within a programme, we've previously talked about dashboards and the importance of this tool. When a dashboard is done well and when the appropriate planning has gone into creating a good tool, dashboards provide clients and the programme management team as a whole, with key information that is required to make their critical decisions.
This information is such that it allows the team to take action, perhaps in relation to a problem, drawing upon trends or from a metric drawn from supporting data. Equally, it may allow a team to identify an opportunity that’s coming their way and act on that opportunity.
With a dashboard, what we’re trying to do is provide people with a tool which has to be used with a degree of judgement, so that the information enables them to act effectively. There is so much information out there in any programme, and all the projects that relate to that programme, and the difficulty decision makers have, is getting access to the information at the level that is appropriate to them.
By providing a dashboard, we’re filtering through the enormous amount of information and pulling out the bits that are important. Obviously there’s a lot of background work that goes into that to making sure that information is current, correct and clean, but once we get access to this information, it really provides a basis on which decision makers can act.
Pieter: The science and skill of this data management and interrogation allows you to take myriad information sources, distill them and then to present information in a way that’s accessible to clients and programme managers so that they can very quickly pick up on the data they need and make the appropriate decisions at the appropriate times.
Graeme: The desktop takes away the requirement for the client, or whoever the target audience is, to have an understanding of the backup systems needed to report this information. It provides information to them quickly and clearly so that they can make decisions. It’s a very valuable tool. I think this relates to what we said earlier about programme leaders needing to focus on the data they need and not having to examine project details that aren't relevant and may cloud the issue.
John: The maxim on most programmes is to keep life simple in terms of controls and reporting, simple data entry, simple reporting with access at the appropriate level. Programmes are complex undertakings and overlaying this with a complex controls and reporting environment can have a detrimental on programme performance. This isn't to say that the controls and reporting system doesn't have to been highly sophisticated, it almost certainly will be, it just needs to service those inputting the data and accessing it in a straight forward and meaningful way.
John Mason: John is Aurecon’s Leader, Programme and Project Delivery and has extensive experience in the planning, design, procurement, management and supervision of major infrastructure related programmes and projects across the world, for both the public and private sectors. John has specific skills in the area of organisational development and the delivery of complex infrastructure programmes and projects, with an understanding of the measures that need to be taken to achieve delivery objectives whatever they may be.
Danie Wium: Danie is an expert in municipal infrastructure planning and development. He provides thought leadership to local provincial and national government departments on critical infrastructure planning and development.
Graeme McKenzie: Graeme has significant experience delivering major health programmes and projects. He is currently part of the team delivering the USD 1.5 billion Queensland Children’s Hospital project in Brisbane, Australia.
Dennis Plockmeyer: Deputy Director for MELE Associates Biomass-to-Energy vertical delivering programme and project management services to large commercial clients fielding large biomass-to-energy plants. (Previous) Technology Director, Coalition Provisional Authority Program Management Office, Iraq, Office of the Secretary of Defense, USA and Chief Information/Technology Officer, Naval Facilities Engineering Command, US Navy.
Pieter de Wet: Pieter has been involved in project and programme management for the past 15 years in both South Africa and the United Kingdom, including contributions to the redrafting of the Office of Government Commerce’s (OGC) ‘Managing Successful Programmes’ manual in the United Kingdom.