Plan ahead

Often on IT-led programmes , the need for a TOM is appreciated too late. We’ve joined many programmes heading into testing and training, not exactly sure what to test or train. Programmes  often cut the design phase short, trusting their business representatives to put the new processes in place without lots of documentation.

By defining a TOM up front, you will be sure to achieve the stated outcomes, and your teams will know what changes they need to make. The TOM needs to be simple, clear and easy to understand.

Meet TOM

TOMs define how the organisation  will operate after the change is complete.

While business representatives are usually knowledgeable about their process areas, the touchpoints between functions are less obvious. Developing a TOM also gives the organisation a structured approach to work through these touchpoints and core business scenarios so it can understand how it will operate when the initiative goes live.

Our favourite  framework for a TOM breaks it down into four components:

• Solution
• Processes
• Organisation structure
• Skills and capabilities

Simply put, to design a new way of working, you need to design each of these components and how they interact. The objective of the documentation is to align the programme  team and wider business to prepare for the change. Really, the TOM is a communication tool. If everyone has a shared understanding of the TOM, that alignment is easier to establish and ultimately easier to implement.

T stands for Target

We’ve seen some programme teams struggle to know what that target is. This can be due to a lack of vision from the business or the volume of change in the organisation . The TOM documents the business design needed to deliver the stated benefits and govern the programme’s delivery. During the design, any risks, issues, assumptions and dependencies are circulated throughout the wider business to gather the support needed to address any gaps in direction.

TOM sets the scene

A TOM defines the new ways of working for the parts of the business that are changing. One of the first steps in developing a TOM is to define the scope of the processes that are changing, often against the value chain (the end-to-end processes needed to run the operations). It’s critical that the business defines the processes needed to run the organisation  in the language that they use to talk about them, so that everyone buys into the value chain.

The value chain should cover all the operational activities. So, when the value chain is marked with the programme scope, the organisation  clearly knows what is in and out of scope.

TOM speaks the LANGUAGE OF BUSINESS AND TECHNOLOGY

Just as the value chain needs to be in business language, so do the process maps. All too often, we’ve seen IT-led initiatives produce systems process maps, not business process maps. A business user should be able to read a process map and understand how they will carry out the process, the roles and systems involved and which parts of the process they support. The process maps should provide IT with the business context for how the technology will be used.

TOM is a team player

Large organisations are generally siloed and some of them replicate this way of working on their programme  teams. These teams produce process maps whose touchpoints have not been worked through or, even worse, processes for just one or two functions. The function owning a process map needs to agree all the steps they have defined with ALL the other functions involved in the process. Along the same lines, a TOM cannot be defined for one function in isolation of the others. Each function depends on the others for inputs and outputs and the other functions need to sign up to provide them.

TOM will save you time

Once you have developed a TOM, developing the next one is that much easier. Recently, we worked on a project with a team who had just completed a Transformation. In the course of our work together, we were impressed with how well the team knew their business processes and the touchpoints with their colleagues’ processes. The design work that usually takes four to five months took only two. Since the team already had established relationships with the business, open questions were quickly answered via text or email. Here, the design work from the earlier Transformation established the foundation for the current one.

Check in with TOM

If you want to start realising  the benefits TOM could provide, you can use the following criteria to check if yours is on the right track:

• Senior sponsorship: Has your senior leadership team bought into developing a TOM? Are they clear on the approach and their role?
• Process scope: Has the business defined a value chain for your organisation ? Has it been used to define the scope of your initiative?
• Programme vision and key changes: Is the programme’s vision clear? Does the team and business know the changes the programme will be delivering?

The process of developing a TOM will align your organisation on the coming change. TOM will help the business own and embed your current initiative and establish a repeatable way of landing your next. So why not make friends with TOM?