{"id":3751,"date":"2025-08-05T10:33:57","date_gmt":"2025-08-05T02:33:57","guid":{"rendered":"https:\/\/tzlee.com\/blog\/?p=3751"},"modified":"2025-08-05T22:37:35","modified_gmt":"2025-08-05T14:37:35","slug":"why-government-tech-tenders-in-singapore-needs-revamp","status":"publish","type":"post","link":"https:\/\/tzlee.com\/blog\/2025\/08\/why-government-tech-tenders-in-singapore-needs-revamp\/","title":{"rendered":"Why Government Tech Tenders in Singapore Needs Revamp"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

This isn\u2019t the first time. But each time it happens, it\u2019s disheartening.<\/p>\n\n\n\n

A Process That Punishes Innovation<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

The Problem with Fixed Requirements<\/h2>\n\n\n\n

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\u2019t always know the end solution, but we do know the problem we\u2019re trying to solve.<\/p>\n\n\n\n

That\u2019s 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.<\/p>\n\n\n\n

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.<\/p>\n\n\n\n

Focusing on Process Instead of Problems<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

We should be seeing tenders that begin with:<\/p>\n\n\n\n