The Diagnostic Method
Every enterprise IT project starts with a diagnosis. Most produce a document and then proceed as if the document were the diagnosis. It isn't. The document is a record of attention paid at one moment in time. Diagnosis is the attention itself — sustained until the problem is resolved or explicitly accepted as unresolved. Everything else is paperwork.
The confusion is not academic. It is the underlying mechanism by which transformations consume budgets without changing operational baselines, by which migrations promise replacement and deliver coexistence, by which audit cycles produce volumes of paper while the same risk recurs each quarter. In each case, an artefact has been mistaken for a practice. The artefact is filed. The practice was never present.
Real diagnosis is older than enterprise IT. It is the discipline practised in any field where stakes are high and confirmation matters — medicine, civil engineering, aviation safety, accident investigation. Different domains, identical structure. What enterprise IT has done, gradually and without anyone naming it, is replace each move of that discipline with a deliverable. The diagnostic method survived under other names; the practice itself receded.
What follows is the discipline, named in seven principles. They are not innovations. They are recovered fundamentals. Each can be tested. Each can be skipped. Each, when skipped, leaves the same trace: a document filed where understanding should have been.
1. Diagnosis is continuous, not episodic.
A diagnosis runs from problem-onset to resolution. It does not freeze at a kickoff and reappear at the next quarterly review. A diagnostic discipline that ends before the problem ends has stopped diagnosing.
The discovery phase of an enterprise IT project is not a diagnosis. It is the beginning of one. When the discovery phase produces a report and the project moves on, what has been built into the project is the assumption that the diagnosis is now complete. It is not complete. It will only complete when the problem itself is closed — and the problem closes by one of three doors: resolved, explicitly unresolved with reasons documented, or explicitly deferred with consequences known. Until one of those doors closes, the diagnosis is still in progress, regardless of what has been filed.
Anyone who has watched the same operational issue surface on three successive quarterly reviews has watched a diagnosis that ended too early. The discovery was filed. The understanding was not maintained. By the time the issue surfaces a fourth time, the team has changed, the report is unread, and the problem is treated as new. It was never new. It was always the same problem, awaiting the diagnosis that was supposed to be sustained.
2. Listen before you analyse.
The first move of a diagnosis is unstructured attention to the system in motion. Not interviews structured around a hypothesis. Not workshops scoped to a deliverable. Attention to what the system actually does, in the conditions where it actually fails, with the people who actually run it.
Most diagnostic failures are listening failures, not analytical failures. The data was already there. Operators had reported it. Logs had recorded it. The pattern had been visible for months. What was absent was someone willing to listen to the system before deciding what the system was.
An analysis that begins before the listening is complete will always confirm the analyst's prior beliefs. There is no method by which structured questioning recovers what unstructured attention would have surfaced first. The order matters, and it cannot be reversed without cost. The cost is recorded later as scope creep, missed requirements, or — most often — a rebuild eighteen months after the original go-live, when the system finally reveals what it was always doing and nobody had stopped to notice.
3. Elementary checks before sophisticated ones.
The electrician verifies the bulb. The sailor taps the hull. The pilot walks the airframe before reaching for the avionics. Architectural review reached for before the power supply has been checked is professional malpractice in any other discipline; in enterprise IT it is treated as seniority.
Sophistication arrives at the wrong moment for a reason. Elementary checks are uncomfortable because they implicate someone — usually someone present in the room — for not having performed them already. Architectural review is comfortable because it implicates everyone and no one. The room reaches for the comfortable instrument. The system continues to fail for the elementary reason.
A diagnosis that opens with sophistication is almost always avoidance — not of the problem, but of the conversation about why the elementary check was never made. The discipline requires that the elementary check come first, regardless of whose negligence it surfaces. Without that requirement, sophistication becomes a permanent shelter from accountability.
4. Test the stated problem.
The problem-as-stated is rarely the problem-as-experienced. The first technical move of a diagnosis is to verify the framing before accepting it.
A request to "modernise the legacy platform" is a stated problem. The experienced problem may be that the legacy platform is the only system the operations team fully understands, and the failure modes of any modern replacement are unknown to the people who will be paged at 3 AM when it breaks. The stated problem and the experienced problem are not the same problem. Solving the stated problem leaves the experienced problem in place, often in a worse form. The team that understood the failure modes is now paged for a system whose failure modes nobody understands yet.
Diagnosis treats the initial framing as a hypothesis, not a brief. It is examined, tested against the system's actual behaviour, and either confirmed, narrowed, or replaced. Skipping that step delivers solutions to problems that were never the real problem. The original failure persists, dressed in new vocabulary, and the project is signed off anyway.
5. Documentation is not understanding.
A document about a system and an understanding of a system are different things. The discipline recognises the difference and refuses to substitute one for the other.
Most enterprise architecture artefacts ratify decisions; they do not capture diagnosis. The diagram shows what was approved. The runbook shows what was promised. The configuration management database shows what was inventoried. None of those artefacts answers the diagnostic question: what does this system actually do under load, at the boundary, in the failure modes that have not yet occurred but are structurally possible.
A practical test separates document from understanding. Ask the document a question only the system can answer — a question about behaviour at the edge, not behaviour at the centre. If the document is silent, or generic, or contradicted by the system's actual logs, the document was a record of attention paid once. The understanding was never written down because it was never present. What was filed was paperwork. What was needed was a person who had stayed in contact with the system long enough to know.
6. A diagnoser is named and accountable.
Diagnosis attaches to a person, or to a small team, who can be questioned six months later. Anonymous diagnosis is not diagnosis. "The system says..." is not diagnosis. "The vendor confirmed..." is not diagnosis. Diagnosis is held by someone who can be wrong — and therefore can also be right.
The discipline of medicine learned this centuries ago. A diagnosis is signed. The signing physician carries the consequences if it is wrong. The signing is not ceremonial; it is the mechanism by which the diagnosis becomes accountable to the patient, to peers, and to the field. Without that mechanism, what remains is opinion, and opinion does not improve over time because nobody owns its errors.
Enterprise IT replaced this with anonymity. A statement of work is signed by procurement and by a vendor's commercial entity. A discovery report is authored by "the consulting team". An architectural decision record names the meeting, not the person who concluded. Each of these constructions is a sophisticated way of ensuring that no individual can be held responsible if the diagnosis is wrong. Which means it cannot be improved. Which means the same wrong diagnosis is delivered, by different teams, to different clients, year after year — because no one ever paid the cost of being the person who got it wrong.
7. Diagnosis has a defined exit condition.
The discipline ends when one of three doors closes: the problem is resolved; the problem is explicitly accepted as unresolved with reasons recorded and consequences known; the problem is explicitly deferred with a defined revisit date. Anything else is open-ended paperwork.
Most enterprise diagnoses end through a fourth door, which the discipline does not recognise: the budget runs out, the contract closes, the consultancy rotates off, the executive sponsor moves on. The problem is not resolved. It is not explicitly accepted. It is not deferred. It simply stops being looked at. The artefacts are filed and the diagnosis is treated as complete because the engagement is complete. These are not the same event.
A discipline that exits through the fourth door has not concluded a diagnosis; it has abandoned one. The problem will recur. The next team will be told it is a new problem. They will conduct a new discovery, produce a new report, and exit through the same fourth door. The cycle is not a failure of any individual project. It is the structural consequence of letting the engagement define the exit condition instead of the problem itself.
The Substitutions
These seven principles are not innovations. They were the fundamentals of any rigorous diagnostic practice — medical, mechanical, navigational, investigative — long before enterprise IT existed. What enterprise IT did, slowly and without anyone naming it, was replace each of them with a deliverable.
Continuous attention became a discovery phase.
Listening became a stakeholder interview.
Elementary checks became a high-level assessment.
Problem-testing became a scoping document.
Understanding became a folder of architecture artefacts.
Accountability became a vendor's signature on a statement of work.
Exit conditions became the end of the engagement.
Each substitution was small. Each one looked like progress. None of them were called what they were: the quiet replacement of a practice with its paperwork.
DiagnosticMind exists because the discipline still works wherever it is restored. Not as nostalgia for an older era. Not as critique of any individual practitioner. As a method that can be named, taught, and held to account — recovered from a profession that mislaid it under twenty years of deliverables.
The discipline begins when someone is willing to call paperwork by its name and pay attention to the system instead.