Designing Partnerships

On the 27th August, I had the pleasure of presenting at The Mandarin’s event ‘Design for Public Sector Leaders’, hosted by the excellent Mathan Ratinam and Lina Patel.

Alongside presenting some recent work with the Victorian State Department of Premier and Cabinet (DPC), I also participated in a session that discussed design partnerships. The session was designed to give the public service tips, tricks and insights into partnering with designers, and to provide some solutions to common issues around procuring processes (design) rather than solutions (platforms or deliverables).

As a prelude to the panel I was asked to give a short presentation on what I had found to be important to partnerships on my projects. This article is roughly what I presented.

Partnerships are about Trust

Like all good relationships, design partnerships are built on trust, and trust happens two ways.

For a ‘client*’, trust is best built by being open about the real constraints that exist around a project.

Common constraints are budget and timelines. Equally common, but slightly trickier to articulate, might be ‘soft’ constraints, such as directives or special focuses from key stakeholders, go and no-go areas of a business or solution, or the experiences of past attempts to achieve a goal. Each of these shapes projects in different ways — budgets and timelines are clearly important when it comes to deciding how to best achieve the goals of the project, but these softer constraints are equally important in designing an approach. They provide as many clues as to what might work, and what we should do, as dollars and time.

It is not uncommon for few or none of these constraints to be shared as part of a briefing process. For good reason, Governments have strict and appropriate rules around sharing budgets. Timelines are easier to share, but almost always shift. Some of the ‘softer’ constraints I’ve talked about here are harder to articulate, and are sometimes overlooked––not because they’re not seen as important, but because project officers don’t see these as project constraints. They see them as workplace politics.

Designers can build trust on projects by, at first, eliciting these constraints and then understanding them. They need to understand that human-centred design might be seen as a risky process for an organisation. Past projects may not have delivered on their promise, or a design-led approach may be a completely new (and frightening) proposition. Designers valorise the idea of not pre-determining solutions — they should also understand that it’s hard to stump the bill for a better problem.

They need to not be sticklers for process and method, and exercise their expertise to design a way forward through the knottiness and mythology of each unique project.

Strategies for Building Trust

At Paper Giant, we have developed a number of tools, routines and rituals for building trust on projects.

To elicit and understand constraints, we work as closely as we’re able to collaborate on scope and design briefs with clients, not just in response to them. This collaboration involves carefully stepping through all of the possible constraints around a project, including the ‘soft’ ones mentioned above. We take the time to understand past work, what worked and didn’t about those efforts, and what people across the organisation might be expecting (or not) this time.

When we’re not able to uncover this information before a project starts, we begin each project by facilitating a ‘kick-off’ workshop or research interviews where these topics are covered off and discussed, and project plans adjusted in response.

To make sure that we’re staying on track to the expectations, we share regular detailed updates on project progress. This often means presenting ‘work-in-progress’ synthesis, partial answers to research questions, or partial designs. We’ve had clients say that we’re brave for doing that, but we do it because it leads to better results. Clients not only trust us to do good work, they better trust the research or designs we give them.

We also work hard and earnestly to build the capability of the people we work with — we don’t have ‘secret sauce’ beyond our people and experience, and as a principle we share our knowledge generously. We embed with teams, and regularly deliver training modules as part of our project work.

Genuine Partnerships

Partnerships are built on trust, and the best way to build trust is to be open about what you’re dealing with, and why.

I’ll wrap up with some questions:

• How do you build trust on projects?
• What are the best examples of design partnerships from your own careers?

*I use the word ‘client’ to describe the broad range of project officers, managers, working groups and departments that might be involved in a project