Launching a critical system like the Baltic Balancing Capacity Market (BBCM) on time and on spec is a victory in its own right, but it’s not the end of the story. In fact, day one of operations and the following weeks were the real proving grounds for this project.
Nowadays, a successful project handover means more than just a solution that works today. It means the project will continue to work tomorrow, adjusting to new demands, resolving issues before they escalate, and growing with its users and the market.
In this final part of our series, we look at how the BBCM fared after go-live and distill six practical criteria that separate a good delivery partner from a risky one. You can use these as selection criteria: if a bidder cannot show how they will run these practices in the first 90 days, the headline price should not be the deciding factor.
The BBCM launch itself was part of a larger triumph. The broader Baltic Synchronization program - which severed the grid from Russian control and linked it to Europe - has been named Project Management Institute (PMI)’s Project of the Year in the construction/infrastructure category, making it one of three finalists for the overall 2025 award.
Delivered to the three Baltic TSOs AST, Litgrid and Elering, BBCM was a small but vital piece of that puzzle: the software platform that enabled the new hardware and cross-border links to actually function together as part of a seamless system. Thanks to solid preparation and delivery (as covered in Part 1 and Part 2), the platform went live in early February 2025, right on schedule. Here we examine what happened after the spotlight moment - how the system was maintained and improved once it was in the hands of real users.
6 lessons for lasting success
The project provided some clear lessons TSOs can take away when selecting a vendor for a major IT project. After all, delivering the system is only half the job. For long-lasting success, you must also pick partners who can keep it healthy after go-live. Use the six criteria below in evaluations and contracts, and ask bidders to show how they will run these in the first 90 days:
Stay close to the users.
Keep regular touchpoints with control rooms and market teams. Turn real questions into written rules and backlog items, then confirm changes with short demos so adoption stays high.
Separate issues from ideas.
Log incidents and change requests in different lanes with clear severity and priority. Incidents follow the fastest safe path to fix. Improvement ideas are sized, ranked, and scheduled.
Use a living backlog.
Give joint ownership to the client PM and the vendor lead. Review on a fixed cadence and tie each item to acceptance criteria, effort, and expected benefit so everyone knows what ships next and why.
Protect the core.
Run changes through staging with automated regression, realistic load checks, and a cutover checklist. Release only after joint user acceptance so the control room stays calm on go-live day.
Plan for the future.
Track upcoming rules and assets. Keep services modular and interfaces clean so regional updates like COBRA or new resources, such as batteries, slot in through regular releases, not new programs.
Stability is key after go-live, but so is momentum.
The best vendors don’t simply react to tickets, but use industry and technical context to suggest improvements, challenge assumptions, and surface better options before they become requests. That’s how a platform keeps getting easier to run while the market around it moves.
A clean landing
The best-case scenario after a go-live is quiet - no fire alarms, no overnight crisis calls. BBCM’s post-launch period was precisely that. There were no critical errors or major problems, which is unusual for such a complex, multi-party system. This clean landing surely did not depend on luck, but was the result of rigorous testing (including intense stress tests), thorough user involvement during development, and proactive vendors with the experience to identify potential pitfalls and suggest design improvements. Every feature had been demonstrated and accepted by the Baltic TSOs before cutover, so the operators knew what to expect. Minor wrinkles appeared, as they always do, but were handled in stride. Most early support focused on helping users adapt to new workflows rather than fixing defects.
Crucially, the project’s phased approach meant that the essential functionality was rock-solid on day one, and enhancements could be layered in without disrupting operations. The Extended phase (Stage 3) went live on October 1, 2025, delivering the final predefined improvements, including preparations for 15-minute market time units and staging upgrades that protected the grid-independence deadline while still advancing capability.
Supporting front-line users
In the weeks after commissioning, the project team remained in close contact with the TSOs to embed the new system into daily routines. Regular check-ins and a responsive help desk gave users confidence that any questions or hiccups would be addressed before they could become issues.
For example, if an operator wasn’t sure how a particular auction rule worked in an edge case, experts were on hand to clarify it on the spot. If a participant encountered a confusing interface behavior, the design team noted it and considered adjustments. This proactive support prevented misunderstandings from escalating into disruptions.
Because the core system was reliable, the Baltic TSOs could focus on operational readiness rather than firefighting. The result was a smooth adoption: within a short time, the platform became simply part of the furniture in the control room, doing its daily job.
Change requests done right
Every project manager knows the saying: No plan survives first contact with reality. After go-live, real users inevitably think of new features or refinements that didn’t surface during design. Far from being a problem, this is a sign of engagement—people are thinking creatively about how the system can better serve them. The BBCM experience was no different. As one team member put it, “appetite comes with eating”—once the operators started using BBCM in earnest, a few ideas rose in value. A few original requirements turned out to be less critical than initially thought.
Often, these early change requests focused on user convenience or improved analytics. For example, the TSOs soon asked for enhanced reporting tools to let them slice and dice market data more comfortably. As in earlier project phases, the vendors introduced their own innovative ideas to make the solution even better.
The key was having a change management process that could harness these ideas without jeopardizing the timeline or the budget. In BBCM’s case, a dedicated change request (CR) budget was part of the plan from the start. This meant that when a Baltic TSO asked, “Could we tweak this workflow to save us an hour each day?”, the team had a mechanism to respond within the project framework, rather than deferring everything to a Phase 2 or - worse - saying no outright.
Each CR was logged, assessed for impact, and approved if it added value within the reserve; lower-value features gave way to higher-value gains. The reserve was used fully without overrun, and dates held. After the main budget closed, the rhythm continued under support and continuous improvement: minor tweaks to validation, messages, and reports; occasional larger items scheduled through the same triage and planning. Everyone understood the rules: priorities, effort, and benefit decided what shipped next.
Keeping an eye on the horizon
One reason to get change management right is that the world doesn’t stand still. Particularly in today's energy markets, regulatory and technical evolutions are constantly emerging. A well-managed system not only handles today’s needs but anticipates tomorrow’s. For instance, not long after BBCM’s launch, all three Baltic TSOs joined the European platform for trading automatic frequency restoration reserve (aFRR) energy, a project known as PICASSO. This meant coordinating the capacity market (handled by BBCM) with a new real-time energy activation platform - a multi-system challenge navigated without issue because the groundwork for interfaces and data sharing had been laid early.
Looking forward, an even more ambitious integration is on the radar: COBRA. The Common Optimization of Balancing Reserves & Cross-Zonal Capacity Allocation (COBRA) initiative is a cooperation of 14 TSOs (including those in the Baltics and Nordics) to harmonize how reserve capacity is shared across regions.
BBCM’s modular services and clear APIs are built to absorb regional alignment through normal releases rather than rewrites; the optimization component, developed with N-SIDE, already supports efficient cross-border allocation within the Baltics. When a common scheme matures, BBCM can adopt it through an incremental update path.
Continuous improvement is the new normal
If there’s one takeaway from the Baltic balancing platform journey, it’s that you should treat go-live as the beginning of a new phase, not the end of the project. Modern IT systems, especially in the fast-changing energy sector, require continuous nurturing. The reward for setting up a sound change management process is that enhancements actually get done and benefits continue to accrue long after day one. In BBCM’s story, the platform grew more useful over time, meeting new needs as they appeared, all while keeping the (literal) lights on.
For the Baltic TSOs, 2025 will be remembered as the year they gained grid independence and a cutting-edge toolkit to manage it. The PMI accolades are nice recognition, but the real success is operational: a regional market that runs reliably every day and is ready for what tomorrow brings. By paying attention to change management, the TSOs turned a one-time project into a lasting capability. And that might be the ultimate lesson for any large IT project: the finish line isn’t when you go live - it’s when you’ve achieved sustained value. Manage your changes with that in mind, and you’ll find that the end of a project can truly become the beginning of continuous success.
