Have you ever wondered why some organizations appear to transition to new ways of working after the completion of large projects or programs seamlessly, whilst others struggle and find the experience very disruptive? The answer may well be The Model Office.
When we think about testing we naturally think of testing the deliverables produced by individual products. We also think of testing the combination of these deliverables to test the end-to-end system. It is easy to forget that these deliverables will have a significant impact on ways of working, tools, and processes used within the organization. A Model Office can be used to address this.
The Model Office is a working prototype of operations which reflects the production environment as closely as is practically possible. The Model Office allows us to validate the usefulness and effectiveness of the proposed solution. Participating in the Model Office are key Operations personnel who will ultimately be responsible for using the systems and processes once the execution of the project or program is complete.
The Model Office engages the key personnel involved in the transition at an early stage allowing early feedback on the new system as it is developed. It is also a great way to obtain buy-in from all necessary parties, as it allows us to demonstrate the benefits of the new system to them early on, and enables us to take onboard their feedback early, and thus adjust the solution to meet their needs. In addition it can also allow us to anticipate issues and address them before they arise.
There are a number of benefits to a Model Office including:
In order for the Model Office to be a success it is essential to run it with very clear objectives throughout the duration of the project or program. Here is the process which I use:
The Model Office Planning Phase occurs at the start of program execution. The objective of this phase is to set-up everything necessary to facilitate the Model Office running throughout the duration of the program. This stage will typically contain the following steps:
In the early stages of your project or program it is unlikely much will exist by way to deliverables which can be tested. This does not mean you shouldn’t run the Model Office. Using whatever does exist at this stage (wire-frames, rough notes on new business process), Business Scenario Walkthroughs can be performed.
The purpose of these BSW’s is to walkthrough the business processes even though the software or hardware doesn’t yet exist to test the planned business processes to ensure they are workable. Because no software or hardware exists participants should be asked to role play, using props or just pieces of paper rather than real systems.
This stage starts when the first real deliverable is available to test. In this stage, in addition to performing Business Scenario Walkthroughs we start carrying out Business Simulations. Business Simulations involve using the delivered systems to perform real world tasks to simulate as much as possible the tasks which will happen once the systems are handed over to the Operations team. As much as possible we are trying to simulate the entire business process end-to-end.
At this mid-stage it is probable that only a fraction of the final systems will be available. However, in addition to the systems delivered at this stage, new wire-frames or designs will be available for those parts of systems being delivered next, and we should continue to perform Business Scenario Walkthroughs on these items.
The late stage model office starts when we no longer need to perform Business Scenario Walkthroughs and can solely rely on performing Business Simulations. The purpose of this phase is twofold:
It is a good idea to prepare the final sign-off criteria for Operations, and training plans towards the end of the mid-stage Model Office. Final sign-off means that everyone is confident that the systems being transitioned to the Operations team are fit for purpose and the necessary people know how to use them.
The Model Office is a great way to ensure that systems developed during the project or program transition to operational use smoothly. It is also a great way to gain buy in from those people who will ultimately use the system, as it gets them involved early, adapts the systems based on their feedback, and ultimately gets them to sign-off the systems and processes as fit for purpose.
Unfreeze, Change, Refreeze
Kotter’s 8-Step Change Model
The SIPOC Model
Satir Change Model
Scott and Jaffe’s Change Model
Six Change Approaches
ADKAR Model of Change