Six symptoms that program risk
has become an issue

If you are looking for a program recovery advisory firm in Australia — particularly for a government program that has stalled, a complex infrastructure program that has lost delivery discipline, or a transformation that has gone at risk — the symptoms below describe the pattern that almost always precedes the recovery conversation. They tend to appear months before a status report turns red, and naming them early is the difference between a managed recovery and an emergency one. The Enterprise System Health Check is the fastest way to test whether they are present in your program.

The purpose of this piece is to describe six symptoms that, in the programs and transformations I have been asked to look at, tend to appear well before a status report turns red, and to map each one to the eight capability domains of an organisation's operating system, and to show how three disciplines drawn from systems engineering can help a program establish a baseline and manage its progress from there. I describe the six as symptoms rather than causes because each can be present in a healthy program for a good reason, and none of them proves on its own that a program is in trouble. Arguably it is the combination, and the way the symptoms reinforce each other, that signals the risk has moved from something being managed to something that has become an issue.

It is worth conceding at the outset that several of these symptoms look like virtues. A collegiate team is usually easier to lead than an adversarial one, a methodology gives a program a common language, and a team that uses AI to speed up its analysis is probably doing what its executive asked it to do. This piece does not contend that any of those things are wrong. It contends that each becomes a symptom when it starts to displace something the program needs more, and that the displacement is difficult to see from inside because the program still looks organised, polite and busy.

The eight domains, and where this sits against method

The lens used to read the symptoms is the eight capability domains described in The Living Organisation: Technology, Governance, Structure, People, Process, Information Flow, Data, and Purpose and Objectives. A program is delivered through these domains and also depends on them, which is why a symptom that appears in one of them is rarely confined to it. For each symptom below I name the domains where it primarily sits and the domains it tends to spread into, and a summary table follows the sixth symptom.

I should also say where this sits against method. I describe myself as methodology agnostic, and I have worked with PRINCE2, PRINCE2 Agile, APMG Change Management, Prosci, PMI and PMBOK, and MSP. The symptoms below appear under each of them in my experience, which suggests that the choice of method is a less reliable predictor of program health than whether the program has a clear picture of its own condition and a way of managing it.

Why symptoms rather than status indicators

Status reporting on schedule, budget and scope is a lagging view. A program can report green on all three while the conditions that produce those numbers are already degrading, because the people who hold the information are managing the report as well as the program, and a report that has been green for six months is uncomfortable to turn amber. The symptoms below are conditions in how the program is run, which means they can often be observed in a steering committee, a corridor conversation or a set of documents, and usually earlier than they show up in a number.

1. Overly collegiate

Primary domains: People, Governance  ·  Spreads to: Structure

The meetings are cordial, nobody disagrees in the room, and the phrase that comes up most often is that everyone is aligned. Contested trade-offs are resolved in corridors, or deferred, or quietly absorbed by whichever function has the least capacity to push back. In a functionally designed organisation this is a rational response, because each executive is protecting a remit and politeness is the cheapest way to avoid a trade-off that someone will lose.

Mapped to the domains, this sits primarily in People, where the working norms reward agreement over challenge, and in Governance, where the forum that should resolve contested trade-offs is not doing so. It spreads into Structure, because a functional structure gives each executive a remit to protect and so a reason to avoid the trade-off. The disagreement has not been removed; it has moved to the delivery layer, where it surfaces later and at higher cost.

2. Absent sponsorship

Primary domains: Purpose and Objectives, Governance  ·  Spreads to: Structure, People

The sponsor exists on the organisation chart and on the program charter, and may attend every steering committee. The symptom is that decisions requiring authority across functions do not get made by the sponsor, either because the sponsor has too many other priorities, because the authority has never been practically delegated to anyone in the room, or because the sponsor treats the role as an approval point rather than a decision-making one.

Mapped to the domains, this sits primarily in Purpose and Objectives, since the sponsor is the person who holds the reason the program exists and applies it when trade-offs arise, and in Governance, since the decision rights sit with the sponsor. Where the sponsor is absent, decisions continue to be made but by people working from their own function's reading of the purpose, and the effect spreads into Structure and People as functions begin to compete. Programs under strain tend to generate a high volume of cross-functional questions, which means the cost of that gap rises at the point the program can least afford it.

3. Unclear roles and accountabilities

Primary domains: Structure, People  ·  Spreads to: Governance

Most programs have a responsibility matrix, and most of them are accurate on the day they were approved. The symptom is that when three people are asked independently who is accountable for a particular outcome, they give three different answers, or the same answer with different conditions attached. Accountability for outcomes that cross functions is often the least clear, since it belongs by design to nobody in a structure built around functions.

Mapped to the domains, this sits primarily in Structure, because accountability for outcomes that cross functions belongs by design to nobody in a structure built around functions, and in People, because each person is acting reasonably on a different picture of who owns what. Governance is affected wherever the decision rights are written down but not understood. Structure is also one of the domains that changes continuously, so a responsibility matrix recorded at approval can be out of date within months unless someone maintains it deliberately.

4. Overly focused on methodology instead of risk, decisions and financial control

Primary domains: Process, Governance  ·  Spreads to: Data

Being methodology agnostic, I do not think any of the major methods is the problem, and the symptom looks much the same whichever one a program has adopted. Compliance with the method has become the proxy for control. Artefacts are produced on time, gates are passed, templates are completed, and meanwhile the risk register has not been materially updated, decisions are made without being logged, and the forecast to complete has not been reconciled to the benefits the business case promised.

Mapped to the domains, this sits primarily in Process, where the method lives, and in Governance, where risk, decisions and financial control should be held together. Data is affected because the evidence for each of the three (the risk position, the decision log and the forecast) tends to be held in separate places and rarely reconciled. Governance in this sense is the holistic view of risk, decision quality and financial position taken together, and it is possible to have complete methodological compliance alongside a poor understanding of any of the three. The Process domain reports that the work is being done, which is useful, but it does not on its own show whether control is being exercised.

5. Outsourcing analysis to AI, and what it does to trust

Primary domains: Technology, People  ·  Spreads to: Information Flow

This symptom needs more care than the others, because the evidence base is still forming and because AI use is, in most contexts, entirely reasonable. The research I find most useful is a 2025 survey of 319 knowledge workers by researchers at Microsoft and Carnegie Mellon University, which reported that higher confidence in AI was associated with less critical thinking effort, while higher confidence in one's own ability was associated with more. It is a self-reported study of a particular group of workers at a particular time, so I would hold the finding lightly; it is, however, consistent with a concern raised in several places, which is that heavy reliance on a tool for analysis may reduce the effort people put into the reasoning itself.

What follows is my inference rather than a finding, and I draw it from published research and not from a client engagement. Mapped to the domains, the symptom sits primarily in Technology, where the tool was introduced, and in People, where the effect on reasoning and trust lands, and it spreads into Information Flow because analysis then moves between team members as outputs with less shared understanding attached. In a program team, analysis is an input to decisions and also the way colleagues come to trust each other, since a colleague who can explain why a conclusion holds, and what would change it, is demonstrably carrying part of the problem. When analysis is produced by a tool and passed along with light review, it is reasonable to assume that the team may lose the cognitive clarity needed to resolve a problem when the tool is wrong or the context changes, and that members may begin to doubt whether their colleagues have understood the work at all. Trust built on shared reasoning is difficult to rebuild once a team suspects the reasoning is not there. I have written separately about the capability dimension of this question in Skills fade in the age of AI.

6. Unmapped assumptions

Primary domains: Purpose and Objectives, Information Flow  ·  Spreads to: Data

Every business case rests on assumptions about vendor delivery dates, resourcing, dependencies on other programs, regulatory timing and the willingness of the business to adopt the change. The symptom is that these assumptions were never written down as assumptions, never given an owner, and never revisited, so that when one of them fails the program experiences it as a surprise and not as a risk that was being watched.

Mapped to the domains, this sits primarily in Purpose and Objectives, since every assumption stands underneath an outcome the program has promised, and in Information Flow, because assumptions are rarely communicated to the people who depend on them. Data is affected because nobody holds the evidence needed to test them. Unmapped assumptions are also the most difficult of the six to detect because their absence leaves no trace; there is no document that is late and no meeting that is tense. They tend to appear when someone traces a program outcome back to the purpose it was meant to serve and finds that a link depends on something nobody has tested.

The six symptoms across the eight domains

Laid side by side, the symptoms concentrate in Governance, Purpose and Objectives, Structure and People, with Information Flow, Data and Technology carrying the secondary effects. That pattern is the main reason a fix applied to one symptom in isolation, such as a new reporting template, a refreshed responsibility matrix or a change of method, tends to move the problem rather than resolve it.

Symptom	Primary domains	Spreads to
1. Overly collegiate	People, Governance	Structure
2. Absent sponsorship	Purpose and Objectives, Governance	Structure, People
3. Unclear roles and accountabilities	Structure, People	Governance
4. Methodology over risk, decisions and financial control	Process, Governance	Data
5. Analysis outsourced to AI	Technology, People	Information Flow
6. Unmapped assumptions	Purpose and Objectives, Information Flow	Data

What systems engineering inputs add: a baseline, and a way to manage from it

Mapping the symptoms to the domains shows where they sit, though it does not by itself say what to do about them. This is where three disciplines I take from systems engineering and apply at enterprise level add value, because each answers a different part of the same problem: where the program actually stands, whether what it is doing still serves its purpose, and what a change will do elsewhere. I use the names from The Living Organisation, and I am describing a method rather than claiming an engineering title.

Operating System Configuration: establishing the baseline

Derived from configuration management, this is the baseline picture of the operating system the program and the organisation actually have across the eight domains, as distinct from the one described in the business case, the charter and the organisation chart. Most of the symptoms above are, in part, the result of drift between those two pictures, and a program that has no baseline cannot tell whether it has drifted. The Enterprise System Health Check is the instrument I use to establish it: a two-day, perception-based screening across the eight domains that tells the sponsor where to look, with the Enterprise System Diagnostic available to test what is found. The baseline then needs to be maintained deliberately, since Purpose and Objectives, Structure and Process in particular keep changing while the program runs.

Enterprise Traceability: managing against the baseline

Derived from requirements traceability, this is the capacity to follow strategic intent through to the decisions, assumptions and activity that deliver it. Once a baseline exists, traceability is what lets a sponsor ask of any decision, investment or assumption whether it can still be explained by reference to the purpose of the program. It speaks directly to the symptoms in Purpose and Objectives and Governance: the sponsor's decisions, the decision log, the risk position and the assumptions register become links in one chain and not four separate documents.

Capability Interaction Design: managing change from the baseline

Derived from interface control, this is the practice of understanding and shaping how the domains behave when they interact, so that the flow-on effects of a change are designed rather than discovered. Programs under strain tend to introduce changes quickly, whether a new reporting regime, a restructure of accountabilities or a new analytical tool, and each one alters how several domains interact. Asking in advance where the effect of a change will land is the most direct protection against fixing one symptom and creating another.

Using the three for future progress

The three are interdependent, and the value of using them together is that progress can be judged against something. A baseline taken at the outset, and refreshed at gates or at intervals the sponsor chooses, shows whether the domains are converging or drifting; traceability shows whether the decisions taken in between still serve the purpose; and interaction design reduces the surprises that would otherwise push the program off course. The six tests below then work as leading indicators that can be put to the program each time the baseline is refreshed, in whichever methodology the program happens to be running.

Six questions to put to your own program

Two or three of these answered uncomfortably would not, on their own, justify alarm. Four or more would suggest, as far as I can judge from the outside, that the risk is no longer being managed through the usual channels, and that an independent read of the program is likely to be cheaper now than at the next gate review.

The six symptoms above are not a comprehensive list and they are not a diagnosis, but they are the ones I would look for first. If the program on your desk is showing several of them together, is the more useful question whether anyone currently has the authority, the independence and the whole-of-program view needed to establish a baseline across the eight domains and manage the program against it?