Whatever you’re buying, wherever you’re buying it, the procurement process always starts with requirements. That means identifying what the system or environment you are commissioning has to output. Typically, we talk about outcomes - what does the system have to do? For example, how many transactions per second does it have to be able to complete.
Identifying requirements
But how do you work out what the requirements actually are? A good place to start is with the end user. They should know exactly what they need and why. The technical requirements are also paramount so make sure your technical people get involved at an early stage too - they know what good looks like.
Consider an example: Infrastructure as a Service (IaaS). As a buyer, I expect a technical member of the team to produce a list of required technical outputs like security levels, hypervisors or networks. Then, I need to know some of the softer aspects: is the supplier a reseller? This may seem innocuous to a non-techie like me, but at a technical level, information like this could present an additional layer of bureaucracy in the operational process.
Caution, it may not end here. Sometimes we need additional clarification when a supplier’s service offering is short on detail. We normally send off emails looking for further information to help us make our decision.
Creating a shortlist
Now we have enough information to make the first cut from a longlist to a shortlist. Those that meet your criteria go through, the rest are removed from the process. As a courtesy to those suppliers we have communicated with, we’ll let them know when they have been unsuccessful and why.
Question-and-answer session
Nearly there. Even with all the technical information we've gathered, we may still need to go into greater detail. Our favoured way of extracting more in-depth information is to organise a question-and-answer session with the short-listed suppliers. This normally involves the supplier team, our technical people and someone from Procurement.
Prior to the meeting, we establish a set of critical questions to be put to all suppliers. These may be just to verify facts or ask about how the technology is used. The outcome of this get-together is a single view of our potential suppliers’ infrastructures, abilities and competences, all pointing to the best technical solution for our requirements.
Finally, procurement
Having established the best supplier with the closest fit to our requirements, the process now turns towards Procurement. That means we have to establish and agree the call-off contract and conduct any additional due diligence not aligned to technical requirements. An example is financial viability - in typical frameworks this is normally undertaken as a preliminary check before acceptance on to the framework. Cloud is not your typical framework. That’s why the buyer needs to perform certain checks to mitigate risks. What has to be checked is decided by the contracting organisation and its attitude to risk.
It’s a team game
A successful procurement process depends on a group of individuals working effectively towards a common goal. Buyers, technical teams, users and suppliers are all invested in making sure that buying the right product is as simple as possible. That means everyone involved has to have a good understanding of the project goals and a clear view of their role in the buying cycle. So when it comes to the crunch, buying really is a team sport.
If you’d like to learn more about the buying process, check out our buyer's guide.