The $96,000 change order: how a fixed-price engagement absorbed 2,000 more repositories
A bank bought a subsidiary halfway through a $420,000 migration and wanted its 2,000 repositories moved too, before a year-end change freeze. The mechanics of change orders, Work at Risk and Work Exceptions, and the forecast that nearly turned the project red.
Harbor was a clean engagement on paper. Meridian Bank, a regulated bank with three thousand developers, bought a dedicated GitLab instance and hired Professional Services to migrate 8,000 repositories from legacy source control and CI servers, build CI/CD templates for its forty most important pipelines, and train its engineers. The statement of work, SOW-4471, set a fixed price of $420,000 over eighteen weeks, paid on four milestones the customer had to formally accept.
Then, in September, Meridian acquired a subsidiary and wanted its 2,000 repositories migrated too. Different source system. Same year-end freeze. This is how a well-run services team handled it.
The economics of fixed price
On a fixed-price contract the seller's revenue is fixed, so every hour of overrun comes out of margin. A services PM watches two numbers above all: hours burned against progress, and forecast hours at completion.
| Role | Planned hours | Rate | Planned cost |
|---|---|---|---|
| Project manager (16 h/wk × 18) | 288 | $115 | $33,100 |
| Technical architect (20 h/wk × 18) | 360 | $140 | $50,400 |
| Two PS engineers (40 h/wk × 16) | 1,280 | $110 | $140,800 |
| Engagement manager handover, oversight | 52 | $130 | $6,800 |
| Total | 1,980 | $231,100 | |
| Revenue (fixed fee) | $420,000 | ||
| Planned delivery margin | $188,900 (45%) |
Watched weekly: hours used vs % of milestones complete; forecast hours at completion; remediation rate vs the SOW assumption (5%); customer-caused delay days.
Three mechanisms, and one lightweight path
| Mechanism | Harbor example | Approved by | Commercial effect |
|---|---|---|---|
| Written confirmation (no CO) | Swap three wiki migrations for the remaining Java template, same effort | Customer PM, in the shared project | None |
| Work at Risk | Adapt the importer for the subsidiary's source system before CO-1 is signed (40 h), so the extra wave isn't delayed | PS delivery manager | Billed under CO-1 once signed |
| Change order | CO-1: +2,000 repositories, +6 weeks, $96,000 | Meridian's CIO; PS leadership and deal desk | New revenue; budget +450 h |
| Work Exception | Not needed: hours stayed within budget plus CO-1 | — | — |
The change order itself
Original SOW: SOW-4471, fixed fee $420,000, 8,000 repositories, 18 weeks.
Change: add 2,000 repositories from Meridian's acquired subsidiary (different source system), with CI templates for its 6 most-used pipelines, migrated as wave 3b. Extend the end date by 6 weeks to 27 Dec.
Customer responsibilities added: two Meridian platform engineers for repository-owner liaison and first-line remediation from 19 Oct; CAB approval of standard migration batches.
Estimate: 450 h (importer adaptation 60, batches 100, remediation 120, templates 60, PM/TA 110). Basis: pilot productivity of 150 repos per engineer-day and the pre-scan remediation rate.
Price: $96,000 fixed fee, added to milestones M3 ($48k) and M4 ($48k).
Approvals: ☑ PS delivery manager ☑ Deal desk ☑ Customer signature · new PS opportunity created in Salesforce; Kantata project phase added (450 h).
Look at what the change order contains besides a price: the customer's added responsibilities, the basis of the estimate, how payment attaches to existing milestones, and links to the Work at Risk issue and the risk that predicted it. And the structural advantage: because a change order creates a new opportunity in the sales system and a new budget in the project system, scope can't grow without someone deciding to fund it.
Change for free, and money for nothing
Agile delivery inside a fixed price creates a tension. The customer should be able to reprioritize, but the price assumes a scope. A common answer allows the customer to swap backlog items of equivalent size at no cost, as long as the swap is made before work on the item starts. Harbor's wiki-for-template swap was exactly that. Additions that increase total size need a change order. Some agile contracts add the mirror image: the customer may end the engagement early once enough value has been delivered, paying a fraction of the remaining fee.
The forecast that nearly turned the project red
At the 18 October iteration review, Harbor had migrated 2,340 repositories out of 10,000, slightly behind its re-baselined plan of 2,500. Priyanka, Meridian's head of platform engineering, did the obvious calculation in the meeting: about 460 repositories a week over the last four weeks, 7,660 remaining, so about 17 more weeks. That meant February, long after the freeze. If that forecast were right, the project was red.
Diego's answer was that the straight line extrapolated the wrong thing. The previous four weeks had been wave 1: the most complex repositories (Payments, with its own freeze windows), batches capped at 300 per change-board approval, and only two GitLab engineers. Three things changed from 19 October, all planned when CO-1 was negotiated:
- Meridian's two platform engineers joined for remediation and owner liaison, doubling remediation capacity.
- Meridian's change board approved standard migration batches as a pre-approved standard change, allowing batches of up to 1,500 repositories when the pre-scan showed fewer than 5% needing remediation.
- The remaining waves were mostly small, inactive repositories, with a measured remediation rate of 2.1% rather than 3.8%.
The technical architect presented a capacity-based forecast: engineer-days available each week times measured productivity per repository type. It showed completion around 18 November, with one working day of buffer. That was thin, so Diego reported Harbor as yellow, not green, with a stated trigger: if the total on 1 November was below 4,300, he'd ask Meridian to move the subsidiary's 400 least active repositories after the freeze. On 1 November the total was 4,550. The last batch migrated on 18 November.
Did the margin survive?
At the end of iteration 6, after CO-1, the cost budget was $283.6k (2,430 hours). With $164.6k spent and 59.5% of the weighted backlog done, the cost performance index was 1.025 and the forecast cost $276.7k, against revenue of $516,000 ($420,000 plus $96,000). Forecast margin: about 46%, slightly above the 45% target.
How students practice this
In week 14, students write a change order with a basis of estimate and payment schedule, decide between written confirmation, Work at Risk, a change order and a Work Exception for a set of scenarios, and defend a capacity-based forecast against a straight-line one in front of a skeptical “customer.”
Adapted from Projects, For Real, chapters 20, 25, 36, 37 and 38. The projects, people, vendors and numbers are the book's fictional case studies, set against GitLab's publicly documented practices. Gantt Guild is not affiliated with GitLab Inc.
