This is a re-post of a previous blog that I have had to trash because it was attracting a stream of spam.  If you have read it before – my apologies.

In a recent workshop, we were working on operating models for four parts of the business. It was only a two-day workshop so we had to keep our work at quite a high level. This involved drawing pictures of the operating model, and then picking out different aspects, such as organisation structure or information systems or core processes and doing some work on them. We also used some good tools to stimulate creative thinking: to get people to think out of the box.

The workshop generated huge energy and interest partly because participants could see both how siloed the company had become and how complex it was. Big themes like smarter, more connected and simpler were being championed. And there were lots of individuals with new ideas about how to review their own areas of responsibility.

One of the issues that came up was about when to get into the grinding detail of process mapping and data architecture and so on. Should the high-level operating model be agreed before work is attempted on lower levels of detail? This seems like the obvious answer; but my own experience is that it is more complex.

I found that the sessions where we delved down into the detail on a particular process – for example reviewing the process using the IDEA tool (increase, decrease, eliminate, add) or the ASIAA tool (aggregate, standardise, integrate, arbitrage, adapt) – were the ones that generated the most radical new insights. These insights had the potential to change the high-level design. So my conclusion is that you need to work at the problem from both ends. You need to identify some areas of detail to delve into, then step back and look at the big picture, then dive into some more detail, etc.

One way to do this is to have multiple teams working simultaneously – simultaneous design!