Better RFP procedures

It is hardly possible to make a really good and objective choice in an RFP process. How can that be better?

Recognizable?

Have you ever set out an RFP trajectory? You had a desire to have a digital product developed and since it involved a lot of work you wanted to do an extensive selection of IT suppliers. To select the desired quality, but certainly also to be able to make financially responsible choices.

You don't start an RFP project unprepared. To give suppliers clarity about the product to be developed, it is necessary to collect a lot of information. These are often the requirements and wishes of the organization. Sometimes you go a bit further and get your wishes from the market. Fortunately, some organizations also pay attention to the intended users.

Zoom out

If you are carrying out an RFP project with good intentions, then you have now collected what you want the IT supplier to develop. But no one knows yet what the solution should look like

The offers

You have followed the RFP process and the questions are with the IT suppliers. Fortunately, you have set aside some time for the tendering parties to get acquainted and to discuss questions and possibilities in a more individual way (quite a pain point in tender processes). Where necessary, you have shared questions with the other providers, so that everyone has the same information as much as possible. You share the questions with the other providers so that everyone has as much information as possible.

You will receive five offers on the closing date. Five IT suppliers have devoted a lot of time and attention to responding to your RFP in the best possible way. You will disappoint four of them and thank you for that effort. But who are you going to select now?

The losers sometimes spend weeks of effort answering an RFP. And they will never get that time back.

Probably 1 of 3 things is happening now:

• There is one party that is clearly the cheapest. You choose that party, because there is quite a bit of financial space between them and the number 2. You realize that there is still some margin, if there is still more work to be done. This party has probably bought in. During the process you spend a lot of time on (distracting) conversations about additional work. The final price is likely to be higher than the prices submitted by other parties.
• With everything you get in return, you have trouble making a good comparison. The easy choice worries you, so you are going to build in extra steps in the selection process. With 2 or 3 parties you go even further in depth. Your trajectory becomes a lot more complex and takes a lot longer than you originally thought.
• There is quite a difference in price, but there is also a clear difference in quality. A good, experienced party has responded but is also the most expensive. Perhaps more expensive than originally budgeted. This is because this party understands that a lot is still unknown and that an uncertainty margin/risk premium is not an unnecessary luxury. Because you are going over your budget, you have to look for more budget.

Zoom out

Most IT suppliers work agile (with good reason). And it is not clear what exactly the solution should look like. It is logical that there is still a lot of uncertainty! Not just with the suppliers. You have the same concerns: with all that money I'm going to spend, will I have what I wanted in the end?

Don't forget the hidden costs. The consultant you involved in the process who now spends several months longer on the RFP. Your own colleagues who still need to be involved to bring the RFP to a successful conclusion. The loss of time, as a result of which your time to market (and therefore the desired value you wanted to realize) continues to be postponed.

Start of the project

The selection is over! The IT supplier can get started. He starts with an extensive analysis phase, because he still doesn't know a lot. He wants to get a good picture of the existing IT architecture and he takes steps to arrive at a solution that fits all requirements and wishes.

That's where the "How" comes in. How does the product actually work? What is the concept behind it? We may know which functionalities are needed, but how do they work exactly? Because the solution can still be worked out in 100 ways, it is important to find the one desired way as quickly as possible.

In many cases, IT people are at the helm here. The supplier uses a preferred technology and that will determine much of what the product will look like. Much will be reasoned towards that technology. Completely valid. But is that also the best solution?

What if..

What if you start the project, where you get a clear picture of what the IT architecture looks like, but especially what the desired solution looks like, what if you bring it to the fore?

What if you had that analysis and the translation to the solution done under the direction of your business (where it belongs) and independently of the technology to be chosen? Of course, things should not be invented that cannot be built, but technology should not be leading.

If you bring the analysis and translation forward, you put part of the project before the RFP. And you will have this carried out by professionals who have a lot of experience with concept design, supplemented by an IT architect who maps out the current IT architecture.

In the agile way of working you even have a means for this: the Discovery phase. Where it is often used by IT suppliers to get all technical information to the surface, a Discovery phase can also be used very well to make the product to be developed much clearer.

What do you have?

By bringing forward a step in the process, you now have much more information about what the intended solution is before you turn off the RFP. And where the development challenges lie. Because that intended solution can be maintained against the existing IT architecture.

As a result, there is much less uncertainty in the project. That means lower offers, but also offers where much less space is needed for unforeseen additional work.

Moreover, in most cases the quality of the end product is much higher. Because IT suppliers are very good at developing, but not always at coming up with a solution based on requirements and wishes.