tzlee.com/blog

Tag: tender

  • Why Government Tech Tenders in Singapore Needs Revamp

    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.

  • Why IT tender and PIC is bullsh*t

    Why IT tender and PIC is bullsh*t

    This is in response to Ben’s note on Faecbook.

    No money, no honey.

    Businesses have limited budget for technology as it is a usually a cost center (regardless if it is classified as CapEx or OpEx) unless the business is like Uber where technology drives the business profits. The quality of a technology is often intangible and difficult to measure, and so the pressure is on the price. This is a sad fact.

    If you can’t beat them, join them?

    It is a battle day-in and day-out on my job to either convince customers (very difficult) or to beat cheaper vendors by price (easy) simply because, like it or not, I am running a business and not a charity and I need to pay salaries. As an unfortunate result of price competition, I may not be able to deliver the quality of work that I desire. I cannot afford to spend all my time trying to deal with customers who do not appreciate the value of good technology and that is also the reason why I tend to be selective with my customers.

    What’s (not) cheap and free?

    What needs to be fixed is the notion that technology is cheap and consulting is free. This bullsh*t idea started with the Singapore Government and has trickled down to several MNCs and Government-linked organisations. I’ve stopped attending long meetings and helping write tender specs only for jobs to be given to the lowest bidder with an outsourced team. Not forgetting it usually takes forever to get a bid out, then when the bid is awarded, they are behind time and want it done now.

    Even if a tender comes in with a spec, it is often terribly written and participating in a bid is a hell lot of paperwork with not much money to be made, and on top of that — many unknowns and liquidated damages to bear.

    Tenders only make sense for off-the-shelf and boxed products and should go away for bespoke products and consulting work. Nobody walks into LV or Prada to pick the lowest bidder.

    The fever medicine dilemma.

    Try going to a pharmacy and say: “I want a drug that reduces my fever.” There are easily 3-4 different types of medicine with different applications, strengths, safety and side effects. Most of us only know Panadol, but is that really what we need?

    You see, even with well written specs (not usually the case), no two bids will ever be exactly the same (except maybe for boxed software licenses, like Microsoft Office.) How can price be a major selection criteria? Such a notion is simply flawed. If you have ever done a home renovation and gotten quotes from contractors you will know how incredibly difficult it is to have apples-to-apples comparison because every contractor will have their own ideas, style, materials and workmanship. There’s no telling until the actual work is being done.

    IT projects are many times more complicated, and more often than not there will be changes to specifications as the project progresses (which brings me to a different discussion about not billing by project and scope but instead by time.)

    I can say with confidence and years of experience that technical specifications do not and can not normally prescribe software quality.

    Free legal advise.

    Ask a lawyer: “I want to sue this guy; tell me how much it costs.” You will almost always get a range, and it can be a huge range.

    There’s a reason why lawyers charge by time and do not limit themselves to a scope. Software developers and technology consultants are no different: We take into consideration a situation or requirement and analyse them, then we act upon them and then also react on the results. The latter part is often missed.

    Good advisory can save your ass and a whole lot of time and money, but it is very common that businesses expect free consultancy prior to work being done. Working on a software project is not just software alone; there are many moving pieces including the choice of technology (frameworks, databases, etc.), infrastructure design and operational expertise.

    Expecting free consulting is no different than asking a building architect to work for free, and then paying only for the building construction costs. And no, we can not and should not “build in” the costs of consulting into development. They are two different things.

    The graduate stagnation syndrome.

    Let me make this clear that the ones who suffer are going to be the employees of businesses, not the business itself or the bosses. Businesses can and will always find ways to create profits, and if the profits can’t be had from sales, it will come from expenses (i.e. benefits) and salaries. We graduate some 4-5 thousand technology students from Polytechnics and Universities each year. The good firms can not hire everyone. It is not the fault of these young graduates that their skills stagnate over the years — they simply have been put in an environment that does not cultivate their growth.

    As a technologist myself, I understand how good work gives growth and satisfaction to passionate people, and this is also something difficult to measure but will significantly improve corporate culture.

    Which is cheaper: iPad software or waiter?

    With regards to the Productivity and Innovation Credit (PIC): PIC has made a lot of people (aheem, fly-by-night vendors) rich, but it has also made it difficult for people like us who are trying to do real business and deliver good services because we do not actively sell PIC. In our experience, the real customers will never ask: “how much can we claim from PIC?” PIC is a bonus to them — their priority is to get stuff done.

    I’ve seen countless people burnt by PIC and what’s worse is that it gives people an impression that technology acquisition is cheap. We can not use cheap technology (as is the case of a sushi joint with a sub-standard iPad software) to replace a trained employee (waiter). This causes job and salary issues because employees are now measured against “cheap” technology.

    The ABC food market story.

    I met this old man at the ABC food center: He was with his classmates and I got to know him from a car club. I have to make a point here that these old folks aren’t your normal uncles or aunties; their classmates were Goh Chok Tong and Tan Cheng Bok, so they are pretty well off.

    One of his classmates married a wife — I can not remember, but is either Thai or Viet — and he has migrated there to live with her family and has a farm and rice field. He says he hires the locals in the village to work in his farm and he gives away the crops because people are poor. I asked why he did not use technology to help with his farm (agriculture is a very technologically advanced business), and he said something that really struck me — why replace the jobs when there are many poor people there who need the jobs.

    With that, I leave you something to think about.