Posted by
I’ve been musing (and occasionally ranting) about the procurement process over the last few months and have finally started writing a white paper on the topic. Some of the issues were brought into sharp relief by two conversations yesterday.
On one hand I was talking to a prospective client where he highlighted that one of the questions with DSDM is “How do you procure system development services from a 3rd party when the features / requirements of that system are either not fully understood and / or expected to change”. He then went on to highlight the issue of which party is taking what risks.
This is one of the core tenets of traditional / competitive / confrontational procurement: in theory the procuring party is transferring risk to the supplier. In reality this is not the case as the lawyers and commercial people in the supplier are typically more expert in assessing the risks and making sure that their organisation does not accept more risk than necessary. This is because they deal with the area of expertise in focus all the time, where for the customer it may be the first or infrequent purchase of its type.
I don’t yet have a complete answer for this question and I know this is something the DSDM community is looking at more generally. What we are looking for is a model for collaborative procurement; so meeting one of the key principles of DSDM. By definition, this could be seen to be the polar opposite of traditional procurement.
I then went to meet one of the people that I have asked to quote for re-branding and re-vamping the Kubernetes website. Again by its very nature the output of a branding exercise is unknown at the start, there is likely to be a known process but being definite about how long it will take and how much it will cost is difficult.
What did I do? Lapse straight back into a competitve procurement mindset! It was only on the train home I realised the hypocritical hole I had fallen into.
So today’s task is to work out how to procure my re-brand collaboratively….. or at least to accept my latent hypocrisy!
Procuring the unknown…
Sweet irony Jeremy!
Following on from the logic that agile methods require collaboration and trust, the underlying question would seem to be about how do you procure trust?
At the risk of stating the blindingly obvious, I think the answer is you can’t – not least because collaboration implies two-way trust, and you can’t force someone to trust you.
So how do you decide who you trust? I guess most people’s answer would have the word “relationship” in it somewhere.
So maybe a core part of a “DSDM approach” to procurement has to start long before a particular project – cultivating relationships with the sorts of people or companies who could deliver?
And is that perhaps a role for a trusted (that word again) intermediary – someone who has long-standing relationships with (say) developers which they can bring to the party in the conversation for a specific client?
First and ill-formed thoughts but maybe an interesting path – and one which obviously works better where you are the boss and do not have shareholders or public service governance hanging over you…
what do you think?
Julian
Agree about trust being critical here.
I talk in presentations about the ABC of trust; assume it, build on it, confirm it. The key is to start by assuming that the other party is trustworthy. This is almost certainly at an interpersonal level initially e.g. do they do what they say they are going to do; before moving onto something more “risky” e.g. lets see how they deal with a “small” contract.
What I think is happening at a psychological level is what I call “an exchange of vulnerabilities” i.e. I put myself in a position where you can hurt/damage me to see whether you respect this and reciprocate it. This is the same process as when we, as individuals, make real friendships; we show a snippet of who we really are and see how the other person reacts, if it goes well then we show some more. The Japanese refer to it as “opening the kimono”.
I also think of it as creating an “honesty”; using honesty as a noun to describe a group of people that feel that can be open and honest with each other. A truly collaborative team will be “an honesty” and I have seen and helped these develop.
Bringing it back to procurement it is almost as if true “open book” pricing / costing has to be in place. The supplier is making themselves vulnerable by showing that they are not “ripping the customer off” and the customer accepts that they are not being “ripped off”. Any cost overrun it is just because business requirements have evolved (as they should).
Fairly radical culture change, but I have seen examples of it when the interpersonal relationship between the parties has been good.
Of course it is the complete antithesis of EU Journal Procurement!
Well many things which make good sense also happen to be a long way from EU procurement rules!
I think the approach you suggest to gaining trust is a common and very valid one, and it’s fairly straightforward to see how, in a company with an ongoing demand for bought-in software development (say), you could make sure that you actively maintained a supplier base with companies that you trust – starting each with small projects to build a relationship.
There’s still a challenge I think for the company that only has occasional needs for software projects – how on earth do they find the right suppliers to deliver an effective agile project? I think there’s a role in there somewhere for trusted intermediaries who are known to work within a given industry sector. (and yes I know that has just moved the “building trust” issue up a level of abstraction!)
Interesting points Julian. My view is that all organisations in today’s environment have to have a “corporate development” or “strategic projects” function i.e. a small group of capable people that are spotting what changes are needed in the organisation. This team should have access to strategic implementation skills (change and project management) either internally or from a trusted 3rd party. This ensures that the organisation always knows how to manage the risks of these type of projects.
This is the opportunity I see for Kubernetes; to provide the strategic implementation skills either as the trusted 3rd party above (as we do at the moment) or helping them develop their internal skills through training coaching and quality assurance.