Organizational Diagnosis: A Process for Planning Change
Learn how organizational diagnosis works: assess readiness, identify issues, and build a practical plan to guide successful organizational change.
Why do so many change efforts solve a problem the organization never had? The answer usually sits in the first week, when a leadership team accepts the problem it announced as the problem it has. Organizational diagnosis is the discipline of testing that assumption before money moves, and the people closest to the work tend to hold the evidence that answers it.
What Organizational Diagnosis Is and How It Differs From an Audit
Organizational diagnosis comes into view through four parts: a holistic pentagon model for reading the whole organization at once, a team-written toolkit with its listed steps and named models, the triggers that start the work, and the audit it is most often mistaken for.
Those parts pull against each other. A holistic reading resists committing to any one model early, a written toolkit leans on named models to stay repeatable, and the trigger that funds the work usually decides which pull prevails before anyone has looked at the evidence.
The Pentagon Model: Per Morten Schiefloe’s Holistic Alternative to Picking One Named Model
A holistic model such as the Pentagon Model reads several dimensions of an organization together, so the diagnostician avoids committing to one named framework before anyone understands the problem.
The catch is that choosing a framework early is itself a diagnostic decision, usually made without evidence. Every named model carries a theory about where trouble lives. A model built around strategy and structure will surface strategy and structure problems; a model built around leadership and climate will surface those instead. The practitioner who opens with one model has already decided which kind of evidence counts, and a problem rooted somewhere the model does not look will register as noise.
A holistic approach responds by keeping formal structure, culture, working relationships, and the technology and tasks people handle in view at the same time, and by treating the interplay between them as the main object of study. When a team misses deadlines, the holistic reading asks whether the reporting line, the informal norms about raising bad news, the relationship between two leads, and the tooling they share each play a part, and how those parts reinforce each other. Single-model diagnoses tend to name one cause; holistic ones tend to name a loop.
The price of that breadth is focus. A diagnosis that looks everywhere can drift into description without a conclusion, and sponsors who wanted an answer in a few weeks receive a map of everything. The discipline that keeps a holistic reading useful is a sharp presenting question held constant while the lens stays wide, so the breadth serves one decision. Without that question, the holistic approach produces an accurate portrait that nobody can act on.
Inside the WMU Toolkit: Eleven Named Authors and a Faculty Supervisor
An organizational diagnosis toolkit written by a team and checked by a supervisor turns diagnosis from one consultant’s craft into a repeatable practice that others can run, review, and run again.
That codification creates its own risk. A written procedure invites mechanical use: the team runs the interview guide, fills the template, and produces a report shaped like every previous report, whether or not the organization in front of them fits the shape. The value of supervision in a toolkit setting lies in checking the judgement calls the procedure cannot make, such as which presenting problem to accept, which stakeholder group the sample is missing, and when the data has stopped supporting the working hypothesis.
A toolkit also makes diagnosis teachable. When the steps, instruments, and decision points are written down, a newer practitioner can see where judgement enters and where it should stay out, and a sponsor can see what they are paying for. Authorship by many hands tends to strip out any one person’s preferred model and leave the steps that hold up across cases, which is closer to what an iterative practice needs. The real test of a toolkit is whether a second team, running it on the same organization, would reach a recognisably similar picture.
What the Toolkit Document Actually Lists as Steps
A diagnostic sequence that holds up across cases runs through six moves: define the presenting problem and the outcome the sponsor wants; collect data from several levels and stakeholder groups; test rival explanations before accepting the first reported cause; compare perceptions with objective indicators such as turnover or cycle time; select interventions matched to the causes the evidence supports; and reassess after implementation, feeding the result into the next round. The evidence-based strand of the diagnosis literature argues for this kind of discipline, with the stated goals of bringing more scientific rigour to the diagnostic process, improving the appropriateness of interventions chosen for a given situation, and contributing to readiness-to-change among organizational members Organizational Diagnosis: An Evidence-based Approach (ResearchGate). The third and sixth moves are where most shortcuts happen.
Testing rival explanations carries the most weight because it protects the diagnosis from the sponsor’s first hypothesis. A sponsor who says morale is low because of the new performance system has offered one explanation; a diagnostic team that collects data only about the performance system will confirm it, since nothing else was measured. Teams that write down two or three rival explanations before fieldwork design their interview questions to discriminate between them, and their findings carry more weight with sceptics as a result. Reassessment matters for a different reason: without it, nobody learns whether the diagnosis was right, and the next diagnosis starts from the same untested assumptions.
Where Named Models Like 7S and Weisbord Fit In
Within a written toolkit, a named model does a clerical job: it fixes the category list the team files findings under, so two teams running the same procedure produce reports that can be compared line by line. Marvin Weisbord introduced his Six-Box Model in 1976, sorting organizational dysfunction across Purposes, Structure, Relationships, Rewards, Leadership, and Helpful Mechanisms Weisbord Six-Box Model (Think Insights). The Burke-Litwin model arranges 12 interdependent factors in a causal map and was first published in 1992 in the Journal of Management Burke-Litwin Model of Organizational Change Explained (Lemon Learning), while the congruence model created by David Nadler, Michael Tushman, and Charles O’Reilly organizes company data to determine the root cause of a business issue Understanding the Nadler-Tushman Congruence Model (Harvard Business School Online). The McKinsey 7S Model belongs to the same family of sorting frames.
For a toolkit, the practical question is when the model enters the procedure. Written in at the start, it makes every diagnosis the toolkit produces look alike, which helps comparison and hides any problem that falls outside its categories. Left open until the team understands the situation, it keeps the procedure flexible, but then the toolkit has to say who picks the model and on what evidence, or the choice reverts to whoever holds the most seniority. Either way, the useful habit is recording which model shaped the data collection, so readers of the findings know which questions were never asked; a report that omits that line cannot be checked by the second team the toolkit was written for.
What Triggers a Diagnosis: Presenting Problems vs. Routine Health Checks
Most diagnoses begin with a presenting problem, a symptom someone senior can name, while fewer begin as a routine check run before a planned change or on a fixed cycle.
The presenting problem is the reason the work gets funded and rarely the thing the work ends up fixing. Turnover in one department, a missed product launch, a slide in customer complaints: each arrives with an implied cause attached, and the person who names it usually has a stake in that cause being correct. Treating the presenting problem as the boundary of the diagnosis narrows data collection to the symptom’s immediate surroundings, which is where its cause is least likely to sit.
Pre-change diagnosis works from the opposite direction. Before a change programme begins, the useful assessment covers how much change the affected groups are already carrying, how aligned and ready the leaders are, what past change has taught people to expect, and where the organisation’s structures, systems, and culture will help or block the new way of working How to Diagnose for Change (The Change Compass). No single symptom drives that kind of check, so the scope stays broad, and the findings often surface the problem that the next presenting complaint would have pointed at months later.
The two triggers call for different contracts with the sponsor. A presenting-problem diagnosis needs explicit permission to follow the evidence away from the named symptom, agreed at the start, because a finding that the problem sits in the sponsor’s own function lands badly when it arrives as a surprise. A routine check needs a clear decision it will inform, or it becomes an annual ritual whose report nobody opens. A diagnosis that lacks either agreement tends to stall at exactly the point its findings become uncomfortable.
When Is an Audit the Better Choice?
An audit is the better choice when the question is whether the organization meets a known standard, such as a regulation, a policy, or a contractual control, and the answer must be comparable from one year to the next.
Organizational diagnosis is built for the opposite case. It is a structured, iterative process that gathers data on how an organization currently functions in order to pinpoint what drives a specific problem or opportunity, whereas an audit checks the organization once against a fixed standard and reports where it falls short. The two look alike from the outside, since both involve interviews, documents, and a written report, and that resemblance is where the expensive mistake starts. A leadership team commissions an audit while the question it actually carries is “why do we keep getting this result?” Executives tend to recognise this weakness in themselves: in a survey of C-suite executives, 85 percent agreed that their organizations were bad at problem diagnosis, and 87 percent said those mistakes carried significant costs Understanding the Nadler-Tushman Congruence Model (Harvard Business School Online).
The choice turns on what each instrument treats as fixed. An organizational audit holds the standard constant and measures the organization against it, which is exactly what a regulator, a board, or an insurer needs. A diagnosis holds the problem open and treats each round of data as a chance to reframe it, so the first interviews usually change the question the second round asks. That repeatability turns diagnosis into a consulting practice a team can run again on the next problem, instead of a one-off event that produces a binder. A quick test before commissioning either: if the sponsor can already name the standard the answer will be judged against, the work is an audit; if the sponsor can only name the result that keeps arriving, it calls for a diagnosis. Health assessments benchmark against a standard of their own, which is a third question with its own instrument.
Commissioning the audit when the question was diagnostic costs more than the fee: the gaps get closed, and the result keeps arriving because the pattern producing it was never in scope.
Why Organizational Diagnosis Is Collective Sensemaking, Not Just Data Collection
Organizational diagnosis works as collective sensemaking because its hardest problem is fragmented meaning: different groups interpret the same events differently, and the diagnosis has to work with that gap before additional data can tell anyone what to do next.
The awkward consequence is that more data can make things worse. When a staff survey and a round of leadership interviews return conflicting reads on the same problem, the instinct is to decide which account is accurate, or to average them into one score. Both moves throw away the most useful thing the diagnosis has found: evidence that two parts of the organization are living in different situations while sharing one org chart.
Fragmented Meaning vs. Missing Data: The Crosswalk’s Central Claim
Fragmented meaning describes a diagnosis where every group has plenty of information but each assembles it into a different story, so gathering more of the same information leaves the disagreement intact.
Missing data and fragmented meaning call for opposite responses. If the problem were missing data, a longer survey or a wider interview sample would close it. When the problem is fragmented meaning, a longer survey produces more numbers that each group reads through its existing story, and the gap widens as both sides find support for what they already believed.
The Millennium Teleservices case shows the pattern at full strength. By the fall of 1999, the company’s 113-person IS department had warring internal groups, 90 percent of staff threatening to leave, and flat revenues; the organizational psychologist brought in, Christine Truhe, assessed the situation by addressing the relationships between individuals and groups, and she describes unclear or competing authority figures as the central element in situations of this kind Corporate Angst (CIO). Each warring group had an account of what was wrong, and each account was coherent from inside. The diagnosis became useful once it stopped adjudicating between accounts and asked what arrangement of authority made all of them reasonable.
Averaging is the quiet version of the same mistake. Picture a team where half the respondents rate decision clarity at two out of five and half rate it at five: the mean of three and a half describes nobody on the team. The split itself says that one group knows how decisions get made and another does not, which is a far more specific finding than any average. Diagnoses that report distributions and disagreement by group keep that signal; diagnoses that report a single score discard it before anyone has looked.
Karl Weick’s Sensemaking: A Disputed Problem Is a Disagreement About What Is Happening
Sensemaking theory treats a disputed organizational problem as a disagreement about what is actually happening, which means the diagnosis cannot resolve it by measurement alone.
That view removes the comfortable idea of a single objective fact waiting to be captured. People act on their interpretation of events, and those interpretations feed back into the events themselves: a team that reads a reorganization as a demotion behaves in ways that make it one. A survey item asking whether communication from leadership is clear gets answered through whatever story each respondent already holds about leadership, so the item measures the stories as much as the communication.
In practice the sensemaking lens changes the questions a diagnostic team asks. Instead of asking how satisfied people are with cross-team coordination, the team asks them to describe the last time coordination failed, what they thought was happening at the time, and what they did next. The answers expose the interpretive frame directly. When a delivery team describes a missed handoff as product changing its mind again, and the product team describes the same event as engineering refusing to commit, the diagnosis has located the dispute precisely: two groups with incompatible accounts of who owns a decision.
The lens also changes what counts as resolution. A disputed problem is resolved when the groups involved can describe the situation in terms each recognises, even if they still disagree about remedies. Diagnoses that skip this step and move straight to recommendations tend to produce plans that one group experiences as an attack, and the resistance that follows is the unresolved dispute resurfacing under a new name.
Collective Sensemaking: Shared Orientation Without Forced Agreement
Collective sensemaking aims for enough shared orientation that people can act together, a lower and more reachable bar than getting every group to agree on one interpretation.
The bar matters because total agreement is rarely available and pursuing it stalls the work. Organizations contain groups with real differences in incentive, information, and history; a diagnosis that waits for those differences to dissolve will wait indefinitely. What groups can usually reach is agreement on a few things: what has happened, which facts are beyond dispute, and what the next experiment should test. That much is usually enough to start moving.
Shared orientation is built through the diagnostic process itself, which is why how people experience the diagnosis matters as much as what it finds. Employees who see their account reflected in the findings, and who see disagreement named honestly, tend to treat the diagnosis as theirs; employees who see their account averaged away or overruled tend to withdraw. Employee commitment appears to move with that experience, so a diagnosis perceived as fair can strengthen commitment to the organization while one perceived as a verdict handed down can erode it, whatever the accuracy of its findings.
The practical design move is to build reflection points into the diagnosis where groups see emerging findings and respond before anything is final. A two-hour session in which each function reads the draft picture and marks what it recognises, what it disputes, and what it thinks is missing does more for shared orientation than an extra survey wave. The cost is time and some loss of control over the narrative; the return is a set of findings that the people who must act on them have already started to own.
Complex Adaptive Systems: Reading Interaction Patterns Instead of Symptoms
A complex adaptive systems view shifts the diagnostic question from “what is wrong?” to “which interaction patterns keep reproducing the current situation?”, treating the organization as a system whose behaviour emerges from how its parts respond to each other.
The shift is uncomfortable for sponsors who want a culprit. In a complex adaptive system, nobody designed the outcome: it arises from many local decisions, each sensible from where its maker stood. Symptoms such as missed deadlines, attrition, or quality escapes sit at the surface of these patterns, and fixing a symptom without changing the pattern tends to move the problem somewhere else. Ron Carucci observes in Harvard Business Review that competent leaders misdiagnose organizational problems all the time, largely because recurring performance challenges run deeper than they initially appear 4 Organizational Design Issues That Most Leaders Misdiagnose (Harvard Business Review).
The CAS view keeps causation and relocates it. Instead of a single root cause, the diagnosis looks for feedback: a behaviour in one group that triggers a response in another, which in turn reinforces the first behaviour. These loops explain why problems survive leadership changes, restructures, and training programmes, since none of those interventions touch the loop itself.
Why CAS Treats the Organization as Emergent, Not Fixed
Emergent system behavior is behaviour that no single team or leader intended, produced by the way local responses combine. A CAS reading treats the organization as a set of agents, people and teams, each adapting to signals around them: targets, incentives, what their manager reacted to last week, what happened to the last person who raised a concern. Because each agent adapts, the system’s behaviour changes as conditions change, and the same structure can produce different outcomes in different years.
This matters to diagnosis because a fixed-machine view sends the team looking for the broken part, and in an emergent system there often is no broken part. Every component may be working as designed while the whole produces a bad result. A sales team hitting its quarterly bookings target while delivery drowns in poorly scoped deals is a typical emergent outcome: both teams are performing to their own measures, and the damage comes from how those measures interact. A diagnosis that hunts for the underperformer will find nobody to blame, while one that maps the interaction will find the incentive misalignment quickly.
What ‘Interaction Patterns’ Means in Practice
An interaction pattern is a recurring sequence of moves between people or groups that produces the same kind of outcome each time it runs, regardless of who occupies the roles. It has a recognisable trigger, a characteristic response, and a counter-response that sets up the next trigger. Spotting one means looking for repetition across incidents: the same handoff failing, the same escalation route, the same meeting where decisions get deferred.
In the same Harvard Business Review piece, Carucci recounts a technology CEO whose leadership team agreed priorities at the start of each quarter, only for him to be told at each review that urgent crises had prevented progress 4 Organizational Design Issues That Most Leaders Misdiagnose (Harvard Business Review). Read as a symptom, that looks like a discipline problem. Read as an interaction pattern, it is a loop: priorities are set without the capacity to protect them, crises absorb the capacity, the review accepts the crises as legitimate, and the next quarter starts the same way. Naming the loop gives the diagnosis something specific to change, such as how the review responds to crises, and that small change can break a cycle that years of priority-setting never touched.
Diagnostic Methods: Running Surveys, Interviews, and Comment Coding
Organizational diagnosis typically gathers its data through three instruments that do different jobs: structured surveys for breadth across the population, interviews for depth inside particular roles, and comment coding to turn open-text answers into themes that can be counted and compared across groups.
Each instrument imports the analyst’s assumptions at a different point. The survey designer chooses which questions exist; the interviewer chooses whom to ask and what to follow up; the coder chooses which themes the open text falls into. Which diagnostic approach a situation calls for is a separate choice. Once it is made, running the instruments well is mostly a matter of knowing where each one bends the data and compensating for it.
Surveys for Breadth, Interviews for Depth
Surveys reach everyone cheaply and show how a pattern distributes across groups, while interviews reach few people slowly and show how the pattern works from inside.
Breadth and depth trade against each other, and most diagnoses need both because each answers a question the other cannot. A survey can show that one site reports far lower clarity about decision rights than the rest, yet it cannot say why. An interview at that site can surface the mechanism, perhaps a regional director who reverses decisions after the fact, but cannot say whether the same mechanism runs elsewhere. Sequencing matters too: running interviews first lets the survey test patterns the interviews surfaced, while running the survey first lets the interviews chase the anomalies it revealed. Both orders work, and mixing them without a plan produces two datasets that never speak to each other.
Diagnostic Surveys: What Breadth Buys and Where It Bends
Diagnostic surveys put the same fixed-choice questions to a large population, so responses can be compared across teams, sites, levels, and tenure bands. Their value comes from the cuts: an overall score says little, while the difference between how frontline staff and middle managers answer the same item often points straight at the problem. Good diagnostic surveys keep the item count low, ask about observable behaviour wherever possible, and include at least one open-text question to feed the comment-coding stage.
The limitation is that a survey can only find problems someone thought to ask about. If no item covers how budget approvals work, a diagnosis whose real issue is a slow approval cycle will show nothing in the scores and everything in the open text. Survey fatigue compounds the risk: organizations that run engagement, pulse, and diagnostic surveys in the same quarter tend to see thin response rates from exactly the groups most frustrated, which skews the picture toward the satisfied.
Structured Interviews: Sampling Across the System
Structured interviews put a consistent core of questions to a deliberately chosen sample, leaving room to follow up on whatever each person raises. The sample is the design decision that matters most: interviewees should be chosen because they sit at different points in the system, upstream and downstream of a handoff, senior and frontline, inside and outside the function that owns the presenting problem. A consistent core lets the team compare answers, and the follow-up room lets it find what the core missed.
Sampling across positions follows from treating disagreement between roles as data. If every interviewee comes from the sponsor’s function, the diagnosis hears one account many times and mistakes repetition for confirmation. A sample that includes the people on the receiving end of that function’s decisions will produce conflicting accounts, and the points of conflict show where the diagnosis should look next. Practitioners often add a handful of interviews with people who recently joined or recently left, since both groups can still describe norms that long-tenured staff no longer notice.
Comment Coding: Turning Open-Text Answers Into Themes
Comment coding groups free-text answers from surveys and interviews into recurring themes, surfacing issues that no fixed-choice question would ever have listed as an option.
The method looks clerical and carries a lot of judgement. A coder reads each response, assigns one or more theme labels, and refines the label set as new responses arrive, until the themes stabilise and every response fits somewhere. The resulting counts let the team say how often each theme appears in each division or level, which often produces the finding the survey never asked about.
The risk sits in who defines the themes. A coder who arrives expecting a communication problem will find communication in comments that are really about authority, and the theme counts will look like strong evidence for a conclusion the coder brought in. Lawyers handle a similar risk by decomposing a complex problem into its elements and testing each element against the evidence before deciding anything, a discipline The Change Compass argues change practitioners can apply far more widely Analytical rigour in change management: a lawyer’s method (The Change Compass). For comment coding, that means splitting a broad theme such as “communication” into testable elements, namely who is left uninformed, about what, and with what consequence, and checking each element against the text.
Two practical safeguards help. A second coder working independently on a sample shows where the label set is ambiguous, since disagreements cluster on vague themes. Keeping the original quotations attached to each theme lets readers of the findings see the evidence for themselves, which matters when groups later dispute what the diagnosis says. Comment coding done this way gives the open text the same standing as the scores, and in many diagnoses it ends up carrying the main finding.
Cognitive Edge SenseMaker: Narrative Capture as an Alternative to Fixed-Choice Surveys
Narrative capture tools such as SenseMaker collect short stories from many participants and ask each participant to tag the meaning of their own story, replacing fixed-choice items with self-interpreted experience.
The appeal and the difficulty come from the same place: there is no single score to report. Participants are prompted with an open question, such as asking them to describe a recent moment that made them hopeful or worried about the change, and they write or record a short account. They then place that account on a small set of scales and triangles that the designer built around the questions the diagnosis cares about. Collection is distributed, so hundreds or thousands of these micro-narratives can arrive from across the organization without an interviewer present.
What the analyst works with is the distribution of tags, with the stories attached. Clusters show where experience concentrates; outliers show minority experiences that a mean would have hidden; differences between groups show where interpretation splits. For a diagnosis framed around fragmented meaning, that is close to a direct measurement of the thing being diagnosed, and it complements the structured instruments by covering what they are weakest at.
The Illuminate 360° Cycle: Collection, Analysis, Reflection, Decision, Action
The cycle runs five stages as a repeating loop: collect stories and their self-signified tags; analyse the patterns in how the tags cluster; reflect on those patterns with the people who produced them; decide what small change to try; and act, then collect again to see whether the pattern shifted. Each pass is short, and the loop is designed to run continuously across a change instead of once at its start.
The loop matters because it closes the gap between diagnosis and intervention that single-pass methods leave open. A one-off survey produces a snapshot that is out of date by the time the report is written; a repeating collection cycle shows whether the pattern is moving in response to what the organization did. For a change team, that turns diagnosis into a running read on the situation, and a pattern that fails to shift after an intervention becomes evidence that the intervention targeted the wrong loop.
Why Self-Signified Stories Reduce Analyst-Imposed Interpretation
Self-signification means the person who tells a story also places it on a set of interpretive scales, for example whether the experience felt more like control or support, so the meaning attached to the story comes from its author. The analyst sees both the story and its author’s reading of it, and works with patterns across many self-placed tags instead of imposing a coding frame on raw text.
This addresses the weakness that comment coding carries, which is the coder’s own categories. When participants signify their own stories, the step where an analyst’s expectations slip into the data shrinks, and disagreements between groups show up as different tag distributions for similar stories. If two functions tag stories about the same handoff in opposite directions, the diagnosis has a visible, quantified picture of fragmented meaning, gathered without asking anyone to agree with anyone. The trade-off is design effort, since the signification scales have to be built carefully or they import the designer’s assumptions instead.
Triangulating the Instruments Before Findings Are Written Up
Triangulation means checking each emerging finding against at least two instruments before it enters the findings, so a pattern that appears in only one dataset gets treated as a lead to follow.
The value of running several instruments comes from their disagreements. When the survey, the interviews, and the coded comments point the same way, the finding is robust. When they diverge, say a survey showing high satisfaction with leadership while the open text is full of complaints about one leader, the divergence is itself a finding, often about who answered which instrument and how safe they felt doing so.
A simple working method is a finding-by-source grid. Each row is a candidate finding; columns record whether the survey supports it, whether interviews support it, and whether the coded comments support it, with a note on any operational data such as turnover or cycle times. Rows with support from only one source go back into fieldwork as open questions. Rows where sources conflict get a short note on the most plausible reasons, which feeds directly into how the report handles contested points.
The discipline costs extra fieldwork time and saves considerably more later, because findings that survived triangulation are much harder for a sceptical group to dismiss. A finding resting on one dataset invites the response that it is just the survey talking, and the conversation shifts to methodology and away from the problem the diagnosis was commissioned to explain.
Building the System Map: Visualizing Interaction Patterns Instead of Isolated Symptoms
A system map in organizational diagnosis plots how people, information, and decisions actually move, built from a comparison of formal structure with real flow, a network map of formal and informal connections, and three capture targets drawn from Human Systems Dynamics.
The tension is that most organizations already own a picture of themselves, the org chart, and it carries authority. A system map that contradicts it can feel like an accusation. The map earns its place by showing the routes that work actually takes, which is why it takes the interaction patterns surfaced through sensemaking as given and adds what they lack: where each one runs.
Formal Structure vs. Actual Information and Decision Flow
Formal structure shows who reports to whom, while actual flow shows who people go to for information, who really makes decisions, and where requests wait.
The two diverge for ordinary reasons. Reporting lines are drawn once and redrawn rarely, while working routes adapt weekly to who is responsive, who holds a relevant history, and who can unblock a request. Over time a parallel structure forms: a long-tenured analyst who answers every pricing question, a deputy who effectively makes the calls her director signs, a cross-functional chat channel where decisions happen before the meeting that is meant to make them.
Weisbord’s model anticipated this by requiring that each of its categories be diagnosed through both its formal and informal dimensions, and by placing Leadership at the centre because it carries responsibility for scanning the environment and setting goals Weisbord Six-Box Model (Think Insights). A structure box read only formally will show the chart; read informally, it shows the routes.
For diagnosis, the gap between the two is where the explanatory power sits. When a presenting problem such as slow approvals is mapped against formal structure alone, the remedy looks like a delegation-of-authority change. When it is mapped against actual flow, the map often shows approvals waiting on one informal gatekeeper whose sign-off nobody formally requires and everybody seeks. The first remedy changes a document, and the second changes the pattern. Teams that map only the formal structure tend to redesign the chart and find, a year later, that the old routes have quietly re-formed around the new boxes.
McChrystal Group’s Network-Mapping Approach to Finding Key Influencers
Network mapping of this kind charts both the formal and informal connections in an organization to identify the people who actually influence outcomes, whatever their title.
The people a diagnosis most needs to find are often invisible in its own sampling plan, since sampling usually follows the chart. Key influencers are the people whose opinion others wait for before committing, who broker information between groups that otherwise rarely talk, and whose support or quiet resistance determines whether a change sticks. Some of them hold senior roles; many hold none, and their influence comes from tenure, expertise, or a position at the junction of two groups.
Mapping both layers and comparing them is what gives the method its diagnostic power. Each layer on its own is a partial account: the formal layer shows what the organization intends, and the informal layer shows what it does. Where they line up, the organization works roughly as designed. Where they split, the diagnosis has found either a dependency the organization has not acknowledged or a governance route that exists only on paper, and both kinds of split tend to explain stubborn presenting problems better than any single interview can.
Mapping Formal Connections
Formal connections are the documented relationships: reporting lines, committee memberships, approval rights, and the handoffs written into process documents. Mapping them means drawing who is required to interact with whom, usually from HR data, governance charters, and process maps, and marking where decisions are formally made. The result is the organization’s official theory of how it works.
The formal map is the baseline every other finding gets measured against, which is why it is worth drawing carefully even though it is incomplete. Where the informal map shows heavy traffic and the formal map shows no connection, the organization depends on a relationship it has not acknowledged and cannot protect. Where the formal map shows a required connection and the informal map shows no traffic, a governance step exists on paper only, which often explains why decisions made in that forum never stick.
Mapping Informal Connections
Informal connections are the relationships people actually use: whom they ask for advice, whom they trust with bad news, whom they check with before committing to a decision. They are usually mapped from interview questions such as “who do you go to when you need to understand what leadership really wants?” or from short network surveys asking each person to name their go-to contacts for specific kinds of help. Aggregated, the answers reveal hubs, brokers between groups, and people at the edges.
Treating informal influence as equally diagnostic to formal hierarchy is what separates a system map from an org chart redrawn with different software. The informal map often reveals that a change’s success depends on a handful of people with no formal authority over it, and that some formally senior people sit at the periphery of the networks that matter. For a change team, the practical consequence is a different stakeholder list: the people to involve early are the hubs and brokers the map revealed, and a sponsor’s endorsement alone rarely moves a network that routes around the sponsor.
Human Systems Dynamics: Patterns, Container Differences, and Significant Distinctions
Three capture targets keep a system map focused: recurring patterns, differences between containers such as teams, departments, or sites, and the significant distinctions that drive behaviour inside them.
Patterns are the recurring interactions the map records with their locations. Containers are the bounded groups within which those patterns form, and container differences are the cases where the same policy, the same process, or the same leadership message produces different behaviour in different groups. A container difference is diagnostically valuable because it rules out the shared element as the cause: if one site handles a new procurement rule smoothly and another site stalls, the rule alone cannot explain the stall, and the diagnosis should look at what differs locally.
Significant distinctions are the differences people inside a container treat as meaningful, such as permanent staff and contractors, head office and field, or engineering and everyone else. They shape who talks to whom, whose input counts, and which information crosses which boundary. On a map they often appear as clusters with thin links between them, and the thin links frequently sit exactly where the presenting problem shows up.
Holding all three targets together prevents two common mapping errors. A map that records only patterns becomes a tangle with no explanation of why the tangle takes that shape. A map that records only formal containers repeats the org chart. Capturing the distinctions that people themselves draw is what turns the map into an explanation the organization recognises, and an explanation people recognise is one they are far more willing to change.
Locating Interaction Patterns Between People, Teams, and Sites
Locating a pattern on the map means recording between which people, teams, or sites it runs, so a loop described in interviews gains an address that the change team can act on.
A pattern without a location produces general advice. The quarterly-priorities crisis loop, for instance, could prompt a generic recommendation to protect capacity. Placed on a map, it might turn out to run between a portfolio office and two particular delivery leads, through one informal broker who decides which crises reach the review. That location changes the intervention from an organization-wide edict into a specific conversation with three people about how crises get escalated, a far smaller experiment with a far clearer signal of whether it worked.
Location also shows where a pattern stops. If the same loop runs in two business units but not a third, the third unit’s container holds something the others lack, and that difference is often the most transferable finding a diagnosis produces. It gives the organization an internal example of the alternative, which tends to persuade more than any outside benchmark.
This kind of pattern analysis is not confined to corporate settings. In the Journal of Innovation Management, Organizational innovation in the context of family farms: lean diagnosis applies a lean diagnostic lens to family farming in Portugal, combining integrated agriculture and work-organization frameworks to examine how production is organized. Small, kin-based operations carry the same mix of formal roles and informal routes as a large company, and reading where interactions actually run helps there for the same reason it helps anywhere.
Choosing the Right Lens: Cynefin, Soft Systems Methodology, and When a Fixed Model Falls Short
Choosing the right lens for an organizational diagnosis means deciding first whether the situation is ordered enough for expert analysis with a named model, or complex enough that only small experiments will reveal what is going on.
Practitioners skip this decision more often than any other, usually by defaulting to the model they know. In an ordered situation that works well; in a complex one it produces confident findings that the next intervention disproves. The instruments, the surveys, interviews, and coded comments, stay largely the same across lenses. What changes is how much the team trusts expert categories, how it reads the data, and what kind of conclusion it allows itself to reach. The Cynefin framework serves here purely as the lens for that choice; its full treatment belongs to its own page.
The Four Cynefin Domains: Obvious, Complicated, Complex, Chaotic
The Cynefin framework sorts situations into four domains by how knowable cause and effect are: obvious, complicated, complex, and chaotic, each calling for a different diagnostic approach.
In the obvious domain, cause and effect are clear to anyone involved, and established practice handles the problem; a full diagnosis is rarely worth its cost. In the complicated domain, cause and effect exist but take expertise to uncover, so expert analysis with a sound model can find the answer. In the complex domain, cause and effect become visible only in hindsight, because the system adapts to whatever is done to it; diagnosis there proceeds by probing, watching the response, and adjusting. In the chaotic domain, no stable relationship is perceivable at all, and the first move is to act to stabilise the situation, with diagnosis following once some order returns.
The framework has travelled well beyond organizational development. A paper exploring Cynefin to inform software development approach decisions argues that conventional approaches have limited value when applied to a complex environment, and proposes a holistic approach built on the framework Exploring the Use of the Cynefin Framework to Inform Software Development Approach Decisions (ResearchGate). The same argument applies to diagnosis: a method calibrated for complicated problems underperforms when the organization is behaving as a complex system.
The practical difficulty is classification. Organizations rarely sit in one domain, and the presenting problem itself can sit in a different domain from its surroundings. Misclassifying a complex problem as complicated is the expensive error, because it licenses an expert answer that the system then routes around.
Matching the Domain to the Method: Expert Analysis vs. Small Experiments
A complicated situation supports expert analysis with a named model such as the McKinsey 7S Model, while a complex situation requires probing through small experiments before any pattern is clear enough to analyse.
| Domain | Signs in the diagnostic data | Diagnostic approach | What a finding looks like |
|---|---|---|---|
| Obvious | Everyone describes the problem and its cause the same way | Apply established practice; skip a full diagnosis | A known fix and an owner |
| Complicated | Experts converge on causes once data is in; the problem repeats predictably | Expert analysis with a named model; compare against known organizational patterns | A causal explanation and a remedy |
| Complex | Accounts conflict; past fixes moved the problem; interventions produce surprises | Small safe-to-fail experiments, narrative capture, repeated reflection | A pattern hypothesis and the next experiment |
| Chaotic | No stable pattern; harm is happening now | Stabilise first, then diagnose once order returns | A stabilising action and a date to diagnose |
The complicated row is where named models earn their place. Bain & Company’s Organizational Navigator, for example, rests on an analysis that six organizational outcomes enable strong business performance and that companies often exhibit one of five organizational patterns, so executives who identify their pattern can decide where to invest and which levers to pull Finding the Right Remedy for Poor Organizational Performance (Bain & Company). A worked complicated-domain case appears in the Journal of International Business and Management, where Implementing Mckinsey 7S Model of Organizational Diagnosis and Planned Change, Best Western Italy Case Analysis applies the 7S Model to Best Western Italy, the brand’s centre for operations and reservations in the European market. A defined operating unit with a known business model is the kind of situation where an expert frame fits.
The complex row asks for a different temperament: several small experiments run in parallel, each designed so that failure is cheap and informative, with the diagnosis updated after each one.
Soft Systems Methodology: Holding Multiple Worldviews Without Collapsing Them
Soft Systems Methodology holds several stakeholder worldviews side by side as legitimate accounts of a situation, instead of collapsing them into one official version before the diagnosis has understood any of them.
The method suits messy situations where people disagree about what the problem even is. Umbrex notes that it strengthens the discovery stage through rich pictures and worldviews, and that it is well suited to the complex domain, where multiple perspectives matter and safe-to-fail probes test changes Soft Systems Methodology (Checkland) (Umbrex). Its two signature devices give the diagnosis a way to record disagreement without pretending to resolve it early.
Rich Pictures
A rich picture is a hand-drawn, cartoon-like map of a problem situation that captures people, groups, relationships, conflicts, concerns, and flows in one image, including the tensions nobody writes into a formal document. Participants draw it together, or a facilitator draws it from what they describe, and it deliberately includes emotions and politics alongside structures and processes. The informality is functional, because a sketch invites corrections in a way a polished diagram does not.
Rich pictures matter because they let a group see the whole messy situation before anyone reduces it to a problem statement. Two functions that would never agree on a written definition of the problem can often agree that a drawing shows what is happening, including the parts where they clash. A diagnostic workshop that opens with a rich picture of a failing product handoff typically surfaces the informal approver, the conflicting incentives, and the resentment about past decisions in one sitting, giving the rest of the diagnosis a shared starting image.
Root Definitions
A root definition is a concise statement of what a relevant system does from one particular worldview: the transformation it performs, who benefits, who carries it out, who could stop it, and which constraints it operates within. The diagnostic team writes several root definitions for the same situation, one per significant worldview, instead of choosing one. Each definition makes the assumptions of its worldview explicit and comparable.
The value lies in what comparison reveals. A procurement function defined from finance’s worldview transforms requests into controlled spend; defined from operations’ worldview, it transforms urgent needs into delays. Setting those definitions side by side shows that the disagreement is about purpose, which no amount of process mapping would fix. The diagnosis can then propose changes that are feasible across worldviews, or at least name honestly which worldview a proposed change serves.
Appreciative Inquiry: Starting From Strengths Instead of Deficits
Appreciative Inquiry starts a diagnosis from documented strengths and generative past experiences, asking when the organization has worked at its best and what conditions made that possible.
The approach answers a practical problem with deficit-led diagnosis: a list of everything wrong tends to make people defensive, and defensive people give guarded data. Asking a team to describe the best cross-functional handoff they experienced in the past year produces detailed, candid accounts, and those accounts carry specific conditions such as a shared deadline, co-location, or a decision-maker who stayed in the room. Those conditions are themselves diagnostic findings, since their absence elsewhere often explains the failures.
Appreciative Inquiry fits complex situations particularly well, because amplifying conditions that already work is a natural small experiment: the organization tries to reproduce a known success in a new place and watches what happens. It also suits organizations worn down by repeated change, where another round of problem-hunting would deepen cynicism.
The risk is avoidance. A diagnosis that only asks about strengths can leave real dysfunction unnamed, and sponsors may use the positive tone to skip uncomfortable findings. Experienced practitioners pair the strengths inquiry with direct questions about what blocks those conditions from spreading, so the hard truths arrive attached to a picture of what better looks like. Without that pairing, the diagnosis leaves people feeling good and the system unchanged.
What the Diagnosis Report Holds: From Raw Findings to a Workable Common Picture
An organizational diagnosis report holds the findings in a form competing groups can act on together: what is agreed, what is still contested, and what evidence would resolve each contested point, so the result is a workable common picture.
The instinct of most report writers runs the other way. A neutral-sounding document with one tidy narrative feels professional, and sponsors often ask for exactly that. The trouble is that every tidy narrative chooses a side when stakeholders disagree, and the side it did not choose reads the report as a verdict against them and quietly declines to act on it.
Beyond a Document: Building a Shared, Workable Picture
A diagnosis report succeeds when competing groups can each recognise their own situation in it and agree on enough to act together, which makes uptake by its readers the real measure of its quality.
That changes what goes into it. The diagnostic phase of a transformation maps the current cultural, operational, and organizational reality before change is introduced, identifying what must shift, who is affected, what risks exist, and what benefits different stakeholders expect Diagnosing Change: The Strategic Transformation Diagnostic (Lemon Learning). A report organized around those questions speaks to each stakeholder group about its own stake, which is far more likely to be read than an executive summary of scores.
The report also has to fold qualitative and quantitative findings into one integrated picture. Separate chapters for survey scores, interview themes, and coded comments invite each audience to read the chapter that suits it. A single picture, in which each finding carries its supporting numbers and quotations together, makes the evidence harder to cherry-pick. A simple structure keeps the picture honest:
| Part of the report | What it states | Example entry |
|---|---|---|
| Agreed | Findings every group recognises as accurate | Spend approvals above the regional limit route through head office and wait there |
| Contested | Findings groups read differently, each reading stated in its holders’ own words | Operations reads the wait as risk aversion; finance reads it as incomplete submissions |
| Evidence that would resolve | The data or experiment that would decide each contested point | Sample recent submissions for completeness and time each approval stage |
| Next experiment | The smallest change worth trying while the contested points are tested | Pilot a submission checklist in one region for one quarter |
What a Workable Common Picture Contains
A workable common picture is a shared account of the situation that each stakeholder group can recognise as describing its own reality, with disagreements stated openly and paired with the evidence that would resolve them. It contains the agreed findings, the contested findings with each side’s reading in that side’s language, and a plan for gathering the evidence or running the experiment that would resolve each dispute. It is workable because it supports a next action, and common because no group has to abandon its own account to accept it.
This matters because adoption depends on recognition. A group that finds its account erased will treat the report’s recommendations as someone else’s agenda, whatever their merit. A group that finds its account stated fairly, even beside a competing one, can agree to the evidence test that will decide the matter. A report built this way turns a standoff into a joint inquiry, and the act of agreeing what evidence would count is often the first jointly made decision the groups have made in months.
When Stakeholders Disagree About the Organization’s Purpose
Disagreement about what the organization is for, or about what counts as improvement, is the hardest case for a diagnosis report, because any framing the report adopts decides the dispute on one side’s terms.
Consider a hospital where clinicians understand the organization’s purpose as patient outcomes and administrators understand it as financial sustainability that keeps the doors open. A finding that operating theatres run below capacity is a failure in one reading and a safety margin in the other. A report that labels it inefficiency has sided with administration; a report that labels it prudence has sided with the clinicians. Either way, half the readership disengages.
The workable move is to name both purposes explicitly near the start, then show which findings hold under both readings and which depend on the reading. Findings that hold under both, such as delays caused by missing equipment, become the agreed base for early action. Findings that depend on the reading become contested findings, and the report states what each side would need to see to change its view. Sometimes the honest conclusion is that the organization must make an explicit choice about purpose before some findings can be acted on at all, and saying so is a legitimate diagnostic result.
A report that ducks the purpose dispute tends to become ammunition. Each side quotes the sections that support it, the dispute hardens, and the diagnosis ends up deepening the fragmentation it was commissioned to reduce.
Participatory Action Research: Participants as Co-Researchers
Participatory Action Research treats the people affected by a problem as co-researchers who help frame the questions, gather and interpret data, and test changes, instead of as subjects the diagnostic team studies.
The method runs in cycles of planning, acting, observing, and reflecting, with participants involved at each step. In a diagnosis, that can mean frontline staff helping design the interview guide, interviewing peers in other teams, sitting in on comment coding, and co-writing the interpretation of what the data shows. Their position inside the system lets them spot meanings an outside analyst would miss, such as the significance of a phrase that recurs in the open text or the history behind a resentment.
The costs are real. Participatory diagnosis is slower, harder to schedule, and less controllable; vocal participants can steer the inquiry toward their own concerns, and participants who interview colleagues may hear less candour than an outsider would. Practitioners manage these risks by rotating who interprets which data, mixing participant and external interviewers, and making the method’s choices visible in the report.
Why Co-Authorship Increases Ownership of the Findings
Co-authorship means participants contribute to writing the findings as well as supplying them, so the report’s account of the situation is partly in their words and reflects their interpretations. When people help decide what a pattern means and how to describe it, the conclusion stops being something done to them. The mechanism is straightforward: people defend explanations they helped build and question explanations handed to them.
Ownership matters because a diagnosis only pays off when people act on it, and the people who must act are usually the ones the findings describe. A finding that a team’s handoff practices cause rework lands as criticism when an outsider writes it, and as a shared discovery when two members of that team co-wrote it after interviewing the downstream team. Change teams that co-author findings with participants commonly find that the first experiments start before the report is formally issued, because the people who will run them already believe the diagnosis.
Developmental Evaluation: Treating the Report as Real-Time Learning
Developmental Evaluation treats the diagnosis as a running read on an evolving situation, updating findings as conditions shift instead of issuing one closed verdict and moving on.
The approach comes from settings where the thing being evaluated is still taking shape, which describes most organizations in the middle of change. An evaluator or diagnostic lead stays embedded with the team, feeds findings back as they emerge, and revises the picture as experiments produce results. The report becomes a living document with dated versions, each stating what the team believes now, how confident it is, and what new evidence would change its mind.
This suits the complex situations where fixed findings date fastest. A finding about resistance in one division may be accurate in March and obsolete by June, after a leadership change or a successful pilot. A closed report would keep circulating the March finding; a developmental one records the shift and what caused it, which is itself useful evidence about what works.
The discipline it demands is version control of belief. Teams have to record which findings were revised and why, or the living report turns into a moving target that nobody trusts. Done well, it gives the sponsor a continuous sense of where the organization stands, and the cost of that continuity is that the diagnostic team never quite gets to declare itself finished.
Running a Project Health Check With the Prosci Change Triangle
A project health check with the Prosci Change Triangle reviews one change project across three legs, leadership and sponsorship, project management, and change management, and treats a weak leg as a reason to pause before the gap reaches the people expected to adopt the change.
It is organizational diagnosis scaled down to a single project and run as a go/no-go review for the sponsor. Each leg is checked separately because a strong leg can hide a failing one: a well-run project plan makes a project look healthy right up to the point where nobody adopts what it delivered.
Leg One: Leadership and Sponsorship
A leadership and sponsorship gap shows up as an unclear or absent active sponsor, even though its visible symptoms often look like technical project trouble.
The symptoms rarely announce themselves as sponsorship problems. Decisions sit waiting for weeks; scope disputes escalate and come back unresolved; steering meetings are delegated to deputies who cannot commit resources; the project team re-plans around blockers instead of escalating them because escalation has stopped producing answers. Each of these looks like a planning or delivery issue, and project managers often absorb the blame for what is a vacancy at the top of the project.
The check is a set of plain questions. Who is the sponsor, and would the managers of affected teams name the same person? When did the sponsor last make a decision on this project, and how long did it take? Has the sponsor spoken directly to the people whose work will change, or only to the project team? If the answers are vague or inconsistent, the leg is weak regardless of how healthy the plan looks.
A weak sponsorship leg matters more than the other two because it governs the others. Without an active sponsor, project-management gaps go unresolved and change-management work goes unfunded. When the check finds this gap, the most useful go/no-go outcome is often a pause until the sponsorship question is resolved, since every week of progress without a sponsor builds more of something the organization may never adopt.
Leg Two: Project Management
A project-management gap shows up as unclear scope, timeline, or resourcing for the change itself, a separate question from whether people are ready to adopt it.
This leg concerns the technical side of delivering the change: what exactly is being built or altered, by when, and with whose time. The symptoms are familiar: a scope that keeps expanding at each meeting, milestones that move without anyone deciding to move them, and key contributors borrowed from operational teams who reclaim them when the day job gets busy. Unlike a sponsorship gap, the trouble here usually is what it looks like.
The check asks whether the team can state the scope in a sentence that the sponsor and the affected managers would all accept, whether the current timeline reflects real capacity, and whether named people with protected time sit behind each critical task. A project whose resourcing depends on goodwill from operational managers is weaker than its plan suggests, since goodwill evaporates under pressure.
Separating this leg from the people side matters for diagnosis. A team that is technically on track can still fail to deliver value if adoption is weak, and a team with keen early adopters can still fail if the thing they are waiting for keeps slipping. Reading the legs separately lets the sponsor see which kind of trouble the project has, and respond with the right remedy instead of applying more training to a scoping problem or more planning to a sponsorship vacuum.
Leg Three: Change Management
A change-management gap shows up as missing stakeholder engagement, communication, or training plans, and it can sit inside a project whose plan and sponsorship are both solid.
This leg covers the people side: whether the groups whose work will change know what is coming, understand why, have had a voice in shaping it, and will have the skills to work differently when it lands. Projects with strong technical teams often treat this leg as a late-stage communications task, which is why it so often sits empty at the midpoint while the plan and sponsorship look fine.
The symptoms are quiet until go-live. There is no stakeholder map beyond the steering committee; communication consists of project updates sent to people who did not ask for them; training is scheduled for the week before launch; and nobody has asked frontline managers what the change will cost their teams in the transition. The check asks for evidence of each: who has been engaged, how they responded, what has changed in the plan as a result, and when people will practise the new way of working.
A gap here produces a specific failure: the project delivers on time and on budget, and usage stays low. Because the delivery metrics were green, the failure is often blamed on users, and a second project is launched to fix adoption. Catching the gap at a milestone review costs far less than that second project, and the check gives the sponsor something concrete to fund.
Checking Health at Each Milestone, Not Only at Kickoff
Running the triangle check at each project milestone catches a leg that degrades over time, which a single kickoff check cannot see.
Legs that look healthy at launch erode as projects proceed. Sponsors move to new priorities or new jobs; contributors get pulled back to operations; engagement plans drafted with enthusiasm stall once the initial communications go out. Sponsor turnover alone can hollow out the first leg mid-project, and senior tenure is often shorter than a large change: in 2006, about 40% of US CEOs who left their jobs had lasted an average of just 1.8 years, according to the outplacement firm Challenger, Gray & Christmas The New Leader’s Guide to Diagnosing the Business (Harvard Business Review). A project sponsored by an executive who leaves at the midpoint has a different health profile from the one checked at kickoff.
Treating each milestone as a go/no-go review gives the sponsor a structured choice: proceed, pause, or escalate.
| Leg | What to confirm at kickoff | What tends to degrade by mid-project | Signal to pause or escalate |
|---|---|---|---|
| Leadership and sponsorship | A named sponsor accepted by affected managers | Sponsor attention, decision speed, presence with affected groups | Decisions waiting beyond one cycle; sponsor change without handover |
| Project management | Scope stated in one sentence; protected capacity | Scope stability; contributors’ protected time | Milestones moving without a decision; key roles reclaimed by operations |
| Change management | Stakeholder map and engagement plan beyond the steering group | Engagement after initial communications; training timing | No evidence of stakeholder input changing the plan; training compressed into launch week |
The review only works if a pause is a real option. Teams whose sponsors treat every milestone as a formality learn to report green, and the check turns into theatre. When a sponsor visibly pauses a project to fix a weak leg, the next round of reporting tends to become more honest.
Organizational Diagnosis vs. Related Assessments: Readiness, Health, and Impact
Organizational diagnosis has three neighbouring assessments that are easily mistaken for it: a change readiness assessment asking whether one chosen change can be absorbed, a health assessment benchmarking overall performance, and a change impact assessment mapping what a planned change will touch.
Each answers a different question at a different moment, and commissioning the wrong one starts the work with the wrong question. Organizations that confuse them tend to pay for an answer to a question they were not asking.
| Assessment | Starting question | When it runs | What it produces |
|---|---|---|---|
| Organizational diagnosis | What keeps driving the problem we see? | When a presenting problem persists, or before deciding what to change | An explanation of drivers and a workable common picture |
| Change readiness assessment | Can we absorb this specific change? | Before a named change launches | Readiness by group and the gaps to close |
| Organizational health assessment | How does our overall health compare with a standard? | On a regular cycle, or as a baseline | Benchmark scores across defined outcomes and practices |
| Change impact assessment | What will this planned change touch? | After the change is designed, before rollout | A map of affected groups, processes, and systems |
Diagnosis vs. Change Readiness Assessment: Why, Not Whether
A readiness assessment presumes the change has been chosen and measures capacity to absorb it, so it cannot tell a sponsor whether the chosen change addresses the problem at all.
That presumption is its strength and its blind spot. Once a change is fixed, readiness questions are the right ones: do the affected groups understand it, are their leaders aligned, do they have the capacity and skills to make the shift. A readiness assessment answers these well and hands the change team a list of gaps to close before launch.
The trouble comes when readiness is used in place of diagnosis. An organization that skipped diagnosis, chose a new operating model because a peer adopted one, and then ran a readiness assessment will learn how ready people are for a remedy that may not fit its problem. High readiness scores in that situation are dangerous, because they lend confidence to a change that was never tested against the cause.
The sequence matters. Diagnosis comes first; the change is designed in response to its findings; readiness then checks whether the organization can absorb that particular change. Running readiness first inverts the logic and tends to produce well-prepared adoption of the wrong thing, a failure that is hard to spot until the expected results fail to appear.
Diagnosis vs. Organizational Health Assessment: Problem vs. Benchmark
A health assessment scores the whole organization against a fixed set of outcomes and practices, which makes it strong for comparison over time and weak at explaining one specific presenting problem.
The best-known example is McKinsey & Company’s Organizational Health Index, which by McKinsey’s own description measures 9 health outcomes, 43 management practices, and 10 employee experience dimensions, and compares an organization with a database of 2,600 clients and 8 million survey responses; McKinsey also claims that companies with top-quartile health deliver, on average, 3x greater total shareholder returns over time How OHI works (McKinsey & Company). An instrument of that kind tells an organization where it stands relative to others and whether it is improving year on year.
What a benchmark cannot do is follow a specific problem to its cause. Its categories are fixed in advance, its questions are standardised for comparability, and its output is a profile of scores. A diagnosis run as a health benchmark will miss the specific problem it was meant to find, because a problem rooted in one handoff, one informal gatekeeper, or one disputed purpose rarely moves an organization-wide score enough to show.
The two work well in combination. A health benchmark can flag an area that scores low, and a diagnosis can then investigate why, using open questions, targeted interviews, and pattern mapping that the benchmark’s format does not allow. Treating the benchmark score as the diagnosis, and launching interventions at the low-scoring practice, tends to treat a category when the problem lives in a loop.
Diagnosis vs. Change Impact Assessment: Open Question vs. Narrow Map
A change impact assessment answers a narrower, later question than diagnosis: given a designed change, which groups, processes, and systems will it touch, and how heavily.
Its output is a map of consequences: which roles change and by how much, which processes need rework, which systems need configuration, and which groups face the heaviest transition. Change teams use that map to plan training, sequence communication, and allocate support. It is indispensable once the change exists in enough detail to trace its effects.
The difference from diagnosis is the direction of the question. Diagnosis looks backward and inward, asking what drives current behaviour with no remedy assumed. Impact assessment looks forward from a remedy already chosen, tracing where it will land. Because it starts from the change, it cannot reveal whether the change addresses the drivers of the problem, and an impact map for a well-chosen change and a poorly chosen one can look equally thorough.
The two connect through the system map. Interaction patterns and informal networks found during diagnosis often explain impacts an impact assessment would otherwise miss, such as a change that formally touches one team but informally disrupts the broker the whole division relies on. Organizations that carry diagnostic findings into impact assessment tend to anticipate those second-order effects; those that start fresh usually discover them after rollout.
Where Current State and Future State Analysis Fits
Current state and future state analysis builds the before-and-after picture that a diagnosis’s findings often feed into, and it is a distinct planning step with its own outputs.
Current state and future state analysis describes what the current state is, what the desired future state looks like, and what gap lies between them. The two overlap in their attention to the present, but diagnosis asks about causes while current-and-future-state work asks about the shape of the destination and the distance to it. A future state designed without a diagnosis behind it tends to describe an ideal without addressing what keeps producing the present.
The handoff between them is where diagnostic value is often lost. Findings about interaction patterns and contested purposes rarely fit neatly into a current-state template of processes, systems, and roles, and they get dropped. Carrying the workable common picture forward as an explicit input keeps the future state anchored to what actually drives the present.
The sequence holds outside corporate settings too. In the Brazilian Journal of Development, Organizational diagnosis: analysis of internal and external environments for operational management at the Military Police of Paraná diagnoses the internal strengths and weaknesses and the external opportunities and threats facing a public-security institution as it moves to implement its first strategic plan. A public-sector police force faces the same task as a company: understand where it stands before designing where it wants to go.
How to Start Applying Organizational Diagnosis
The first useful act is small and can happen this week: write the presenting problem down in the sponsor’s exact words, then list three rival explanations for it, each with a note on what evidence would favour it over the others. That page does two jobs. It shows whether the sponsor will tolerate an answer that differs from their own, and it gives fieldwork a shape before anyone designs a survey. If the sponsor cannot accept that the second or third explanation might win, the work ahead is an exercise in confirmation, and it is better to know that before spending on it.
Next comes scope. Most first diagnoses go wrong by trying to explain the whole organization at once, so pick the smallest slice of the organization that still contains the complaint: one site, one team boundary, one recurring meeting. A narrow first round produces findings fast enough to test with a small experiment, and the experiment’s result tells the team whether to widen the inquiry or change direction.
Three decisions are worth making before fieldwork starts, because they are hard to reverse later. Decide who will co-own the findings, and invite them in at the start instead of at the presentation. Decide what happens to raw data, including whether quotations will be shared and how anonymity will hold in small teams where a single phrase can identify its author. Decide whether the diagnostician should be an insider, who sees more but sits inside the very patterns under study, an outsider, who sees freshly but misses history, or a pairing of the two, which tends to catch what either alone would miss.
One boundary case deserves a straight answer. When leadership has already decided the remedy, say a restructure that has been announced, a diagnosis commissioned afterwards tends to become justification for a decision already made, and the people interviewed usually sense it. In that situation the honest move is to run an impact assessment openly under its own name, and keep diagnosis for a question that is still open.
The last risk is fatigue. Organizations that have been surveyed, interviewed, and workshopped repeatedly without seeing anything change will give thin, cautious answers to the next diagnosis. The surest remedy is visible action on something small from the previous round before asking anyone for more of their time. Which question to open first, and whom to invite into answering it, stays the reader’s call.
Anonymous. Counted, not tracked.
Where is your organisation with this right now?
What is the hardest part where you are?
In a sentence: what are you trying to work out right now?
No names, no company. Anonymous. Counted, not tracked.