How to prepare a good online procurement? Selection of procurement conditions

In my previous blog post, I talked about the selection of evaluation criteria as one of the most common typical mistakes when preparing a public procurement. In fact, there are several other conditions in the procurement that should be paid more attention to.

Set a reasonable deadline

One good example is the deadline for submitting a tender. If you set a deadline of 4 working days (including a long weekend, well, to make the time seem longer), then many agencies have a justified doubt that this procurement has not already been promised to someone in advance. They also don’t participate because it’s just not a realistic time.

It is good practice to set a deadline of at least 2 weeks. If you also ask for a test assignment or it is July or December, add at least a week more, so you will get a larger circle of good participants.

Avoid the Iron Triangle

Another classic problem is the rigid fixation of the budget, the deadline for execution and the scope at the same time.
A situation where the procurement has a rigidly fixed budget, scope and deadline is illustrated in software development with the “Project management triangle” or “Iron triangle” model, which automatically leads to a decrease in quality, a break in the budget or a transition from deadlines.

Today, the classic or Waterfall triangle has been replaced by the Agile triangle. While the classic model rigidly fixed the scope and started to make the project from scratch (as a rule, as a result, both the budget and the deadline were exceeded), then the agile approach fixes the budget and deadline, but leaves the scope flexible. This means that both at the beginning and during the project, the functionality must be regularly evaluated based on how much value it creates for the user and how long it takes to make it. Less valuable and more time-consuming features fall to the bottom of the to-do list and in the end it may be decided not to do them at all (because the ROI – Return of Investment – is too small).

But now we have already moved one step further, to the project management process and scope management. In the procurement, I recommend leaving at least one of these three components open.

The maximum budget is usually already fixed in the public sector, and this is perfectly OK. It is not worth writing the scope in a so-called closed and too detailed way, because no one has the abilities of an oracle and does not foresee all the needs (more on that later). It would be reasonable to leave the deadline either open or not to force too little implementation time, a la “the project must be completed within 3 months”. If the customer has a specific expectation about the time of launching the website, they should share it in the procurement document, but it should be marked as an expected date and not as a strictly required date.

There is an old ironic saying among developers that the client wants all projects to be completed either “by Christmas or Midsummer’s Day”. The reason is that the budget money has to be spent within this year or the project is to be completed before the summer holidays. In order not to fall into the same pattern, plan your activities in advance, prioritize and think through whether something bad will actually happen if the project ends, for example, in February or October.

Realistic budget

As mentioned, a public sector contracting authority usually has a fixed budget, and this is normal. This is also the case in the private sector. It all comes down to how much functionality they try to squeeze into that money number. Usually too much is piled up, and if you dig deeper, a considerable part of it is either relatively useless or a much simpler and cheaper solution would be suitable.

You say that you definitely need all these features and right now? In reality, this is true in very rare cases.

I suggest you do the following simple prioritization exercise:

1. List the planned functionality modules in a table (in the case of a regular website, their number will be around 10..20).
2. After each row of the module, add its priority on a scale of 1..5. Priority for your web user and not for yourself.
3. Sort your table by priorities so that the most important functionalities are at the top.
   Voila! You’ve done the first Product Backlog prioritization. (From here, we can move on, to finding ROI, i.e. the value to be obtained, but let’s stick to the minimum for now).
4. Finally, ask yourself and others if the modules at the bottom of the table are needed at all. Are they definitely needed immediately or perhaps it would be possible to add them later, during the development and maintenance period?

If you get into trouble yourself, bring in an IT expert who will help you assess whether the planned budget and the scope described are in balance so that as many strong bidders as possible participate in the procurement.

Should we make one or two IT procurements?

I would like to talk about another dilemma that contracting authorities often struggle with – namely, whether to make one large procurement or two separate procurements.

Two separate procurements mean first the procurement of the business analysis, visual design, UX/UI analysis and prototype, then the procurement of a separate technical analysis and implementation. At the same time, the results of the first procurement are the input materials for the second procurement.

A single procurement means procuring all these stages at the same time.

If you have less experience with web projects and there is also a lack of in-house IT support, I recommend carrying out the procurement of the web with two separate procurements. This may take more time, because the procurement takes time, but in the end, you will get a better result.

Why? There are several reasons for this, but to make it brief, the most important of them is the following.

When mapping business needs and creating a user interface, many new needs emerge that no one has thought of before. Or the harsh truth about the futility of some wishes emerges. If nothing new is revealed, then the person conducting the analysis is downright poor 😉

Once the analysis has been completed, you now have the opportunity to adjust your planned scope according to the results of the first procurement and provide high-quality input for the second technical procurement. And the higher the quality of the input, the better your project will succeed!

In the next story, I will talk more about writing a technical brief – what, why and how much.