In public procurement, the lowest bid can often win the day, but then end up losing the year. Project deadlines can slip, requirements go missing, change requests multiply and the final bill ends up well above the accepted bid price. TSOs and large energy suppliers know this pattern well. But the lesson is simple:
You’re not rich enough to buy cheap!
This first article in our three-part series (before, during, after) focuses on the part most teams rush and later regret. A good tender or RFP is the foundation to a successful project. Get it right and bids will better reflect reality, the partner you pick should deliver, and the chance of the project landing on time and on spec are improved. Get it wrong and you will often pay later through change requests, scope disputes, and delays.
We use the Baltic Balancing Capacity Market (BBCM) as a recent named example because the outcome is public and the lesson is clear. This project was part of the Baltic Synchro, which helped the Baltic countries connect to the Central European Power Grid after disconnecting from the Russian one on February 8th, 2025. Notably, it had an truly immovable date, a complex regulatory context, and cross-border complexity.
BBCM succeeded because the tender work was done with discipline. Requirements were crystal clear and the budget declared in the tender was realistic. Evaluation rewarded credible plans over cheap promises. The estimate of the work required proved accurate in delivery: 100 percent of the allocated project and change-request budget was used, no more and no less. That is extremely rare and exactly what good preparation looks like.
Why the tender determines the outcome
When projects encounter trouble, the visible trigger is often a late decision, unforeseen requirement, or a failed test, but the ground for that outcome is laid much earlier in how the work begins.
It really isn't an easy game with utility projects: First, unique systems rarely come with a clean price tag, and turning goals into requirements that engineers and operators can act on takes time. Procurement, IT and business often sit in different business functions by design, so scoring models are fixed early, and price carries weight. At the same time, feasibility competes for room, as is the case with public frameworks.
Large organizations also bring many voices, which is healthy, but without a named product owner at the customer to sequence and decide, an RFP can sometimes read like everything for everyone. The sections that most need detail, the interfaces between legacy systems and external platforms, often get the fewest lines, and that is often where surprises surface later.
Hold one picture in mind while you read the rest: TSO software is not like driving a new car out of a showroom. It is more like renovating an old house where the walls carry history and weight. You can replace the kitchen, but you still have to respect the plumbing and the load-bearing beams. If you treat the renovation like a catalog purchase, the surprises will arrive when it’s being installed after the contract is signed, and you will pay for them with interest.
What a quality tender contains
A quality tender does three things that may sound simple, but are hard to fake.
Functional requirements that accurately reflect use cases as they will be lived.
Describe what the system must do and how it behaves when something goes wrong. Connect the software to the daily roles around it. Spell out message formats, reconciliation and audit, security baselines, performance thresholds, and acceptance criteria that you will actually use. Give interfaces the space they deserve, since this is often where risk hides. The point is not to dictate design, but to remove ambiguity while building in flexibility so every bidder prices the same thing, and your team will recognize the delivered product. Let’s think back to the house renovation metaphor: How many rooms do you need? How big should the kitchen be? A big fancy, “I never cook” kitchen? A modest, useful kitchen for everyday cooking?
A should-cost and a plausible schedule before going to market.
That sounds obvious, yet many teams skip it because they lack fresh internal references or because a low number on page one feels safer. Bring in people who know the vendor landscape, the going rates, and the patterns that drive effort up or down. With a baseline in hand, you can tell the difference between a credible price and a number that depends on luck. You can ask pointed questions about staffing by role, about the critical path and risk points, and about how performance at scale will be proved, not asserted. In the renovation project, you might have heard from your peers how much a new kitchen would cost nowadays.
An evaluation that rewards fit and credibility.
If price dominates the score, you will end up selecting for or even incentivizing the wrong behavior from bidders. Calibrate the framework so technical merit, delivery approach, team quality, references, and price all matter, and so qualitative judgments are made against written rubrics rather than gut feel or a shiny demo that hides a lack of substance beneath. Check the sizing as well as the story. A trustworthy vendor can still sell you a solution that is larger than you need, like do you really need the airfryer, the steamer, the water cooker, the soup maker, and the oven?
Public buyers in Europe do not have to guess how to do this. The utilities regime allows awards on the most economically advantageous tender, and provides paths such as competitive dialogue when complexity is high. If you want chapter and verse, here’s the European Commission’s summary for water, energy, transport, and postal services.
One thing that also needs to be addressed is the organizational gap that produces brittle tenders. A product owner must be put in charge on the client side, someone who can consolidate input, set priorities, and say no when needed. You can then create a decision-making committee with procurement, legal, operations, and IT that can act promptly during the tender and later during delivery. When business and procurement work as a single team from day zero, the process can be adapted to the problem rather than the other way around.
BBCM: setting the table for success
BBCM began under pressure that would have broken a weaker foundation. The go-live date was tied to a regional milestone. The calendar could not move. Three TSOs - Augstsprieguma tīkls AS (AST), Litgrid and Elering - had to act as one, and the system had to speak fluently to multiple existing tools and external platforms.
Preparation came first. With FORRS and OMNIA - The Plural of Energy guiding the work, the TSOs ran structured sessions that involved operations, IT, market design, and compliance. Vague targets became concrete requirements that a vendor could price and an operator could trust. The documents did not hide the problematic parts. Naturally, product definitions and auction timing were precise, and cross-border rules were spelled out. Exception handling, data ownership, and daily roles were accurate, just as interfaces were treated as first-class citizens, with behavior described not only in the happy path but at failure points and recovery steps. Must-haves were separated from the rest, and lower-priority items were staged so the program could land the essential first.
The team did not ask the market to tell them their price before they had a view of their own. Cost and effort were benchmarked using recent deliveries and current capabilities. From that came a reasonable range and a schedule that a real team could meet. It also produced the questions that separate slide decks from plans: how many people in each discipline, which checkpoints serve as go or no-go, which tests unlock the next tranche, and how resilience and cybersecurity will be demonstrated rather than just described or promised.
Procurement and business stayed close, just like the siblings they are. The evaluation framework prioritized evidence over assertion, which meant that proposals that appeared to be underbaked in terms of scope were scrutinized for specifics. A decision-making group was named in advance, so clarifications did not sit in an inbox while the calendar advanced. The same governance that made the tender strong carried forward into delivery.
When a vendor challenge created and early deadline risk, the project did not lose its footing. The team had a shared understanding of the scope and the path, and once the challenge was resolved, the work moved at a pace. BBCM met all of its delivery milestones and specifications. All change requests were accommodated and the CT budget was used in full but not exceeded. That outcome is rare in complex programs, and it does not happen by accident. It occurs when a buyer knows what they are buying and a supplier knows what they are building, because the tender forces both sides to face the same reality.
It’s the contrast that makes the point
It helps to say out loud what everyone has seen. A poorly prepared tender often produces overruns, hidden costs, missed requirements, and long-term pain. Buyers unfamiliar with the vendor landscape often receive mismatched solutions. Evaluation weights are fixed before the business defines what’s important and what's not. Vendors overpromise and underbid, then make up the difference through excessive change requests. Without a single owner, an RFP becomes a collage that nobody can deliver cleanly. Public tenders often skimp on interface detail, treating a renovation like a catalog purchase. This has procurement becoming something you survive rather than a tool you use.
A well prepared tender produces the opposite. A clear scope means vendors price the same work—realistic costing surfaces risk before they buy a ticket. Balanced evaluation selects the bid you can trust. The time you invest in crafting a better RFP pays off during delivery, resulting in fewer surprises and faster decisions. A named owner and a defined committee keep momentum, and an independent perspective keeps ambition in proportion to capacity. The lesson applies to TSOs, to large energy suppliers, and to any public buyer wrestling with complex systems.
One simple rule to steer by
You simply do not want the lowest bid. You want the bid you can trust and that truly fits your needs, delivering the full product lifecycle at the best cost. Remember that TSOs are not rich enough to buy cheap things. The BBCM project is living proof that with up-front investment in a high-quality RFP and a fit-for-purpose selection process, an aggressive and demanding project can be landed on time and on spec. While this level of accuracy is rare in complex projects, it can be repeatable when you set the table the same way.
What comes next
Everything you read is relevant to the time before the first step in a project occurs. Next, we examine the “during” phase, illustrating how Navitasoft and N-SIDE formed a consortium that enabled each team to focus on its strengths within a disciplined development process. Employing PRINCE2 quality circles, combined with agile test driven development produced an operating model that kept BBCM on schedule, on budget, and on spec.
