‘You can’t always get what you want…’

In 1969 Mick Jagger was obviously talking about output specifications, says Steve Gale.

When Carillion recently imploded, the talk about PPP involvement brought back memories of my own brush with PFI, as it used to be called, which stood for ‘private finance initiative’. The one huge lesson I took away was how the public sector tried to define its requirements in a way that encouraged the market to bring innovation into their allegedly ossified practices.

Whatever you think of this theology, it has a great founding principle of the ‘output specification’, which defines how requirements are captured and expressed. The principle is quite easy to explain, but surprisingly hard to put into practice. I will try to explain why it is actually difficult to do.

A few years back, the government needed a new Home Office HQ, and three weeks into the project I joined a team to write a brief for it. At my first big meeting, the civil servants delivered a sermon on how we must produce an output specification and what the simple rules were. I drank all this in because it was genuinely new to me, and it sounded a great idea, and others around the table took the opportunity to add their take on it. This was going to be more interesting than I had expected.

The second part of this long day was a review of the first draft of an engineering specification. The project was just three weeks old, but already there was a weighty document, stiff with prescriptions for air changes, temperature control, relative humidity, lighting levels and colour temperatures.

But surely this was the exact opposite of what was required for an output specification? I was the new kid, I was not comfortable standing up, pointing out the elephant in the room. But it was indeed the exact opposite, and we spent many weeks refocusing on what was really being asked for.

Why was this so hard? Why did intelligent, seasoned, technical professionals have such a problem with the output specification? An output is the opposite of an input. An example of an output would be a desire for your village to have improved access to another village on the opposite bank of a river. The input to achieve this might be a tunnel, a ferry, a bridge or even some virtual communication, depending on the detail in the request. But the desired output is better access. The requirement is not a bridge, which as an input is just one potential way to meet the need.

Closer to home, we can see the big difference between a request for accommodating a tech business of 300 people (output), versus a specification for 35,000 sq ft with 300 desks, 10 8-person meeting rooms and a kitchenette with space for 45 people seated at one time (input!).

The difference is clear when you look at it, but back in PFI land we all found that outputs were devilishly hard to define. The architects and engineers were not best qualified to write the output requirements, it was really a client task – only they knew what they needed. But specifications were traditionally technical documents, so wheel in some architects.

We found that, because design and engineering people had spent their entire professional lives defining inputs, it was not possible to suddenly drop all this training and wear a completely different hat.

This lesson is just as relevant now when we ask a client what they need. They might easily think they are being asked for a list of components and facilities to support their business, whereas in fact they need to express the bits that we, the designers, do not know about. We already understand buildings and how to arrange them, it’s our day job, whereas only the client knows about his business and where he would like it to be in the future.

‘You can’t always get what you want, but if you try, sometimes you just might find you get what you need’. Thanks Mick, glad you agree on that.

Steve Gale is Head of Business Intelligence at M Moser Associates. SteveG@mmoser.com