There is an imbalance in the IT sector of government procurement and this is a headache for customers and contractors

Several systemic problems have arisen among IT tenders: poor technical specifications, bias towards large integrators, a queue of work on large orders, and small and medium-sized teams are practically idle. What’s most interesting is that problems follow from one another.

Expert: Timur Alimkhanov, co-founder of the StepUp web integrator, 14 years of experience working with the government.

In this article I want to address the problems that I observe among IT orders in government procurement. They don’t get written about in business publications, but my team meets with them all the time.

Disclaimer

The material reflects my experience in the field of IT procurement, and specifically in the development of websites and portals. Your experience and opinion may differ – that’s okay. You can always write about this in the comments.

Purchasing database (if you are aware, feel free to scroll further)

I keep repeating that the state simultaneously combines the features of the worst and best IT customer. There are many orders, large budgets, the regulating laws are complex, but studied far and wide. However, there are nuances and they need to be dealt with.

Just in case, I’ll clarify some basic things. Government procurement is a system where state companies look for suppliers of goods, works and services. The customer publishes the terms of reference, cost and other documents, and the participants submit applications. As a result, the customer chooses the best offer. It’s clear that there are a lot of nuances, but it’s not worth getting bogged down with them now.

To avoid confusion, we will divide government procurement according to 44-FZ and 223-FZ.

Government procurement under 44-FZ. Conducted by all state and municipal organizations that live off the budget. Tightly regulated. Fun fact: the document is 10 times thicker than 223-FZ.

Government procurement under 223-FZ. Needed for companies with a state share of 50% or more and their subsidiaries, natural monopolies, regulated activities and budgetary institutions that plan to spend a grant, subcontract funds or their own money.

There are also commercial purchases. There you can do whatever you want within the framework of the Civil Code. However, today we are not talking about them.

Purchasing is difficult and not for everyone. However, if you get comfortable here, you will get a large pool of customers. True, there are nuances here. More about them below.

Imbalance of orders: they are either small or expensive and promise gray hair

Formally, all conditions have been created in the IT sector of government procurement to ensure that the environment is as competitive as possible. The trick is in the details, and now there is an imbalance in the proposals. Roughly speaking, there are two types of orders: small ones with dubious benefits and large ones with problematic technical specifications.

I will explain each point.

Small ones with dubious benefits. Here you can object that such orders are not interesting for you, but just right for beginners. Okay, let’s do the math.

There is an order for website development with a budget of 300,000 rubles. To the standard expenses, add the salary of a public procurement specialist, a lawyer with relevant experience and other employees needed to support the project. If everything goes like clockwork and the project is completed within 10 iterations, you can open the champagne. Only inexpensive, because the margin will be 20,000 rubles. If the project stalls, there will be no profit at all.

Large ones with problematic technical specifications. Long-lived purchases can be found on trading platforms. More often these are orders with a price tag of 200-300 million rubles and a well-known name of the customer. However, providers of relevant experience are bypassing the application. The reason is a problematic technical specification, and this is not just a “red flag”, but Red Square on May 1st.

However, it is best to explain this with an example.

There is such a thing – closed procurement. This is when the customer invites a limited number of suppliers to participate, and they are already competing for the project. This year I was invited to such a closed tender under 223-FZ. The customer is a major government developer who needs to implement two corporate portals.

The terms of reference are written in bold strokes, and some aspects are completely vague. The security block in the technical specifications was given a lot of attention, but it was verbally stated that its implementation was being discussed because block is not a priority.

The law allows you to communicate with the functional customer – the people who will accept the project. I took advantage of this opportunity in my case it was the IT department and security.

I start communicating and then it turns out that the security unit is a priority. A corporate portal with average characteristics and a portal built around security are two huge differences. Initially, the technical specifications were estimated at 15 million rubles for two portals. After communication with functional customers and recalculation, the cost increased to 40 million rubles. In general, I dropped out of the project.

The imbalance did not come out of nowhere. Often the customer tries to save money by describing the scope of work in a streamlined manner, and this leads to another problem.

Terms of reference seem to be written poorly on purpose

Companies that have been burned by a streamlined technical specification select projects very carefully. It turns out to be a paradoxical situation: there are experienced and cool performers, but because of the risks they do not take on orders.

I’ll reveal the inner kitchen. When I take on a tender, I make a profit based on a positive, not negative, scenario. If it worked well, then the profit reaches 30%. If you messed up and spent more resources for various reasons, then 15%. If it’s really bad, then there’s no profit or I’m going into the red. Bad scripts are super rare. After all, 14 years of experience taught us to see bottlenecks in advance.

But!

When I read some technical specifications, I understand that no amount of experience is enough to bring the project to the final. It’s just that the technical specifications are written in such a way as to create tasks that will never end. For such orders, the immortal phrase “There is no money, but you hold on” is not a meme, but a motto in life.

The main problem with inaccurate specifications is that they open up the potential for an endless development cycle. Each element of the project can be done as standard, or you can go crazy and make the best implementation on the market. Everything depends on the will of the customer. And yes, no one will increase the budget.

Here’s another example. The portal is being developed, the budget is fixed at 20 million rubles. It turns out that portal support should be 24/7, 180 hours per month, with a middle-level operator and situational specialists of a higher rank working on the line. In other words, support eats up half of the budget.

I met the customer halfway and offered a detailed technical specification, where I described how to redistribute resources. The answer was something like this: “We won’t cut off support, everything remains as it was, try to keep it within the money.”

I am convinced that bad technical specifications are not a collective act of malice. This is a consequence of low qualifications or internal discord of the customer’s team. And this is the next problem.

Often there is simply no one to write technical specifications

In an ideal world, the customer writes the technical specifications, and the supplier works according to it and everyone is happy. Yes, some details are being clarified, but overall the logic of the project does not break. In reality, the technical specification rather outlines the outline of what is needed. The contractor signs the budget, and then draws up a private technical specification, also known as ChTZ. This is where the complete work plan is fixed.

I remember a failed experience with a corporate portal for a federal developer. The first 20 working days would be spent on creating a ChTZ taking into account the threat model. In a good way, you need to spend at least 40 days on the threat model alone.

It turns out that I, as a contractor, do the customer’s work, forming the ChTZ, and I also have to meet a tight deadline. This does not apply to a specific tender, but to the procurement sector as a whole.

Writing technical specifications and pushing it through to publication on the procurement portal are different skills. While the document passes through all authorities, it may change beyond recognition. Even the author has difficulty recognizing his work.

Customers are often surprised by the timing of ChTZ development. Let’s say I plan to submit a document in 20 days, and the customer says that it can be completed in 10 days. There is no doubt – they know their infrastructure well, but I need to delve into it.

Why does almost no one write ChTZ? An outside glance suggests that there is no desire or competence to write clearly and understandably.

The second reason is discord within the customer’s team. The reasons for the discord may be different. Perhaps the departments are pulling the wool over their shoulders, perhaps they are in a hurry, or vice versa – the project was imposed from the outside and no one wants to take responsibility.

The format of the terms of reference in procurement is established by law, but the law does not contain the line “make sure the contractor turns grey.” I’m at a loss here.

Large teams are overwhelmed with work for years to come

There was a tender where I was the only participant. No monopoly, just no one else showed up. I started the project, at the ChTZ stage I proposed to implement the portal on Bitrix, but this decision was not accepted in principle. What prevented you from specifying the recommended platforms in the technical specifications? Mystery.

We parted ways with the customer by agreement of the parties. At the time of writing, the tender was still active, and the contractors were in no hurry to send applications. There are also few responses to other customer tenders.

Let’s return to the first point – orders come unprofitable, or large, but without profit due to weak technical specifications. There is no middle option. I would love to take “middle peasants” with a clear technical specification, but they simply don’t exist.

Let’s imagine that there is a ChTZ worth 200 million rubles. You won’t be able to just show up, because there are legal requirements. The contract can only be accepted by the company that has completed similar work for an amount of at least 20% of the current one. It turns out that there should be a similar contract for 40 million rubles. Usually people play it safe and clearly write down a list of work as required.

That’s the trick. There are many good teams that have entered the government procurement market and completed contracts worth 5-7 million rubles. They won’t accept a large tender even if they want to. First you need to grow up. However, performers of the relevant scale are booked several years in advance. Here an order comes to a large integrator, for which 200 million is not that much money. He is looking for a subcontractor and reluctantly implements it.

Entrepreneurs who want to grow get stuck. They have great specialists and the resources to complete the project and grow further. However, they hit a glass ceiling.

So what to do?

Let’s summarize the problems.

Imbalance of orders on public procurement sites → either small or large. Both with questionable economic benefits.

Low qualifications of the drafters of the technical specifications → the scope of work is difficult to estimate, technical specifications are written after the project is accepted, prices do not correspond to the scope of work.

Potentially interesting orders are idle → desires do not correspond to the budget, and the technical specifications are drawn up so poorly that they scare off the performers.

Most of the listed problems can be solved with the advice “customers need to strengthen management and write technical specifications correctly.” Let’s just admit that this is the “Exercise and sleep 8 hours” advice.

In my opinion, the problems will remain relevant until IT orders are separated into a separate category. There are already industries in Russia that stand apart in tenders, for example, state defense procurement. Now let’s imagine that IT orders are placed on their sites according to special requirements.

The framework is most useful in this regard. Let’s say that when publishing a purchase, the customer is required to indicate the section: web development, information security, or something else. The selected section specifies the required fields to fill out. If you don’t fill it out, the purchase won’t be allowed through.

There is still a lot of work to be done in procurement. Separating the IT sector into a separate cluster seems a logical step to initiate positive changes. Now there is a variety of platforms, but there is no culture of forming clear technical specifications and requirements. We need a framework that will work as the first line of defense against the human factor.

What a separate ecosystem for IT procurement might look like is a broad question. I think I will write a separate article on it.