I recently spent a considerable amount of time working with a government client to explore an app development project. We went deep into understanding the problem, brainstorming possible solutions, identifying constraints, and scoping out practical approaches. But just as we were starting to make progress, the project got yanked into the familiar black hole of bureaucracy: a rigid, poorly-defined tender was issued, seemingly designed to tick boxes than solve the actual problem.
This isn’t the first time. But each time it happens, it’s disheartening.
A Process That Punishes Innovation
These government procurement processes are built to be transparent and fair, and rightly so. It would work prefectly fine for buying a bunch of laptops, or constructing a basketball court. But when it comes to technology projects, the structure of these tenders is fundamentally broken. The system rewards those who can respond to overly prescriptive, unrealistic tender documents, not those who best understand or can solve the underlying problem.
Too often, these tenders are written after the agency has already gone out and sought informal advice – sometimes even prototyped or trialed solutions – but instead of incorporating these learnings into an agile, iterative approach, they fall back on old-school waterfall RFPs.
The Problem with Fixed Requirements
Technology, unlike construction or hardware supply, is not a domain where you can define everything upfront. The entire software industry has moved away from rigid requirements-gathering for good reason: we don’t always know the end solution, but we do know the problem we’re trying to solve.
That’s why #Agile practices have become the norm – because they accept uncertainty as a reality and focus on iterative progress toward a shared goal. Yet in the tendering process, government agencies are forced to cast vague assumptions into stone, creating a scope that no vendor can fulfill without overcharging, over-engineering, or outright guessing.
The result? Vendors quote sky-high prices to protect themselves from the ambiguity – or worse, they underquote, win the bid, and the project collapses mid-flight due to unrealistic expectations, scope creep, or misalignment between the stated requirements and actual user needs.
Focusing on Process Instead of Problems
Perhaps the most frustrating aspect is the focus on process over outcomes. So many tenders are framed around implementation timelines, documentation deliverables, and checkbox compliance without clearly articulating the real-world pain points or desired business outcomes.
We should be seeing tenders that begin with:
- “Here’s the problem we are trying to solve.”
- “Here are the constraints and stakeholders.”
- “We want your expertise in helping us figure out the best solution.”
Instead, what we get is a 20-page legal document and:
- “Build X, Y, and Z with ABC tech stack.”
- “Deliver within six months.”
- “Provide five user manuals and a training deck.”
A Call for Change
Singapore has bold ambitions in tech: Smart Nation, GovTech, digital transformation across the public sector. But these ambitions are being held hostage by legacy procurement practices that actively undermine the principles of good software design and delivery.
What we need is a new paradigm for technology procurement, one that:
- Starts with problem statements, not rigid feature lists
- Embraces agile, iterative delivery models
- Allows for co-creation with vendors, not just transactional handoffs
- Encourages value-based evaluation, not just lowest cost or most compliant
Let’s stop punishing good faith collaboration with broken processes. Let’s start solving real problems together.
Because if we keep doing this the old way, we’re not just wasting vendors’ time – we’re wasting taxpayers’ money.
