Systems Integration Done Right

Successfully navigating large infrastructure programme complexity is essential to the delivery of targeted outcomes. Devising and guiding how to navigate complexity comprise the core capabilities of systems integration. Getting that process right depends on an array of factors, including a well-considered strategy and shared vision, clear requirements and end-goals understood by all, organisational stability, engagement with end-users, and sound decision-making.

In the following Q&A, Scott Meadows, Technical Director, WSP in the United Kingdom, looks at actions that can lead a programme into trouble; he also explores how effective systems integration guides efforts to achieve the end goals of rail and other infrastructure programmes.

What is the power of systems integration done right?

Scott Meadows: Delivering any major infrastructure programme is a complex business that requires a well-considered systems integration strategy. Strategy should focus clear actions on crucial problems that connect operations to aims¹ supporting and driving the journey to attain the end goals, on time and within budget. Sounds simple, but this is hard to achieve, as clear actions are rooted in interconnected systems of activities.

Systems Integration should look at each programme as an integrated whole, linking together the elements by understanding the relationships between people, processes and ideas.

Of course, this necessity makes those 36 easy steps seem so appealing.

What 36 easy steps?

Scott Meadows: When typing into a search engine is your programme in trouble, hits are likely to give you the following: specific key indicators to check for, provision of a specific health status in the form of a coloured rating— Red, Amber, Green—on a dashboard to help identify how much trouble your programme is in, and after diagnosis prescribe remedies to cure your programme ills in, say, 36 easy steps, using a stage gate programme management method where progress is controlled by achieving a milestone or stage before proceeding to the next phase. Sounds logical, doesn’t it? But there is significant evidence to suggest that too often these steps do not create the most effective path to deliver a complex programme.

An effective systems integration strategy requires a diagnosis, a guiding policy and coherent action. Systems integration can identify troubles with your ‘in-flight’ programme if you have not already applied SI from the beginning—which is of course the best scenario; it can determine what needs to be measured and what doesn’t and prescribe effective actions to move forward. However, these are not simple rules to abide by; there is no specific set of rules for a programme as each programme is different and choices will vary. Systems integration requires making strong choices and also helps to shape those choices. Inevitably, choices may lead to ‘winners’ and ‘losers’ within the programme—as entrenched ideas are challenged, new ideas and processes are adopted.

We must also recognise that placing rigid technical analysis within a changing political environment is problematic. Solving programme problems is just hard and made even harder by governmental, organisational and people-centred issues, which are unique to each programme.

Can you expand upon people-centred issues?

Scott Meadows: Systems integration requires technical analysis, but it also requires an environment that encourages people to think differently to solve problems.

The delivery culture has evolved over time to dictate that the worst thing you can do is admit that you have a problem you cannot handle. So, it becomes a technical problem, as responsibility and accountability for technical problems lies elsewhere. As programmes get into more trouble, the number of technical problems increases, but still you don’t have a problem; manual workarounds or interventions provide operational solutions to technical problems.

However, operational solutions are delivered by people, so your problem just got much bigger; more people are involved and need aligning to solve your problem.

Except, as it is now a technical problem with operational solutions, you are convinced there is no real problem for you to solve. It’s not your problem.

As you don’t have a problem, only technical problems that need operational solutions, it is highly likely that you and everyone on your team have transitioned into fire-fighting mode. This is comforting but addictive and extremely risky, as everyone is likely to be ploughing on with operational solutions, at, say, 767 miles per hour.

In the rush to find operational solutions to technical problems, no one is thinking about the best way to coordinate activity to achieve programme outcomes and solve real problems; no one is challenging technical problems and operational solutions to see if they are correct—as something needs to be done in the programme and the need for action is now.

What happens next?

Scott Meadows: If no one is thinking about how best to define and solve a problem, the top-level strategic view that provides integrated coordination over the programme can be lost, as are the programme’s chances of meaningful success. This can lead to programme cost overruns, late delivery and shortfalls in benefits realisation.

Get the article in PDF

Scott Meadows

Technical Director

United Kingdom

Contact

Related themes and tags

How do programme controls play into this scenario?

Scott Meadows: As no one is thinking and just getting on with operational solutions, programme reporting starts to interfere with people’s ingenuity. Rather than using their ingenuity to think about the real problems, people are now focusing on how best to report ‘green’ on programme dashboards—how to say the right thing or find the right targets to report against—at the expense of solving real problems.

Often, uncertainty cannot be gauged by a three-colour rating system² —uncertainty remains uncertain. Still, in this scenario, programme leaders continue to believe they can quantify uncertainty, which is difficult with uncertain complexity and nigh on impossible relative to Goodhart’s Law³, which states that when a measure becomes a target, it ceases to be a good measure. In other words, in an environment where people are governed by a system of rewards and punishments, they will usually optimise their actions within the given system to achieve their desired results rather than try to manage uncertainty.

What then is the best way to deal with uncertainty within a systems integration context?

Scott Meadows: Programme leaders cannot plan for every eventuality. Plans themselves need to be adaptable, and people need to be flexible, open to tradeoffs.

This is why a systems integration strategy should not be based on the concept of perfection of planning, which supposes a sequence of events that allows programme actors to move with confidence from one state to another. Systems Integration strategy demonstrates its value when a shift in plans is required; this shift can jeopardise programme outcomes and increase costs as interested parties with conflicting concerns slip into a fight for control of the programme. Perfection of planning is a symptom of system decay; when the belief that once our plans are perfect, we cannot fail infects a group, that group will begin to fail.

Organisations need to empower and support their people as much as possible to manage shifts and solve the problems a programme faces against delivering strategic targets.

In addition to being adaptable, can you identify other key points that shape a successful SI process?

Scott Meadows: It is critical to manage stakeholders well, commit to flexible contractor management, and manage the interaction of these areas to create a clear benefit for each party, which drives the programme forward—with an understanding that degrees of uncertainty will exist throughout the programme.

Can you elaborate upon these areas?

Scott Meadows: Major projects require a coalition of delivery partners with the support of external stakeholders. Risk increases if stakeholders or problems are ignored, and conflicts then brew under the programme surface. Conflicts can cause agreements to fail, where partners no longer collaborate to achieve goals but instead work against one another. Forums need to encourage people to be open and transparent so conflicts can be aired and resolved.

Due to the size of major programmes, multiple parties are required to bring specialist expertise. In competitive tendering, often this expertise is awarded to the lowest bidder. This, however, brings a further complication as contractors are forced by the system to bid aggressively and then work inflexibly, asking for compensation with every project variation. By having a clear understanding of the requirements of the programme, systems integration can help inform the competitive tendering process, linking supplier incentives to contractual agreements that support integrated and collaborative working.

What are your parting thoughts regarding the impact of systems integration on future decision-making?

Scott Meadows: To bring true value to programmes, it is important to translate the understanding explored here into broad policies for programme governance that allow the focus to be on solving the hard problems, to concentrate ingenuity on those hard problems rather than expending time and energy on the noise, which like acceleration is addictive. Such policies would also allow the choices that emerge to be articulated to everyone, clearly, even though they may not be universally popular.

Ideally, policies should give talent the latitude to apply their ingenuity to shape clear, coherent actions, focusing on what is critical so that the aims can be linked directly to delivery and all of the major problems that arise can be resolved on the journey to success. Getting and staying on the right journey always comes down to people, and people need an environment that is conducive to making the best decisions.

To continue this conversation and learn about the WSP systems integration approach—SI:D3—contact Scott Meadows at [email protected].

¹ Richard P. Rumelt, Good Strategy Bad Strategy: The Difference and Why It Matters (Crown Business, 2011)
² RAG (Red, Amber, Green) ratings are used for status reporting to indicate project performance
³ Charles Goodhart, Problems of Monetary Management: The UK experience (In Courakis, A, S. (ed). Inflation, Depression and Economic Policy in the West, 1981)