Have you ever seen a program* that did a lot of things but didn't really move the needle? I'm...
Is it just you? The program has started, everyone knows there is a big change coming (maybe, probably, if it works, unless I keep my head down) but the future looks a bit... fuzzy. Everyone else seems to know exactly how things will work, but they seem to all be saying slightly different things... Spoiler alert: it's not just you and there is something you can do about it.
- We are merging the companies
- We are implementing a cloud platform
- We are consolidating the support functions
- We are setting up a new sales process
- We are leveraging strategic insights powered by AI across the business
- We are transforming to place the customer at the heart of our operations
Wouldn't it be wonderful to see a comprehensive picture of how things will work after these changes?
Every stakeholder, whatever their role in the organization, wants to know how will things be different when you've finished, and the program needs to know it, so it can plan all the work to make the necessary changes.
- CxOs need confidence that the disruption and spend is taking the organization to the right place
- Leaders at all levels need to know where we are going so they can support the change
- Business operations need to know how the new ways are going to join up so they can run the business
- The program team needs to plan and execute the work and support the transition
In my last post, I talked about how a Benefits Map can help to connect why you are doing something with what you are doing, and I alluded to another tool: the Target Operating Model. These two tools are a key part of my ethos to apply effort early on in the life cycle of your initiative to clarify what needs to be done to get the intended results. This approach is underpinned by the best practice articulated in the Managing Successful Programmes framework.
The Target Operating Model helps you build a picture of how the organization will be when you've finished your program. You might also hear the term "Blueprint". It prompts you to think across roles and responsibilities, culture, business processes, technology, infrastructure, information (data) and learning.
It is human nature to focus on building new capabilities, but this checklist will help the you to identify what is needed to move the whole organization to new ways of working successfully. If this part of the definition is skipped then programs tend to implement unused capabilities and have to belatedly take corrective actions to drive adoption and fill missing process gaps.
Make building the Target Operating Model a group activity involving stakeholders from your program, and external specialists when needed. That way you will get the inputs to create a robust understanding of how the organization will run in its to-be state, with fewer nasty surprises later on. As ever, involving the right stakeholders in this activity will also help to build support for the planned changes and create a feeling of ownership within people in the organization, rather than a feeling of having something done to to them.
The Target Operating Model describes how the organization will run in the future. As you build it, free yourself from thinking about how you are going to get there. For example, if you are consolidating the support function, you might identify that you now need a Process for people to request support and there might be a Cultural threat to that as people are used to the existing arrangements. Don't worry at this stage how you will provide the Process and deal with the Culture change. Just capture it... then plan your actions later.
Let's review the checklist. Firstly, here's an aide-memoire. If we arrange the headings in the right order we get the acronym "POLITIC". I was quite pleased with that.
| Process | Business processes that will be running. Include KPI concepts. Don't forget supporting processes like policy definitions you will need |
| Organization | Who is responsible for what? What staffing levels do they need? What skills will they need to have? Remember you might need to change the organization |
| Learning and Knowledge | How will people know what to do? How will they have been trained, for change and on an ongoing basis? Where should they find training and reference material? |
| Information and Data | What information do you need to manage the new way of working? It might be helpful to think about guard-bands here, e.g. how do you know a process is working properly, or how are the benefits coming along? How will you monitor if Risks are occurring? |
| Technology | IT systems and other tools you need |
| Infrastructure | Buildings, office space, transport links. Physical things |
| Culture | What are the values and ways of working of the to-be organization? What does the gap look like when we compare with today? Might there be some issues to overcome? Remember Peter Drucker's quote about Culture and strategy |
As you go through the checklist capture what happens today (as-is state) as well as the desired future state - the to-be state. Do this in separate columns in your document as this makes it possible to see the change. The difference between the two columns is the gap between the as-is and to-be operating model.
>> All those changes? That's the work your program needs to make happen. Those are your projects. <<
It might look like a lot to do up front when you are itching to get going, but it is better than delivering the technology and then wondering why no-one uses it, or, worse, having to firefight issues stemming from foreseeable gaps. Start at a high level and go deeper as you need. Even a light pass through these seven prompts is better than going deep on the capability parts and skating over the rest.
Try it today! It will either prompt some new thoughts or enhance your confidence in your existing approach. Both are useful.
Please reach out to me at fieldenablement.com or LinkedIn to explore more about this approach or my services.
Gareth.
