Skip to main content

Getting the right supplier: out with specification documents, in with user needs

Posted by: , Posted on: - Categories: Agile, Case studies, User research infrastructure

I’ve been working with GDS for several years now. I’ve researched, negotiated, procured and delivered several services for GDS, including a user research lab, an A/V library pilot and – currently in progress – a user research panel.

At GDS we talk a lot about user needs. GDS was my first, truly agile and user-centred work environment. It would be no understatement to say that I’ve learned more in the past few years, at least regarding user research and service delivery, than I’d hoped to have learned in a lifetime.

Having said that, I’m almost embarrassed to say that it’s taken me several years, and as many projects, to realise that it’s vastly better to procure a supplier using a list of user needs than a specification document

If we’re doing user-centred and agile service delivery, then getting the right supplier should be both agile and focused on user needs too. Doh.

Still, I’m told (and I’ve experienced) that procurement via a specification document is pretty standard practice across government. So, I’m not alone. And perhaps, in finally seeing the light, I’m even ahead of the pack.

How potential suppliers reacted to a list of user needs

Out of six potential suppliers, four completely ignored the list of user needs. These suppliers instead pressed for either a specification document, or upfront budget so that they could workshop and create a specification document for us.

They didn’t have the interest or patience to respond to user needs. They simply wanted to estimate, sign-up and deliver the thing that we asked for.

The thing is, because we didn’t really know what we wanted, we needed to build something simple based on our understanding of user needs, so that we could start to learn more about what would and wouldn't work. That’s how agile goes.

Furthermore, because we didn’t know what each CRM platform could deliver out the box, or through customisation, we couldn’t realistically write a specification document.

In short, we needed and wanted to work with a supplier who was truly agile. If a list of user needs scared them off, the relationship was unlikely to work in the long term.

Call it supplier speed dating.

What suppliers say they are versus what they actually are

A lot of suppliers, especially in government, say they’re agile. Considering the current environment, it’s good marketing. But ask them to respond to a list of user needs from the outset, and it doesn’t take long to find out whether they mean it or not.

I don’t think it’s a problem of process or procurement fears, I think it’s an issue of work style and attitude. Some people think and work agile. Others think they do, but don’t.

The two suppliers who got it and what worked well

There were two suppliers who responded well to a list of user needs. Their proposals showed us which user needs could be addressed ‘out the box’, which would need light customisation, and which would require heavier investment.

This allowed us to loosely plan a first phase, second phase, and so on. We could confidently ask for a low-risk start up budget, and another fairly well estimated pot of money to cover reasonable customisations as our needs became clear in the long run.

In delivering a list of user needs to suppliers, this is what worked well:

  1. I used a spreadsheet to list user needs. This allowed the supplier to add columns and comments, and filter by user, task, priority and so on. Very useful.
  2. Each supplier received a unique Google Sheets spreadsheet, with their name in the header. The suppliers commented that this immediately let them know that the document was theirs to edit. It gave them ownership.
  3. The spreadsheet made it easy to reference specific user needs in conversation and in proposals. As in, “User need, line 25”.
  4. To my surprise, the spreadsheet became an official record of what the supplier would deliver and was referenced in both the supplier’s proposal and GDS’s procurement call off contract. It became more than just a working document but a legitimate part of the contracting process.

Image of a spreadsheet of user needs. For example, As a researcher, I need to see how many people clicked on an email/form so I can learn how effective my communication was.

No more specification documents for me

All said and done, I don’t think I’ll procure using a specification document ever again. Procuring suppliers should be user-centred and agile too.

If you've had experience with user needs and procurement, drop a comment. It's always useful to compare notes.

Keep in touch. Sign up to email updates from this blogFollow Kate on Twitter.

Sharing and comments

Share this page