Plans do not turn into results on their own. After being awarded, a project either gathers pace and holds its line, or it frays at the edges and begins to drift. It hinges on a delivery structure that keeps attention on the next meaningful slice of scope and turns decisions into action.
Part 1 of our series showed why a good tender sets the foundation. This Part 2 is about what happens next: how you run the work so the plan survives contact with reality and the calendar.
We are naturally biased, but the Baltic Balancing Capacity Market (BBCM) also offers a good lens to outsiders, because it has some constraints that could very well also pop up in your own next project. As part of the ambitious Baltic Synchro program, the Baltic TSOs Augstsprieguma tīkls AS (AST), Litgrid and Elering faced a fixed date tied to grid independence, three operators had to act as one, and a vendor challenge removed about two months from an eight-month build window. The platform still launched on time, on spec and on budget, which tells you the way of working was sound. What follows is how the work moved.
The frame protects the date
A project with a hard finish cannot carry all of its ambition at once, so the team framed the scope in three steps that everyone could understand without a slide: a Minimum Viable Solution to lay the base and expose the risks early, an Essential release that contained everything required for the detachment milestone, and an Extended phase that captured sensible improvements once the cutover was safely behind them. That simple structure changed the shape of difficult conversations.
Instead of endless arguments about whether something was in or out forever, the question became where it belonged. This meant that the calendar stayed safe, value still grew, and the team had permission to keep the important things small.
One team, two specialties
With the BBCM project, ownership was equally clear. Navitasoft led the platform delivery and carried market workflows, integrations, and operator tooling. N-SIDE supplied the optimization component as a modular plug-in and was responsible for its performance. The two teams planned together, maintained a single backlog, and followed a single path to acceptance, ensuring there were no shadow schedules and no guessing at the seams. Inputs and outputs were defined early, joint rehearsals proved the edge cases before production, and what landed felt like one system rather than parts stitched together at the last minute.
Wired to be agile
Agile here was a small set of habits that gave the work its rhythm.
For non-technical readers, think of it as building in small, inspectable sections on a short cycle, with frequent proof that each section behaves as intended. The backlog came first and encompassed every requirement, dependency, and risk in one place. Work was sliced thin enough that progress was visible every two weeks. Sprints ran on a fixed cadence, which kept planning, building, and checking in step. At the end of each cycle, the team showed working software to business users, who confirmed intent and corrected misreads while they were still inexpensive to fix.
Acceptance criteria were written before the code started and used when the code landed, so a story was considered complete when those steps were passed, not just because a status cell turned green. Regular retrospectives removed grit from the gears: if a decision path was slow, the next iteration shortened it; and if an interface was noisy, the next iteration addressed the cause rather than the symptom.
Keeping in touch
The weekly business workshops brought TSO experts and Navitasoft analysts together at the same table to transform rules into behaviors that systems and operators could live with. Auction timing aligned with shift patterns, failure modes reflected what actually happens in control rooms, and interface behavior included slow or partial replies from external platforms rather than only the happy path.
The decisions were recorded once and flowed straight back into the backlog, which meant developers were not building on assumptions and testers were not guessing at intent. On the client side, each central area of scope had a named functional owner who answered questions, set priorities, and accepted work. A small decision board stood ready for approvals and exceptions, so clarifications did not sit in an inbox while the calendar advanced. It was essential that governance remained visible and active, which is why issues remained manageable.
Change with intent
Everyone who has ever been involved in project management knows that no plan survives its first contact with real users without adjustments. As operators saw the system, some ideas rose in value, and a few original items proved less helpful for day one. The project handled this without hand-wringing. A change-request budget was in place for precisely this purpose. Effort moved from lower-value items to higher-value ones inside that envelope. Impressively, not only the cap held and the date held, but the user experience also improved. The change budget was fully used and not exceeded, which is rare in complex programs and is a sign that estimates and reality were aligned.
The entire preparation of the solid tender in Part 1 now starts to pay off big time: a clear scope, a realistic baseline, and a selection that rewarded fit gave the delivery team a solid start. What kept BBCM on track was the way the work was managed after the contract was signed.
- Roles were assigned clearly and explicitly.
- Interfaces did not wait until late in the schedule.
- Evidence arrived every two weeks.
- Users shaped the product as it evolved, rather than filing complaints after it shipped.
- Partners worked towards one single plan.
These are habits any TSO or large energy supplier can adopt within their own constraints.
If you want a single line to steer by, use this: Build the delivery engine before building the product. The engine is the consortium with clear ownership, a phased plan that protects the date, a cadence that produces working software, workshops that make policy workable, and decision paths that keep moving forward.
BBCM, seen from inside the work
To make the picture concrete, imagine just a typical work week:
Monday begins with a short planning session; the backlog already tells the story, so the team pulls the next thin slices that move Essential closer to completion.
Midweek, a workshop settles two edge cases and clarifies a timeout rule that would have caused noise later.
Friday ends with a demo of three working features; operators ask for a minor tweak to a validation rule, and it lands in the next sprint’s plan. Two stories tick their acceptance steps, and one is sent back for a narrow fix; nobody argues because the criteria were agreed in advance. Replace the specifics and repeat that rhythm for a few months, and you have the shape of BBCM’s delivery.
Beyond BBCM
Cross-border collaboration added complexity, for sure, but it also added discipline. Three TSOs agreed on one language for requirements and one method for decision-making, which reduced duplication and ensured consistent choices. Partnership worked for the same reason. Navitasoft and N-SIDE did not invent a new model; they agreed on who owned what, defined the seams clearly, and kept calendars in lockstep. Integration then felt like part of the build rather than a separate project with a late start.
What comes next
Delivery structure is the work to meet the most crucial date which is the launch deadline. BBCM stayed on track because the team protected the date with a phased plan, turned requirements into a living backlog, maintained a two-week rhythm, utilized workshops to transform rules into behavior, and treated change as a value to be traded within an agreed-upon framework.
That is how on time, on spec, and on budget can be actually in arm’s reach, especially when under pressure.
The upcoming Part 3 closes the loop. We will examine what day-to-day operations look like after a platform lands cleanly, how support is organized to ensure issues are resolved before they escalate, and how the solution prepares for what comes next, including COBRA.
