I am in the middle of designing a course on Operating Model Design for a client. So I have been observing my behaviour. I understand what the client wants, but there are lots of ways of achieving the end result. How have I been doing the design work.

Some of the design principles or constraints are things like – 2 days, 19 people, 4 internal projects to be discussed hence lots of break-out sessions, no overnight work because participants will be going home, etc.

Rather than go at the problem top down – strategy, design principles, options, evaluation – I have found that I have gone about it top-down and bottom-up. So, yes I have spent time getting clear about the strategy: what this event is expected to achieve for each of the stakeholders. But I have also been focusing on the core sessions that I think will prove critical – the break out sessions. By laying out all the possible break-out sessions, I concluded that, the first design choice would be to decide which of ten possible break-out sessions to run. Having chosen 5-7 sessions, I then worked out the optimum amount of time for each session. This required defining what the break-out task should be, how much time would be needed in plenary and how much input would be needed to brief the session. This process helped me realise that we only had time for six break-out sessions.

With this back bone of break out sessions, I then began to design other sessions around them. Obviously the introductory sessions at the start, but also linking sessions, change of pace sessions and sessions involving switches of media.

The bottom-up design was then challenged against the top down objectives and against my knowledge of what makes for a good event. The final step will be to have the design challenged by the client.

If I had had access to participants, I would, of course have called three or four in order to understand their expectations and needs. These have been relayed to me by the client, so I am working with second hand data – always dangerous when doing design work.

Conclusion: Design involves top-down and bottom-up approaches. It is often necessary to design the details of critical components before finalising the overall design. Judging which details need to be designed early is the key.

Post script: I once worked on designing a matrix structure. I knew that the structure would only work well if there was a good process for linking product developers with markets. But, I failed to insist that this process was designed before the matrix structure was finalised. As a result, the new matrix structure was implemented without the critical linking process. Performance dropped, the company was acquired and most of the top managers were asked to leave. A pretty bad outcome for a design process mistake.