I recently had an interesting conversation with Tom Cummins of PA Consulting about design governance.  He is doing some research on different approaches to design governance with the idea of creating a framework for helping organisations choose an appropriate and cost-effective governance approach for each design project. 

I pointed out that the jargon (“governance”, “operating models”, “design principles”, etc) that we use when we are thinking about or researching these issues often gets in the way of clear thinking. 

So first, what do we mean by governance.  We mean who makes the decisions and how we make sure that different decisions makers coordinate so that the whole design is aligned with the purpose, strategy and financial constraints of the organisation. We also mean how we resolve differences of opinion or clashes between different designers or design teams. 

Both Tom and I recognise that design work often goes wrong in organisations because different design teams – for example, the Finance team and the IT team or the North American team and the European team – have different design ideas and fail to coordinate well.  They make their own design decisions judging what the organisation needs from their own perspective.  This can result in hard to resolve conflicts or a design that does not fit well together.

I often find it useful to use a non-business example, but one we are all familiar with, to help me think about these issues.  So lets take the example of designing a house.  Lets assume we have five separate design teams: foundations; structure and room layout; plumbing and heating; electricals, sound system and wifi; and decoration.  We can easily see that, without coordination between these teams, the resulting house is likely to be a bit of a camel.

How is this every day problem solved?  First there are the clients for whom the house is being built.  Whenever there are difficult issues, they can be presented to the clients.  Lets assume the clients are husband and wife, and lets assume they do not always agree: the husband holds the financial controls and the wife has strong views about what she wants (or the other way around). 

In this case, the “design authority” is the husband-and-wife team.  Each of the design teams working for them should be careful about making design decisions without checking back with the “design authority”.   To help them, the husband-and-wife team will typically employ a building architect.   This person takes all of their desires and converts them into a blueprint.  He or she then takes the overall blueprint to each of the design teams and asks them to think about how to design and cost the details in their area of responsibility.  Inevitably issues come up not just about coordination, say between the foundations team and the plumbing team, but also about the practicality of the blueprint (e.g. the plumbing team may ask for a wall to be moved to give space for the boiler).  The architect, who is ideally someone who understands the challenges in each of the specialist areas, (something that the husband-and-wife team typically do not), takes all of the issues raised, tries to develop solutions and thinks through whether any of the solutions will be a problem given the expressed requirements  of the husband and wife.  The architect is a crucial conduit between the design teams and the design authority.

The architect makes it possible for the husband-and-wife team to make design decisions even though they do not fully understand the challenges facing the specialist design teams and even if they do not agree.   If the husband-and-wife team do understand all the challenges, have aligned views about what they want and have time to devote to resolving all the issues, possibly doing some of the detailed design themselves, they do not need an architect.   So, some houses are built without architects.  Also, in some cases, one of the specialist design teams, such as the “structure” team, takes responsibility for coordinating with all the other teams and with the client.  Often the architect does the structure design, hence is one of the specialist teams coordinating all the others.

So now lets apply our jargon to this situation.   The blueprint is a high-level “operating model”.  The detailed designs for plumbing or decoration are “detailed operating models” for these areas.   The governance process consists of the husband-and-wife team, the architect and the design teams in each specialist area along with some rules of engagement.  Example rules of engagement might be “the architect will share progress with the client at least once a week”,  “the specialist design teams will not make any design decisions that conflict with the blueprint without checking with the architect”, “the architect will arrange a meeting between all the design teams to share their design ideas every week”, etc

“Design principles and design guidelines” are mechanisms that any or all of the participants can use to help get alignment, for example between husband and wife or between the husband-and-wife team and the architect.  In fact, the blueprint can be considered to be a set of design guidelines for the specialist design teams (in other words a high-level operating model is a set of design principles for lower-level operating models).

So, what do we learn from this example about design governance.

There are some elements of the situation that we need to understand before we choose our governance mechanisms and processes.

1. How clear is the “client” about what is wanted and how aligned is the “client” on what is wanted.   Since the client is often the executive team, clarity and alignment are hard to get (in my experience).  If the client is the head of the organisation and he or she is clear and is prepared to impose alignment, the governance is easier.  Design principles, design meetings and blueprints are often used to help get clarity and alignment.
2. How experienced is the client in understanding design challenges and developing design solutions across different specialisms?   In most cases the client does not have the necessary experience or does not have the time.  Hence a designer/architect is needed who does most of this work for the client.  This person must have deep understanding of all the specialisms, plenty of time to work on the problems that arise and the full confidence of the client.  Very few “transformation leaders” or “project leaders” have these three requirements.
3. How many specialisms are involved and how often have those involved worked together, before, on this kind of a design project?   The smaller the number and the greater their familiarity with each other, the more informal the governance processes can be.
4. What time and cost constraints exist that might call for lighter touch, rather than heavier touch, governance.

Design projects in my experience go wrong because the governance is not designed to take account of the situation: the number of different political groups who need to collaborate, how much experience they have had with design work, how often they have worked together on projects like this, the degree of alignment about what is wanted at the level where the different groups have a common boss, the capability of project or transformation leaders, and the time and cost constraints. Leaders too often set up standard governance processes, without thinking through the challenges that the governance should be designed to solve.