The 7-S framework (+2) for evaluating change readiness

I recently explained the “Arenas of Change”  approach that I often use to understand a team and its environment. So I thought it might be a good time to discuss another approach that I often use – the 7-S framework developed by McKinsey Consulting.

For a proper explanation of the approach and its use and background, it is probably best to go to the source, so this link will take you to an explanation by Mckinsey themselves:

https://www.mckinseyquarterly.com/Enduring_ideas_The_7-S_Framework_2123

The way I use it is slightly simplified and slightly adapted to the work I do.

Essentially I just use the framework as a set of headings to provide me with questions to ask and ways to connect the answers. Each “S” is a set of questions around a topic such as “Strategy”. Then once you have the answers you compare each category to the others to see how they connect to each other (support, inhibit, etc). For example, you might find a clash between the Structure of the team and the Style (culture, decision making approach, leadership style).

The framework, as I use it, consists of asking questions around the following topics:

1. Super-ordinate goal
   1. What is the value proposition for the team?  Why does it exist?
   2. For a project – what is the overarching goal or outcome we are looking to achieve? 
2. Strategy
   1. How do you intend to achieve your goals?
   2. Do you have a 20/60/180 day plan?
   3. What plans do you have around succession planning and capability growth?
   4. How do you implement projects?
   5. What short-term goals, deliverables are you working on?
3. Skills
   1. What capabilities exist within the team?
   2. What capabilities will be needed for my project to work?
   3. Do people understand the systems they need to use? How?
   4. What capabilities might become less important if my project works?
   5. Where is the gap?
4. Staff
   1. Who is in the team?
   2. Who do they work for? What other teams are they in?
   3. What are they like?
   4. What do they do? What don’t they do?
   5. Who performs what role? What happens when they are not around?
   6. How do they relate together?
5. Style
   1. (This is where I often use the Arenas of Change).
   2. What leadership style(s) exist in the team?
   3. How are decisions made and communicated in the team?
   4. How is conflict handled?
   5. How do people go about getting things done?
6. Structure
   1. What structure exists in the team?
   2. What roles exist in the team? How are these determined (based on team skills and preferences, based on team services, based on corporate structure)?
   3. Who does the team report to? Are they part of a wider group?
   4. What vendors, partners and internal teams contribute to the team?
7. Systems
   1. What processes exist? (Often, a couple of value stream maps or swim-lane diagrams help here. Otherwise it is sometimes useful to use a standard checklist. For example you might use TOGAF, ITIL or COBIT for an IT team even if they don’t use that approach) What IT systems exist?
   2. What informal approaches do people use to get things done?
   3. What would happen in a disaster, emergency or panic situation?
   4. How do the different systems (processes, approaches, tools, applications) integrate?
   5. How do things get done? What really happens when the pressure is on?

Then I always add my “+1” category of Risks. 

I have a number of approaches to investigating risks in more detail, ranging from just asking “what scares you” to a full-on set of models like fault-trees and “failure mode and effect” tables. You can see some of these by browsing through the Risk category on my blog.  But for the purpose of this article you could simply ask about RAIDS:

• What risks does the team face? What could happen that is relevant to our project?
• What near misses has the team had recently?
• What, if it went wrong, would be really bad?
• What should never happen, but always seems to?
• What issues exist?
• What assumptions are we making? What should be true, that might not be?
• What are we depending on for this to all come together? Or what resources, contracts etc is the team dependent on for success?

Finally, I add my “+2” – rewards and recognition. This one is really covered in Systems and Staff, but I like to separate it out to remind myself to focus on it:

• How are staff recognised and promoted?
• What behaviours and tasks are seen as praiseworthy by the team? By management?
• What factors are salary, contract rates and bonuses based on (eg job titles, size of team, specific skills, length of service)?
• What is measured in annual performance reviews? Who performs them? Who has input?
• What have employees been recognised for in the past year? Have any special awards been presented, and if so, for what?

While the Arenas of Change is a good approach to assessing the culture and political environment of the team, the 7-S framework attempts to gain a more strategic and systemic view.

All this might seem pretty complex, but when I am performing a 2 week discovery phase on a project, I find that this sort of approach provides a really useful structure to my analysis. And in smaller assignments (say a couple of hours) then you can still get a feel for some of the information.

All of these questions bring together a great amount of information, but what do you do with it all?

I actually run a course in gathering and using all this information to plan and communicate change in your organisation so let me know if you are interested, and I will also try to make it the subject of another couple of articles in this blog.