How can we navigate a world where public procurement procedures are most often out of touch with the reality of web projects? What solutions exist to successfully complete our projects while respecting the client's wishes, deadlines, and budget? Here is the story of our experience as a Drupal web agency, reaching out to public organizations.
Let’s not mince words. Public procurement procedures are not suited to web projects. There is an almost systematic gap between the framework set by the call for tenders and the actual constraints of the project, which become apparent throughout the course of service delivery. This gap can quickly render specifications, timelines, and estimated budgets, on which the provider is legally committed, obsolete. However, it remains in the public interest that the project meets the client’s needs, is profitable for the provider, and, above all, is completed. So, in order to align contractual constraints with the real-life constraints of the project, we’ve had to develop and embed into our processes a culture of dialogue and compromise.
The cost of a call for tenders
For their web projects, public institutions or similar bodies issue calls for tenders. These outline the framework for the public procurement process, ensuring fair competition between candidates on the one hand, and getting the best value for money, on the other.
For candidates, these procurement procedures come at a cost: that of entering into a rather burdensome, rigid, and time-consuming process for their teams. You’ll have to introduce your company, outline your resources and staff, fill out loads of paperwork to prove your legitimacy, and demonstrate the reliability and soundness of the business. And, of course, make a proposal that fits the buyer’s needs and provide a quote.
A “blind” response
The problem is this commitment is made with no guarantee of success. And, let’s be honest, often with great uncertainty about whether our proposal truly matches the client’s needs. In fact, as part of the call for tenders, no contact is allowed between the buyer and the candidate. So there’s no way to check that the needs of one have been properly understood by the other. As a candidate, you’re left to work with a file that’s more or less clear, without the opportunity to confirm or refute key pieces of information.
The only communication provided for by the procedure is through written Q&A exchanges. But the answers often provide the bare minimum of detail. Or they arrive too late, as the buyer can respond up to six days before the deadline for application submission. Needless to say, if the question is fundamental, it’s too late to revise your proposal.
Is the game rigged from the start?
In reality, in most cases, the candidate finds themselves forced to respond based on assumptions grounded in their understanding of the need. This "blind" response is therefore at odds with the original goal of these public procurement procedures: to provide for fair competition among participants. Thanks to their knowledge of the context, the buyer, and the contract history, the incumbent provider gains a serious advantage, leaving little chance for challengers.
Bottom line: public procurement requires significant investment for, let’s say, slim odds of success! It’s worth asking how many candidates self-censor, discouraged by the process.
A procedure particularly unsuited to web projects
Public procurement procedures are especially ill-suited to web projects. The reasons are many, as Christophe Le Jeune, CEO of Alfa-safety, a hosting and managed services provider specializing in web applications, explains very well in his post. He mentions, for example, a technical framework that lags far behind market best practices and the rapid evolution of technologies, as well as response times that are much too short.
Moreover, precisely scoping a web project in advance is a very complex, if not impossible, task. Here’s why: web projects are, by nature, iterative—they’re built step by step, in the field, facing real-world challenges, especially the client’s requests, user needs, and technical constraints. While getting closer to reality is more likely with project management assistance, only an empirical approach, built jointly by provider and buyer, allows for an accurate definition of scope, timeline, and budget.
There’s the framework, and there’s what we do with it
So, now what? What can we do to reconcile the contractual framework and reality? In our experience, it’s always the same story. It’s only once the contract is won and the project launched that we can really begin to define it.
It all starts at the kick-off meeting. We ask the client about their needs, we discover their priorities, the features that are essential to them, and the real level of involvement these features will require. We also identify less important features, those that, for example, could be implemented in a V2.
Often, it’s only at this stage that we truly understand the project and its workload implications. For example, we might learn that the client’s database is actually poorly structured, making the anticipated work much more tedious.
Our initial estimate therefore quickly becomes obsolete, and adjustments are required.
These adjustments are systemic and reveal just how ill-suited public procurement procedures are for implementing a Drupal web project. In practice, both parties must show agility to achieve an outcome that matches the client’s needs and the committed budget. To ensure the project's success, you have to rely on the goodwill of both client and provider.
Especially since the two parties are not on equal footing. On one side, you have an administration protected by the tender process. On the other, a private company that has committed “blindly” to a budget and a timeline for a project whose real scope they will only discover after the fact. Their company’s profitability—maybe even viability—can be on the line.
Developing and embracing a culture of dialogue and compromise
This gap between contract and reality is perfectly well-known, anticipated, and built into our way of working. To address it, we’ve developed a culture of dialogue and compromise.
We listen, we analyze, we discuss, we negotiate, and we get results.
We also know that—most of the time ;)—we can count on the goodwill of clients who, over the years, have grown accustomed to this type of project. Thanks to their past experiences, many public organizations have faced failures and become aware of the web’s constraints and its iterative process.
All parties are better off reaching an understanding, because everyone has something to lose.
For the provider: a client, a project, future projects that may follow, and payment for work completed.
For the administration: the completion of their project, public money lost, and poorly delivered public services.
Let’s talk!
If this culture of dialogue resonates with you, don’t hesitate to contact us to discuss these procedures that shape our working relationships. Let’s open doors, let’s talk. And of course, let’s talk about your Drupal web projects!
