A local government organisation was replacing a storage platform through a competitive procurement. One response was heavily discounted. On the spreadsheet, it looked attractive. The price was aggressive, the vendor wanted the reference, and the commercial pressure to accept the saving was obvious.
During technical review, the design did not stand up. The concern was not that the product was poor. The concern was that the proposed architecture could not satisfy the requirement the organisation had actually documented. Capacity, performance, resilience and growth expectations did not align with what was being purchased.
There is a difficult moment in these projects where the numbers look good and the technical judgement does not. At that point, signing off the design would have been easier politically but wrong professionally. I declined to approve it because the gap between the proposal and the requirement was not a rounding error; it was structural.
The organisation proceeded with the purchase. Six months later, the limitations were no longer theoretical. Additional hardware and associated work were required to reach the capability that should have been present from the beginning.
The additional cost was around £120,000. The cheapest tender had not reduced cost. It had deferred it, moved it into the delivery phase, and removed options from the people who had to operate the platform.
The lesson is not that discounted technology is bad. The lesson is that procurement scoring cannot replace engineering validation. A platform can be a good product and still be the wrong answer for a specific environment.
Engineering lessons
- A low price is not a technical control.
- Procurement should include engineering challenge before the decision is locked.
- The wrong architecture can turn a saving into a delayed cost.