I once blogged, “It (procurement) just needs to be invited to the table early on”, I wanted to share my experience of being involved in multidisciplinary teams.
They stood up
A few years ago I thought it was odd, people ringing bells or cranking a ratchet instrument to start a meeting. Even odder that this meeting was everyday. People didn’t sit, they stood. People weren’t frantically reading the reams of paper they planned to read the night before. They weren’t hanging around outside a meeting room waiting for people to vacate it (always awkward). And these people didn’t wait for the most senior person to kick the meeting off.
So I walked over to the jean and Star Wars t-shirt wearing Frappe Latte drinker and said can I observe.
There was no, “no”.
There was a “yes”, followed by “let us show you what we do in this team”. (Although my tie did put a few people off).
Procurement – the dreaded word
When asked what I did, I said, “I do procurement”. The dreaded word had been dropped. What would happen next: ignored, pushed out, shot…!
No. A barrage of questions followed. It was great. The ‘stand uppers’ wanted to know about procurement. And from then on I went to the same stand-up every day. Well, until I realised I was not ‘assigned’ to that project.
I located the stand-up of my assigned project and for 3 consecutive days I climbed the 78 steps to attend the 1030 session.
Just sit with us
By the end of the 3rd day, someone said, “why don’t you just sit with us”. So I did.
Obviously the “where have you been for the last week” questions were being asked by my procurement seniors.
The answer was simple:
“I’ve been sitting upstairs with the project team. I’ve learnt a lot, I’ve shared a lot and I’ve also removed the need for the weekly 2-hour meeting (also saving the preparation and printing of papers). It’s great. We talk instead of sending emails and I understand so much more about the project”.
It took me a while to convince people of the merits of ‘allowing’ a support function to sit within the project team but there were so many advantages:
– meet the face behind the email
– less emails
– less paper
– knowledge of the ask
– knowledge of the users
– knowledge of blockages
– better risk management
– basically, I gained loads of knowledge
– (trying Frappe Latte’s – “how much do they cost?”, said the procurement guy).
Ruby is more than just a Kaiser Chiefs song
From then on I would attend the daily stand-ups, contribute to the show & tells, learn about black screens with coloured numbers and letters (that is coding by the way). I found out that Ruby is more than just a Kaiser Chiefs song and Java isn’t just a manly body spray consumed by teenagers keen to deploy ‘the Lynx Effect’ (note, there is often some good procurement to be had on these products in the January sales).
People took the time to explain the difference between a front-end developer and a back-end developer, why user research matters, why delivering in iterations is important (it lowers risk and saves money and protects the reputation), and so forth. I even started to wears jeans…..!
We would share:
– what we have done
– what we are doing
– what we will do
– blockages and issues.
Exchange of knowledge
However, the most rewarding bit for me was the exchange of knowledge that took place.
I had various people asking me questions about procurement:
– what is it
– what is buying then
– what is a threshold
– what is an OJEU
– why does it take so long.
This was a win-win: I learnt about the project, digital things, and how to use agile.
The non-procurement people learnt about procurement. They were starting to understand my world and the issues around it.
So what are my takeaways:
– Being part of the multi-disciplinary team enables cooperation and teamwork
– This in turn creates shared knowledge
– Which results in less process duplication, less resource wasted, less management
– Meaning more doing, more delivery, better public services.
For non-procurement people:
– invite your procurement people to things, this will help with the marginalised feeling some people often have
– let procurement be part of the multi-disciplinary team from day zero
– explain the capability you might need and future scaling
– challenge the processes
– ask questions about procurement (good ones include: What does the Public Contracts Regulations mean, what local rules are there that I must know, what do you mean when you say “open, fair and transparent”)
– work with not against procurement, on market engagement.
For procurement people:
– get involved as early as possible, even to just listen about things
– go to the design workshops and see what they are about
– get embedded asap
– understand the product roadmap and pipeline of potential work
– do some user research to find out about user experience
– remember it is ok to ‘copy, paste, adapt’
– try and remove some of the bureaucracy by challenging it (don’t open yourself up to more risk, just apply balance)
– ask lots and lots of questions (for example: what is the minimum viable product here, when will you need to scale, how long is the alpha)
– don’t worry about asking the ‘stupid questions’
– be proud of your profession by sharing the good things it can do
– don’t ramble, just say the thing or even better show it (diagrams do help)
One delivery team
Procurement is part of the wider eco-system. Getting involved will help prioritise delivery, lower the risks, deliver real user value, and save money.
Integration is key. Remember, suits, ties, jeans and t-shirts can all work together as one delivery team. The less levels of hierarchy the better. Lets all share the problems, the risks, and demands. But lets have tea together and share the medals too.