Find out who your users are (it will make procurement better)

I recently wrote about why ‘Procurement needs to be part of the multi-disciplinary team’ (Chapter 1). Some people liked this and asked me to write some more stuff about my experience as a public sector procurement person, so here goes.

Let’s just call them users

I want to share my experience of how I understand my users (the people that use my procurement service). In procurement we are taught to call them: clients, internal customers, consumers, stakeholders.

Confused already?

Let’s just call them users.

Types of people

Understanding the people you work with enables you to tailor the service you are providing to them. This makes procurement better. Many procurement teams have a standard service level agreement (SLA) for engaging with users and frankly this just doesn’t work (for complex/non-commoditised procurement projects).

Examples of this include:

- procurement cannot engage with the users until they (the users) have their requirement sorted (procurement can add value here so I get involved in this stage as early as possible)

- procurement wont engage until the business case is signed-off (this is where a procurement person can add value too)

- the procurement activity isn’t on the pipeline/tracker so the procurement function wont assign a procurement person to the project.

What makes the various users tick

When I start a new project my number one priority is to understand my users. Whenever I meet a new user from the project I ask them to prioritise (list in order of importance to them individually) the 8 subjects below. This is the first stage in me working out who my users are.

- Governance: I need to understand their appetite to follow governance. The user may follow governance to the nth degree. They might not do this at all. There could be various reasons for this - they don’t understand it, it doesn’t work for the specific project, or it is contradictory to other policies. By understanding the reasons I can make the procurement activity easier for the user.

- Regulation: This is different to governance. This is about procurement rules (The Public Contracts Regulations). Is following these important to the users. We all know it should be but like the above (Governance) understanding the appetite to follow The Regulations enables me to personalise my approach to the specific procurement.

- Savings: This is important in any organisation let alone the public sector. However, sometimes, for some users, this will be a secondary priority to delivery. It helps me to know the users views on savings.

- Budget: I see so many times projects ploughing ahead without budget set/approved. Sometimes there are genuine reasons for this. But knowing the importance the user puts on ‘budget’ enables me to make the procurement activity as frictionless as possible.

- Delivery: This is always on the users priority list. Well that’s what most of the users of a procurement service are about: delivering stuff.

- Reputation: This is often on the users priority list as well. The user of procurement services is most often closer (than the procurement function) to external facing groups (public, media, wider public sector, suppliers, etc). By understanding how the user feels about reputation enables me to control the communications regarding procurement (most communications are covered by The Public Contracts Regulations).

- Market: I like to know the users priority regarding the market. The user may have a view on the current market, market creation, and future market developments.

- Supply: There are various elements to supply. By understanding the importance of supply to the user enables me as a procurement person to ensure the user gets what they need to do the things they are required to deliver.

Have you ever done an OJEU

I then ask the following 5 questions:

- have you ever “done an OJEU (Official Journal of the European Union)?”

- do you know how a framework agreement works?

- how do you feel about intellectual property rights and exit clauses?

- what is the market like for this work?

- can you get good value out of this supply relationship?

Asking these gives me a good understanding of my users procurement, contractual and market knowledge. I do all this before I start working on the project. This provides me with insight to how our relationship will work and what I might have to do:

- influence their thinking

- educate them about procurement

- help stimulate the market

- explain the plethora of procurement processes

- buy in external legal support

- think about contract management

the list does go on.

I now know the various types of personalities, skillsets, experiences and appetites I will be working with. I have formed user groups, which I refer to as procurement personas.

Personas

On a previous project we defined the users personas on a scale of 1 – 10 (with 1 being lowest). The subjects were:

- subject to be delivered, including market

- procurement

- contracts

- risk appetite

- savings targets.

All 25 people on the project had a mix of scores. Some scored high for subject knowledge and low for procurement knowledge. Others had strong contract knowledge, medium procurement knowledge, but had a very enthusiastic style towards risk.

This was a true multi-disciplinary team. This team delivered its things quicker as we tailored the procurement activities to the personas involved.

Don’t do what I did

When I first got into procurement (erm, how did that happen I often ask), I thought all of my users needed to know everything about procurement.

I would recite the Public Contracts Regulations, explain how a contract works, describe contract management techniques, etc.

On reflection, I could see the users nodding off and disengaging. I was failing to deliver an efficient service.

By understanding your users you will keep the procurement conversations relevant to both the user audience and the topic in hand. Your users will also learn.

Users – why bother understanding them

It is simple, it enhances collaboration.

The more I’ve got to know the users the more I’ve got to understand how they work. But more importantly, why they do certain things.

This in turn allows me to flex the procurement activities to my users. I become efficient.

All of this delivers better things much quicker. The teams becomes effective.

My advice for procurement people:

- get to know your users from day 1

- establish an understanding of what makes them tick and if easier create some personas

- be inclusive (the note taker is equally important, sometimes more)

- explain why you are doing this (to make the procurement journey easier for them)

- remember people change so don’t worry if this happens (in fact, you might have helped improve someone’s procurement knowledge since the last project you worked on together so it would be good to realign their priorities)

- tell your users about your findings (so they can help and learn)

- get your procurement colleagues involve (you could even try and roll this approach out to a wider user group)

- don’t spend lots of hours on this.

My advice for non-procurement people:

- let your procurement people get to know you

- let them do this as it will help remove unnecessary conversations (it will also help improve your procurement knowledge)

- it will save time

- it will help procurement people understand the true benefits of user research

- accept the findings and offer ways to improve.

How did you do?

At the end of the project, I ask: what could I have done better?

Make sure you ask this, but more importantly, ensure you adapt for next time.