Based on actual needs and not complicated technology-based requirements.
The advice comes from Christofer Wiechert, solution consultant at InExchange, and is aimed at all public sector buyers in the country.
Christofer also has other tips regarding IT-related procurement.
- Think new and problem-oriented. Tell us what you want to solve and why. Be straight to the point, he urges.
Christofer Wiechert worked for several years at Region Västra Götaland with process improvement, agile project planning, strategic communication and IT solutions. He is now a member of the Consulting team at InExchange.
He has worked with procurement cases in both directions.
This much is certain: Christofer is convinced that there is room for improvement. He is referring in particular to the process that takes place when public administrations go out to tender for IT contracts.
- Often, they reuse requirements from previous tenders or take ready-made formulations from the public requirements library for IT procurement. They also lean on existing solutions and listen to the existing supplier, rather than conducting market research and obtaining external opinions before the requirements are published in the procurement, Christofer notes with a tone that clearly emphasizes that he thinks this is the wrong methodology.
For a requirements developer, the need should always be the guiding principle.
A request should be focused on what you know is important. Not what you think is important.
And if you don't know, you ask.
- A lot of it is about making sure you get the functionality you need and not the functionality you already have. Now, many people fall into the trap of guessing how it works on the other side. It is not very successful. Nine times out of ten, it does not work at all as you thought technically, Christofer points out.
He interjects with a relevant comparison:
- Look at how private actors do. There is an incredible difference between the private and public sectors in how procurement is carried out. The private sector focuses on achieving something rather than defining specific requirements.
- The requirements picture is not nearly the same in private procurement. You don't have a list of 300 requirements to answer yes to. Something that occurs frequently in public procurement.
Christofer believes that a change in management would also benefit the suppliers with whom the authorities or municipalities will sign agreements.
- We who have to respond to a procurement do not currently have to make much effort. On the contrary, it's quite easy. I think it's wrong. I think we should describe how we are going to meet their needs in a detailed way," he says.
According to Christofer, all stakeholders would benefit if the requirements were managed with an approach focused on solving real challenges instead of trying to micromanage technical aspects.
But more to the point: what are Christofer's handy tips for buyers who are about to carry out a deal linked to operator services? You have them here in order:
Be problem-oriented from the start. Map the need and collect RFIs (Request For Information) from suppliers. This gives you the opportunity to describe your business needs more precisely. Ask the question "How do we solve this?", invite suppliers to hearings and capture what is said in a generalized requirement that encircles the problem. Then let the suppliers respond and evaluate. Then the focus is not on technical details but on the real needs of the business.
A user story is a short description of what a user wants to achieve. In IT, and perhaps in particular development, it is a common methodology. You put a few simple phrases on paper. For example: "We want to do this to achieve this". Or you describe the case in a straightforward way. Then you let the suppliers tell you how to fulfill it all. This is a better approach than having mandatory requirements that can only be answered with a simple "Yes".
Ask yourself: why have we included this requirement and what is the purpose? You have to evaluate why you are imposing requirements on certain things. The main goal of the procuring organization is usually to simplify and improve operations. The best way to achieve this is to be straightforward and clear. Avoid the squareness that easily arises when lots of mandatory requirements are stacked on top of each other. Instead, dare to step back and set requirements to be met in a qualitative way. It is more relevant. Then you get a requirement that matches the needs picture.
It is rarely a good practice to set detailed technical requirements at this level. The risk in this situation is that the actual problems, the ones that primarily need to be solved, get lost in incorrect designations or technical terms. There is no point in setting requirements if you do not understand the real meaning of the requirement. It is better to describe your business problem in a straightforward way. Then the supplier has to make an effort in the procurement and talk about what their solution looks like and how it works.
Summary:
Christofer's advice and thoughts aim to revitalize a process that he believes could benefit from some fresh thinking and different approaches.
- Focusing on the actual challenges and being open to different solutions not only helps to better meet business needs. It also creates a more dynamic and innovative procurement environment," he concludes.