I have realised over the years that the flow charts we put together to describe the work steps of a design project, which look very neat, dovetail into each other and make all kinds of rational logic, don’t describe what happens.

So let me have a go at describing what happens.   First, there is a brief from the “client”: the person who wants some change or improvement.   Part of the brief is about what is important, part is about the history and the journey to today, part is about the stakeholders, part is about constraints, and so on.   I have learnt not to try to get all this in one briefing but rather to have a check list of things I need to know, and pick up the missing bits early in the assignment.   So the “briefing” work step often spans the whole of the first week or month of the project.

But, after the first meeting, stuff starts to happen in one’s brain or amongst the team.   A view starts to form about what the problem is and what sort of solution is likely to emerge.   This is dangerous work.  Every work plan will say do the diagnostic before coming up with solutions.  But the human brain does not work like that.  In fact, the brain often does not really understand the problem without thinking about it in terms of a solution.  “Oh, I see what we are talking about.  We are trying to decide whether to create a shared services division or not.”

I like to log these early solution ideas – in part as a guide as I go through the rest of the project.  If I start getting towards the end of the project and I find that I have not re-framed the brief – in other words come up with a very different understanding of the problem or the solution than I had immediately after the briefing – I start to worry.    In my experience the best solutions to complex problems are non-obvious ones: in part because the obvious ones have already been tried or rejected. But I also try keep the rush to solutions at bay by focusing on design principles (see earlier blog on how to create good ones).  In fact, one of the things I like to do following a briefing is to extract from it anything that I think is a design principle.  Part of the on-going briefing is about putting these emerging design principles in front of the stakeholders to get their reactions.

Following the briefing, there is a period of diagnostic or “immersion”.   There are a couple of things going on here.  There is a need to get one’s arms around the context: to know enough about everything to know what is in the box and what is outside it.  Interviews with all sorts of different stakeholders.   Discussions about what goes on in all the different departments and so on.   This phase can be structured around a “databook” or it can be a looser process of following ones nose.   The latter is best for insight generation.  The former is normally more useful for documenting conclusions.   Sometimes, it is possible to do both.  Have part of the team complete a databook and the other part wander around talking to people.

A critical judgement here is about where to get into more detail (see posts on ‘detailed information’ and ‘going to Gemba’).  You never have time to understand all the detail.  But you must understand some of it.  Customer journey maps and getting close to customers normally pays back.   Getting close to critical employees is also often powerful.

Diagnostic work can go on for ever … and cost your client too much.  So how do you keep it under control?  By focusing on design principles.   As you learn more, you add to your list of design principles or you refine the ones you already have.  When you stop making changes to your list of design principles, you have arrived.

This is the signal for some structured thinking about options and solutions.  Of course this thinking has been going on since day 1, whether you like it or not.  But, it is helpful to have some structured time on options, where you deliberately identify some extremes and deliberately flush out some of the options that lie between the extremes.

Evaluation is supposed to come after option generation.   But in practice these two steps are more iterative.   It is hard to think of a solution without evaluating it, and the process of evaluating one solution often leads directly on to another solution.   So, option generation and evaluation often go along in parallel.   The only time I try to deliberately turn off the evaluation filter is when I am generating ideas for extreme solutions – these nearly always fail the filter, but are useful as boundary markers, for stretching creativity and for challenging the status quo.

Of course evaluation, against design principles and against other challenges, such as ease of execution, is supposed to be a separate step in the process: generate options and then do evaluation.  But, in practice it is much more muddled together.   Also, new design principles emerge at this stage.  In fact it is not uncommon for re-framing to happen during option generation or evaluation:  the problem gets seen in a different light, for example it becomes a problem of customer segmentation rather than one of under performance or it becomes an issue of capability rather than clarity of roles.  When this happens it is helpful to stop and go back to the beginning.

Imagine what you would have done if the original brief had been articulated in this new way: what different stakeholders might you have talked to; what different bits of diagnostic might you have done; has Gemba been defined differently?  Where there are differences you may need to redo parts of the briefing or diagnostic steps and reconsider your list of design principles.

The end of the journey is some agreement by those who are involved that the proposed solution is a good one.  This can only be achieved with face to face discussion and a willingness to adjust the solution to accommodate relevant inputs.  I like to start this step as early as possible, often involving people up front as stakeholders, checking with them the wisdom of the design principles, getting from them their solution ideas, working with them to evaluate solutions, and so on.   But this is time consuming and can distract large amounts of people from more useful work – so a balance is needed (but rarely found!).

At the end of the process you should have a pretty well designed operating model.