It is important to ensure everyone is on the same page and has a clear understanding of the new vision before tackling the detailed design.

In developing a case for change, a vision statement will have been created to enable stakeholders to understand what the change is aiming to achieve. This can be a starting point in confirming the vision.

McKinsey 7S is used as a way to ensure all aspects of a change vision have been considered:

•Will there be a change to the Shared Values of the organisation?

•What is the strategy and plan for the new vision?

•What does the new vision mean for the structure of the organisation?

•What does the vision mean for the systems of the organisation – both the processes and the technology which help deliver them?

•Will the new vision require a new leadership style or culture within the organisation?

•What will staff be expected to do in the new vision?

•What skills will be required for the new vision to achieve its planned outcomes?

Knowing the current ‘as-is’ status of all these aspects is useful input as answering these questions provides a helpful insight into understanding what must be designed in detail.

This stage focuses on designing the change in detail. Every aspect identified as needing change must have clearly defined requirements with an identified solution agreed. It is useful to create a set of design principles or restate design principles if already agreed to help guide design.

For example, a design principle may be empowerment of the individual, or for students to have easy access to services.

For complex projects, especially where there is significant technology change, it is likely that a proportion of design will have been pulled forward into a case for change to help determine a recommended solution. It is also likely that further design will still be needed.

McKinsey 7S can continue to provide a checklist to prompt people to consider all the different elements when designing a change. For example, if a new process is required; who will perform the process, will a new role need to be created, what skills, experience and

training will be required, what does that mean for any supporting technology solution and management information reports, is it in line with the shared values, strategy and leadership style of the organisation?

This step should finish with a set of ‘to-be’ design documents, pictures, process maps – whatever is required to enable the solution to be created.

Performing a gap analysis is crucial to understand what needs to happen to move from the current situation to the new vision.

There are a number of ways to do this from workshops which tackle a side by side comparison of ‘as-is’ and ‘to-be’ or doing a ‘desktop’ exercise with a subject matter expert to confirm the likely impact. Once again, McKinsey 7S provides a useful checklist to determine if all potential impacts have been considered.

The impact is documented into a change impact assessment. This is reviewed with stakeholders and the wider project team to ensure all impacts have been correctly and accurately identified. This can be done in conjunction with step 4.

Planning the change from the current situation to the new situation once the design is known, is vital to the success of the change. It’s a truism but proper planning at this stage prevents poor performance later.

For simple changes, the transition actions will usually be clear and contained. A transition action plan can be drawn up quickly with affected stakeholders and put into motion.

For large complex change it is recommended to run a series of transition or implementation workshops with members of the team who can identify all actions required. The workshops may also consider how long these actions will take, who will do them, and how the specific time (often referred to as the cutover) when the current ways of working stops and the new ways of working starts will happen.

Transition needs to consider a lot of change activity – creating the solution, testing, training and, importantly, the engagement and communication to help create understanding of what will be the future and how people can play a part.

• A short vision statement (if one has already not been done).

• Gather existing ‘as-is’ documentation together – it is not advised to create ‘as-is’ if it does not exist as this is typically wasted effort.

• ‘To-be’ design documentation will be created including process maps, functional requirement documents, etc. depending on the type of change being proposed.

• A Training Needs Analysis and Training Approach

• A Change Impact Assessment

• Detailed implementation and transition plans