When complex
engineering programmes
become harder than
they should be.
Markus Hager
More and more effort is needed to make the many contributions fit together. Friction increases, and confidence falls that the programme as a whole is on track.
I work with the people involved to understand what is making the programme unnecessarily difficult. At the points that matter most, we change how the distributed work comes together so the programme can move forward more reliably and with less unnecessary effort.
A lot is getting done. And yet bringing the whole thing together is becoming harder.
The difficulty rarely shows up as one clearly defined problem. More often, it takes the form of recurring situations that create additional coordination, rework and repeated clarification.
“Integration keeps revealing new problems.”
Each test exposes further dependencies, interface problems or necessary changes. The remaining work grows even though many individual tasks have long been considered complete.
“The status looks good, but we do not quite trust it.”
Reported progress and the judgement of experienced people do not fully align. There is a sense that important uncertainties will only become visible later.
“Decisions remain open or keep coming back.”
What seemed settled has to be discussed again because effects on other areas only become visible later, or responsibilities across boundaries were never fully clarified.
“Our key people hardly get to their real work anymore.”
Experienced people spend more and more of their time on coordination, problem solving and escalation. The very people who are most needed elsewhere increasingly find themselves personally holding the programme together.
When situations like these begin to accumulate, a technical and organisational problem increasingly becomes a business problem: time, budget and scarce expertise are absorbed by rework, coordination and late corrections.
What matters is whether distributed work comes together into a functioning system.
In complex programmes, the overall result depends on many distributed contributions. Good work in individual areas is not enough if those contributions do not reliably come together into a functioning overall system.
What happens between these areas matters just as much. How they work together across boundaries helps determine whether the distributed work reliably comes together into a shared result.
When this interplay works, it becomes easier to move the programme forward reliably and to remain capable of responding as conditions change.
Organisation
Technical work, teams, management, ways of working
Suppliers and partners
Customers
Dependencies · interfaces · assumptions · decisions · responsibility
Delivers its intended value in the customer environment.
From a shared picture to targeted change.
I do not enter a programme with a fixed prescription. I work with the people involved to build a shared picture of what is actually happening, clarify what matters for continued success, identify targeted changes, and help put them into practice.
Understand the programme as a whole
We reconstruct how technical work, decisions and responsibilities actually interact, and where different perspectives, gaps or critical connections exist.
- Dependencies and interfaces
- Assumptions and differing assessments
- Actual progress and maturity
- Responsibility and decision-making
Work out what really matters
Not every difficulty deserves the same attention. Together, we distinguish symptoms from the issues that are actually shaping what happens next.
- What needs to be clarified now?
- Which uncertainty should we test earlier?
- Where would a change make the greatest difference?
Change what will make a difference
From that picture, we develop and test changes that fit the actual conditions of the programme.
This might mean clarifying responsibility at a critical interface, deliberately integrating earlier, or changing decision-making and ways of working where they are holding the wider programme back.
The point is not to introduce another layer of process. It is to make the programme work better where it matters.
Help the programme move forward more reliably.
The programme remains complex. But it should require less additional coordination, rework and personal compensation simply to keep functioning. It should also be better able to respond when new requirements, uncertainties or changes emerge.
A more dependable shared picture
Programme leadership and the teams involved can see more clearly what has actually been achieved, what remains open and where uncertainty still exists.
More opportunity to act early
Critical questions become visible while there is still time to change priorities, test something or intervene deliberately.
Less need to hold everything together personally
Problems and decisions can more often be handled where the relevant knowledge and responsibility sit, rather than repeatedly converging on a small number of key people.
That leaves more attention for the work that actually moves the programme forward, and less for constantly compensating for friction between its parts.
Experience from responsibility for integration and interoperability in complex programmes.
I connect technical, organisational and business perspectives. I pay particular attention to the places where different parts of a programme come together, but are easily considered separately in day-to-day work. As an external consultant, I can look at those questions with some distance without losing sight of the practical realities of engineering.
For many years, I was responsible for integration and interoperability in complex medical technology programmes. My role was at the point where technical systems, teams, suppliers, customers and organisational decisions had to come together into a functioning whole.
I saw how quickly programmes come under pressure when progress in individual areas is not sufficiently connected to the development of the overall system. Technical problems surface late, decisions do not have the expected effect across organisational boundaries, and a small number of key people end up absorbing more and more coordination and problem solving.
That experience still shapes how I look at programmes today. I am particularly interested in what happens between established responsibilities, where technical questions, organisational structures and business decisions meet.
When you have the sense that there is more going on.
You do not need to know yet why the programme has become more difficult or what should be changed. A conversation can be useful if, for example, you notice that:
- the interaction between teams, suppliers and technical areas is creating increasing amounts of additional effort
- reported progress and actual confidence in where things stand are drifting apart
- similar problems, decisions or escalations keep returning
The initial conversation
You tell me what you are seeing and where additional effort, uncertainty or friction keeps appearing in the programme. Together, we look at the picture that emerges and whether an external perspective could help.
An initial description of the situation is enough.
Discuss your programme
Or write directly: markus@insidecomplexity.today