There is a specific kind of failed rollout that the sequential change models cannot explain. The urgency case was honest. The coalition made real decisions. Training was good, the guides were there, the pilot went well. Twelve months later, adoption is at 55% and nobody can point to the moment it went wrong, because nothing did go wrong. Every step was completed.
The McKinsey 7S model is built for that situation. It is not a process, and it will not tell you what to do next. It is an alignment check: seven interdependent elements that all have to be consistent with each other for anything to hold. Its uncomfortable finding, applied to software, is easy to state — deploying a new tool changes exactly one of the seven, and the other six were all quietly shaped around the tool it replaced.
This guide covers the seven elements, the hard and soft split and why it matters more for software than for anything else, how to run a 7S audit as a working session, and where the model's limitations start. It complements our change management guide and the software rollout plan.
Key Takeaways
- 7S is a diagnostic, not a sequence. It answers "why isn't this holding?", not "what do we do next?"
- A software rollout changes one element out of seven. Systems goes live overnight; skills, structure, style, staff and shared values lag by months.
- The soft elements decide the outcome. They cannot be changed by announcement, which is why they are usually left out of the plan entirely.
- Every tool encodes assumptions about the other six elements. List them before you configure, because a false assumption becomes "resistance" later.
- Shared values is the tiebreaker. What actually gets rewarded will beat any policy, and it is visible in who gets promoted rather than on the intranet.
- Use it twice. Before launch to find what will resist, and after a well-run programme underdelivers to find out why.
What the 7S Model Says
The McKinsey 7S model, in one paragraph
A framework describing an organisation as seven interdependent elements — strategy, structure, systems, shared values, skills, style and staff — developed at McKinsey in the late 1970s by Tom Peters, Robert Waterman and colleagues. Its central claim is that performance depends on the seven being aligned with one another, and that changing one in isolation fails because the other six will pull it back to a consistent state. It is deliberately non-sequential: the elements are drawn as a connected web precisely because there is no first one.
The model's usefulness for software adoption comes from a fact it makes obvious and nothing else does: a system can be replaced overnight, and nothing else can. On the Monday after go-live, one element has completely changed and six are exactly as they were on Friday — including the skills that were built for the old tool, the structure whose approval chains were designed around it, and the informal norms about what "done" looks like.
The Seven Elements, and What Each Assumes About Your Rollout
Each element below comes with the question worth asking about it during a rollout — the one that surfaces a misalignment before it turns into a support queue.
How the organisation intends to compete and win. For a rollout, the question is whether the tool genuinely serves the strategy or was bought to solve an operational irritation that has since been framed strategically.
Ask: if this rollout succeeds completely, which strategic goal moves?
Reporting lines, decision rights and where authority actually sits. Nearly every workflow tool encodes an assumption about who is allowed to decide something, and it is often wrong.
Ask: does the tool assume decisions are made by people who are not currently allowed to make them?
The processes and tools people use daily — the element you are actually changing. It is the only one that can move in a single night, which is precisely the problem.
Ask: which surrounding processes still assume the old system exists?
What the organisation genuinely believes and rewards, as opposed to what it publishes. Sits at the centre of the model because it determines where the other six settle over time.
Ask: does the behaviour this tool requires get someone promoted here, or noticed for the wrong reasons?
What the organisation is collectively good at — not individual competence, but capability that exists reliably. Old-system expertise is a skill, and replacing the system destroys it.
Ask: whose expertise does this rollout make worthless, and what are we giving them instead?
How leaders actually behave, especially under pressure. Style is read from what happens when a deadline slips, not from what is said at the kickoff.
Ask: when this rollout makes someone temporarily slower, what will their manager do?
Who is here, how they are recruited, developed and rewarded, and what the mix of tenure and experience is. A long-tenured population changes differently from a high-turnover one.
Ask: do incentives and targets still reward the workflow we are replacing?
The pattern in those questions. Every one of them is about an assumption the software makes about the organisation. Tools are opinionated: they assume a decision structure, a skill level, a tolerance for visible mistakes and a set of incentives. When the assumption is false, the resulting behaviour gets labelled resistance — and no amount of change communication fixes a structural contradiction.
One Element Changes Overnight. Six Don't.
This is the single most useful thing 7S contributes to a rollout plan. Sketch the realistic time each element takes to actually change, and the shape of the problem becomes obvious.
There are two honest responses to that picture, and only two. Either you accept the lag and configure the system to fit the organisation you have — which usually means turning off the features that assume an organisation you do not have, and adding them later — or you take on changing a second element deliberately, with the time and authority that requires. What does not work is deploying against six false assumptions and treating the fallout as a communication problem.
The middle elements are also where in-product guidance earns its place. Skills is the fastest of the slow elements to move, and it moves fastest through repetition on real work rather than through training events — which is the argument for putting the help inside the application at the moment of use rather than in a session beforehand. Our digital adoption guide develops that case, and training employees on new software covers what a training programme can and cannot deliver.
Skills is the fastest of the slow elements to move — if practice happens on real work rather than in a workshop.
Running a 7S Alignment Audit
The audit is a two-hour working session, not a document. Invite people who know how the work is actually done, not only the people who own the project. For each element, answer two questions: what does the new system assume about this? and is that true today?
If you cannot name the strategic goal it moves, the project will lose every resourcing argument for the next year. That is worth knowing in advance.
Map one real workflow end to end in the new system and mark every point where it expects a decision. Then check who currently has authority at each of those points. Mismatches here are the most common single cause of a stalled workflow tool.
List every report, integration, external reference and audit artefact that the old system produces. Anything unclaimed at go-live becomes a permanent reason to keep the old path open.
Compare the stated values with observable ones. If the tool makes work visible and the organisation quietly rewards looking effortless, adoption will be partial and the missing part will be exactly the visibility you bought it for.
The person everyone asks about the old system loses status on day one. They are usually influential and rarely consulted. Recruiting them early converts your most credible potential critic into your most credible champion.
If the honest answer is "it shows up in their numbers", people will protect their numbers by using the old system, and they will be right to. Style is only demonstrated under pressure, so this question has to be answered with a past example, not an intention.
Incentives outrank instructions every time. If a commission structure, SLA or utilisation target is easier to hit through the legacy workflow, that is not resistance; it is the organisation working as designed.
Then write the misalignments down as a short list and decide, for each one, whether you are changing the element, changing the configuration, or accepting a known limit. All three are legitimate. Not deciding is not.
Two Worked Examples
A CRM rollout that stalls at 60%
Systems changed: a modern CRM replaced a spreadsheet and an old database. Everything else did not. Structure still routes discount approval through a regional director who works outside the CRM, so every deal leaves the system halfway through. Staff incentives still pay on closed revenue with no data-quality component, so time spent on record hygiene is unpaid work. Shared values reward individual performance, and the CRM's core benefit is shared visibility — which the best reps experience as giving away an advantage.
None of that is fixable with better training or a longer product tour. Three of the four fixes are organisational: move the approval into the system, add a data component to the incentive, and be explicit that pipeline visibility is now expected rather than optional. Our CRM onboarding guide covers the product-side half.
An HR platform nobody uses twice
Systems changed and the tool is genuinely good. Skills never develops, because an employee touches an HR system a handful of times a year — every visit is effectively a first visit, so no habit forms and nothing is retained between sessions. Style compounds it: managers keep answering questions directly because it is faster than pointing at the portal, which is kind and which permanently removes the reason to learn it.
Here the misalignment is with Skills, and the correct response is not more training — it is to stop requiring skill at all. Guidance has to be present in the product every time, because there is no such thing as an experienced user. Our HR software onboarding guide covers this frequency trap in more depth.
Where 7S Stops Being Useful
- No time dimension. It will hand you four misalignments with no view on which to fix first, or in what order. Pair it with a sequential model for that.
- Nothing outside the organisation. Customers, competitors, regulators and market shifts are all absent. For a customer-facing product that omission is serious.
- The elements overlap. Skills and staff blur, style and shared values blur. Do not spend the workshop arguing about which column something belongs in.
- It is qualitative. Two honest people can audit the same organisation and disagree, so 7S produces a structured conversation rather than a score. Resist the urge to turn it into a RAG dashboard.
The practical consequence is that 7S belongs at two moments — before the programme, to find what will resist it, and after a well-executed programme has underdelivered, to find out why. It is a poor choice for running the work in between, which is what Kotter's eight steps are for.
7S Compared With the Sequential Models
| Model | Type | Question it answers | Use at |
|---|---|---|---|
| McKinsey 7S | Snapshot / diagnostic | Is this organisation internally consistent enough for the change to hold? | Before the programme, and after it disappoints |
| Kotter | Sequence | What do we do next to build momentum? | Throughout the programme |
| Lewin | Shape | Have we planned a beginning and an ending, or only a middle? | When writing the plan |
| ADKAR | Individual diagnostic | What is this specific group missing? | When one team will not move |
| Change curve | Experience | Is this dip normal, and when does it end? | During the post-launch trough |
The pattern worth internalising: 7S is the only one of the five that can tell you the change was never going to work regardless of execution. That is an unpopular finding, which is exactly why it is worth running the audit before the contract is signed rather than after the second wave.
Incentive misalignment has a signature: heavy use of whatever helps someone hit their target, near-zero use of everything else.
Making Misalignment Visible in the Data
A 7S audit is qualitative, but its findings usually have a quantitative signature — which is how you confirm them without another workshop.
- Structure misalignment shows up as workflows abandoned at a consistent step — the one that needs an approval the user cannot give.
- Staff/incentive misalignment shows up as high adoption of the features that help someone hit their target and near-zero adoption of everything else.
- Skills misalignment shows up as long time-to-completion that does not improve with repetition, and repeat visits to the same help content.
- Style misalignment shows up as adoption that varies more between managers than between departments — the sharpest signal in the list, and the least often looked for.
All four require adoption data cut by team and by role rather than an organisation-wide percentage. Our guides to segmentation and feature adoption cover how to set those views up so the comparison is honest.
Configure for the organisation you actually have
Kompassify lets you guide people through the workflows your organisation really uses — tours, checklists, tooltips and in-app announcements built without engineering time — and shows adoption per team, so a misalignment turns up as a flat line rather than as a rumour. Free up to 100 monthly active users, plans from $129/month, GDPR-compliant and EU-hosted.
Start for free →The One-Sentence Version
7S says an organisation only holds a change when all seven elements agree — so when a well-run rollout underdelivers, stop auditing the programme and start listing what the software assumed about your structure, your incentives and your leaders that was never true.
Frequently Asked Questions
What is the McKinsey 7S model?
The McKinsey 7S model is an organisational alignment framework built around seven interdependent elements: strategy, structure, systems, shared values, skills, style and staff. It was developed at McKinsey in the late 1970s by Tom Peters, Robert Waterman and colleagues. Its central claim is that an organisation performs well only when all seven are aligned with each other, and that changing one in isolation produces no lasting result because the other six pull it back. Unlike step models, it is a diagnostic rather than a sequence — it tells you what is out of alignment, not what to do on Monday.
What are the 7 elements of the McKinsey 7S framework?
Three hard elements: strategy (how you intend to win), structure (who reports to whom and who decides), and systems (the processes and tools people use daily). Four soft elements: shared values (what the organisation actually rewards and believes), skills (what the organisation is genuinely good at), style (how leaders behave, especially under pressure), and staff (who is there, and how they are recruited, developed and rewarded). Shared values sits in the centre because it holds the other six together.
What is the difference between hard and soft elements in 7S?
Hard elements — strategy, structure and systems — are documented, visible and can be changed by decision. Soft elements — shared values, skills, style and staff — are cultural and behavioural, harder to describe and impossible to change by announcement. The practical significance for software rollouts is that a new tool is a change to exactly one hard element. It goes live overnight while all four soft elements lag by months, and it is that gap, not the tool, that most stalled rollouts are actually experiencing.
How do you use the 7S model for a software rollout?
Use it as a pre-launch alignment audit and again as a post-launch diagnostic. For each of the seven elements, ask what the new system assumes about it and whether that is currently true. A workflow tool that assumes decisions are made by the person doing the work is misaligned with a structure that requires two approvals. A collaborative platform is misaligned with a style that punishes visible mistakes. Wherever the assumption is false, either change that element or change the configuration — deploying anyway and calling the result resistance is the failure mode the model exists to prevent.
Why is shared values at the centre of the model?
Because shared values determine what the other six elements settle into over time. Structure can be redrawn and systems replaced, but if what the organisation genuinely rewards is unchanged, behaviour reverts to whatever the reward favours. In practice this means comparing stated values with observable ones: the values in the new system's design are the ones on the poster, and the values that determine adoption are the ones visible in who gets promoted and which numbers are reviewed each month.
What are the limitations of the McKinsey 7S model?
It has no time dimension and no sequence, so it will tell you that four elements are misaligned without any view on which to address first. It ignores anything outside the organisation — customers, competitors, regulation — which for a customer-facing product is a significant omission. The elements are also somewhat arbitrary and overlapping; skills and staff in particular blur. And it is qualitative, so two people can audit the same organisation and disagree. It works best as a structured conversation, not as a scoring exercise.
How does 7S differ from Kotter's 8-step model?
Kotter is a sequence and 7S is a snapshot. Kotter tells you what to do next to build momentum for a change; 7S tells you whether the organisation is internally consistent enough for the change to hold. They answer different questions and are often used together: 7S before the programme starts to find what will resist it, Kotter to run the programme, and 7S again when a well-executed programme has still not produced adoption.
Can 7S be applied to a customer-facing product rather than an internal rollout?
Yes, applied to the customer's organisation rather than your own, which is what enterprise onboarding teams are doing informally when they ask about approval chains and internal champions. A product that assumes self-serve adoption will underperform in a customer whose structure routes every configuration change through IT, and the fix is a different rollout design rather than a better product tour. The model's blind spot — that it ignores the world outside the organisation — matters more in this context, so pair it with something that accounts for the market.