The Chokepoint of Digital Transformation
If we were a fly on the shoulder of a random middle manager in any corporation, who is sitting in a meeting discussing strategic plans for the upcoming several years, we would see and hear about innovation, digitalization, and how it will fuel growth and success.
And the bigger the organization is, the more likely it is that road to this success goes through a transformation or digitalization project of significant size. And unless the said organization has an extensive IT team sitting around waiting to start this big project, it is very likely that some IT vendor will be contracted to make the magic happen.
The tendering process takes time. Request for information (RFI), request for quote (RFQ), and request for proposal (RFP) is prepared and published. Vendors all prepare their proposals, there are several question and answers sessions, clarifications are provided, and then finally team can review the proposals. Unfortunately, often they seem to be “just ok.” They are barely covering requirements and there is no feeling of anybody providing anything extra nice and innovative. Somehow one vendor is selected, and the project starts. And then fails to succeed fully. Either is delayed or becomes more expensive or both. And benefits are also not as great as expected. Why?
The problem lies in what I call “The chokepoint of digital transformation”. The organization has spent a large amount of effort discussing various pros and cons of the requirements. There have been brainstorming sessions, workshops within various departments, several alignment iterations between teams, review sessions with top management. Each team has provided its input. It has been aligned with the strategy of each department. It has been aligned with the high-level strategy of the organization. Also, technical architecture has been defined and aligned with the target software architecture by the enterprise architecture team and senior technical leadership across the company. And if the company and project are large enough, all this has been facilitated by an international management consultancy.
All this is considerable effort is then compressed into one single RFP document that is then published for vendors to apply with their proposals. Sometimes there can be intermediate stages of RFI or RFQ processes, but in the end, there is still this one large tender document with all the needs, requirements, and constraints written down.
After vendors receive the document, they are allowed to ask questions in a written format, or maybe during a Q&A session where all the vendors are invited. The Key is that all of the answers are provided to all of the vendors, so there is no competitive advantage given to any participant, which would reduce the chances for the company to choose the best offer. And in many cases also illegal, especially if the purchaser is a government entity.
This, of course, means that there is no way how vendor representatives would be able to spend significant time speaking with multiple people involved in the great effort of preparing the RFP. Any one-to-one conversation would contain a chance of giving an advantage to someone, so it can't be allowed.
This, naturally, limits the understanding the vendors have. If the full understanding that people who have prepared the RFP is 100%, then even with the in-depth one-to-one conversations, the vendor would probably not reach more than 80% of the same understanding in a limited period of time. But if the only way of interaction between the vendor and the RFP team is via the RFP document and one or two clarification rounds, then the percentage of understanding can be much lower. And this is the first point where the quality of the entire process is lost.
When software vendors build their proposals based on incomplete and unclear input, they have to plan for upcoming uncertainties, mistakes, and misunderstandings. All of the risks that are present there have to be dealt with. Either by adding special clauses to the proposal that this or that eventual idea is explicitly out of scope or by adding additional risk buffers to the price estimate. Often they end up doing both to ensure that even if during contract negotiation all the special clauses are taken out, they would still be able to deliver.
When all the risks are buffered, then the vendor can end up with an oversized effort estimate and, therefore an uncompetitive price. Which in turn leads to various cost-cutting efforts in the proposal. They are trying to remove any possible bells and whistles, any extra value-add items, and so on. And at the end, there is a relatively skinny proposal that is trying to cover the maximum amount of requirements that are well understood and trying to defend against any complexities that might torpedo the project budget.
You might think that it should still be possible to build an excellent proposal that will deliver a lot of value and fulfill the maximum amount of requirements while providing attractive added value benefits based on the vendors' past experience. Vendors are certainly trying to do that, but the fact is that there is often no time to come up with something great.
Often there are only 3–4 weeks to come up with a great proposal, and that time is spent writing large amounts of text, making diagrams and flowcharts, gathering CVs, arranging references, organizing the proposal in a specific format that the procuring organization has requested, estimating the effort, compiling the commercial offer, doing internal reviews and so on.
If the RFP preparation effort has taken months or even years, then RFP itself can be hundreds of pages long, with thousands of detailed requirements. The prepared proposal is then of similar size, and each detail matters, as it later becomes part of the contract between parties.
There is no time to put any more effort than the absolute minimum required. Especially given that time is money, and preparing a proposal that is hundreds of pages long can take hundreds if not thousands of man-hours. And as the tendering process can be very competitive, the return on this investment can very well be zero. So giving any additional effort without it having visible improvement on the chances to win the deal is not likely to be approved by management who has to control the sales budget.
So, when the proposal is made, it inevitably contains many assumptions and approximations. And ideas of solution are very raw as well. If initial full knowledge of the plans was 100%, and due to the very stringent tendering process it could go down to 60% or so, then it can decrease even more during proposal writing. So no surprise that when the tendering committee reviews proposals, there is a certain lack of celebratory mood in the room. Proposals are ok, but nothing more. And some are undoubtedly bad as well.
And when the project starts, the interpretation of initial knowledge starts to expand in all directions. Architecture starts changing. New mandatory requirements are added to the project scope, and in exchange, some other original requirements are outscoped. The legal environment changes. The business environment changes. Competitors do something. The government does something. New products. New managers. New 3rd party systems.
The project end of the information funnel keeps expanding, but at the same time, the information is less and less similar to what the RFP preparation team had in mind during the first part of the tendering process. And this inevitably leads to a reduction in the value that is delivered. Any bit of wasted effort in the process and any piece of lost or misunderstood information decreases the benefit provided by the project.
And, of course, much of the benefit had probably been exaggerated in the first place when planning the project. Project business case documents are some of the most optimistic papers ever written on planet Earth.
This is a rather bleak reality that I have painted in this article. However, it is also true more often than not. Maybe your organization is the lucky exception, and if so, kudos to you. Now just to keep it that way! |And for others — how could you avoid this mess? How can you innovate, transform and digitalize without losing years of time and tons of nerves in the process, and with actual tangible benefits sooner than later?
Well, there is no single correct answer. But you have to start by recognizing the problem. And then all the bright people already employed by your company will undoubtedly come up with multiple ideas on how to fix it. And management consultants will certainly provide their solutions as well.
Maybe it will be building more in-house IT capabilities to avoid lost information, maybe splitting large transformation projects into many small ones to tender them out faster with fewer risks. Or maybe it will be deeper and longer-term cooperation with selected vendors to benefit from trust and understanding brought by such partnership. Or maybe something completely different, or maybe a combination of it all. Whatever it is, the first step is acknowledging the problem. Be brave.
While you are here, please check out my new book “The Invisible Complexity.” (note that for shipping to Europe, it is better to use the amazon.de site instead. And the same goes for UAE — use amazon.ae site.)
In the book, I explore how large enterprises’ IT and business functions keep fighting about everything, all the time. Why they do it, what drives them, what goals are set for them, and so on. I dive deep into thinking how various psychological quirks that are part of our human condition are at fault most of the time.
How software architecture choices reflect the pros and cons of particular solutions and the requirements for the enterprise architect, goals set to the IT director, and what the CEO wants to say in the next quarterly earnings call. Everything is always interconnected, and it is a pure joy to try to untangle it all.
There are no magical three-step solutions provided in the book, but it will give you a lot of extra clarity of corporate technology affairs and some tools on how to influence them.
