MoveLagos Logistics: a custom platform heading for a contractual cliff
MoveLagos Logistics commissioned a custom fleet-management and customer portal from an offshore vendor for ₦480m over nine months, with go-live contractually tied to service commencement for its largest client in eight weeks. At the end of month five the project manager reports planned value ₦250m, earned value ₦150m and actual cost ₦310m. Forty-seven change requests have been raised; 31 were implemented without formal approval because the client said it needed them. There is no automated testing, no separation between test and production environments, and the solution architect resigned three weeks ago. The vendor has written demanding a ₦95m change order before it continues. The client contract carries penalties of ₦12m per week for late commencement, capped at ₦96m. The CEO wants to push to the original date; the CFO wants to stop the project.
1. Calculate and interpret cost and schedule performance indices and the estimate at completion, stating your assumptions. What does the arithmetic not tell the CEO?
Read the worked answer
The arithmetic
- CPI = EV / AC = 150 / 310 = 0.48. Each naira spent is buying about 48 kobo of planned value.
- SPI = EV / PV = 150 / 250 = 0.60. The project has earned 60% of the value planned for this point.
- CV = EV − AC = −₦160m. SV = EV − PV = −₦100m.
- Physical progress against total budget: 150 / 480 = 31%, against a plan that expected roughly 52% at month five.
- EAC = BAC / CPI = 480 / 0.48 = ₦1.0bn, on the assumption that current cost efficiency continues and scope is unchanged. Adding the claimed ₦95m change order on top of that would be double counting if the inefficiency already reflects rework on that scope, so the two figures must be reconciled, not added.
Assumptions to state
Earned value is only as good as progress measurement. Here there are no approved change controls and no automated testing, so the 31% may be overstated.
What the arithmetic cannot tell the CEO
- Whether the earned value is real: unapproved changes mean the baseline no longer describes the scope being built.
- Whether the architecture is sound enough to operate and support.
- The cost of a failed go-live: reputational damage with the largest client, data integrity failure, manual workarounds.
- The probability the vendor can deliver at all after losing the architect.
- The value of the penalty cap: ₦96m is bounded and may be cheaper than an unsafe go-live.
The numbers say the project is in trouble. They do not say which option is least damaging.
2. Recommend a course of action, with decision criteria, to the steering committee.
Read the worked answer
Recommendation: re-baseline and descope; do not chase the original date
A launch in eight weeks, with no automated testing, no environment separation and a departed architect, is not a delivery plan - it is a hope. The penalty cap of ₦96m is fixed and finite; an unsafe go-live is not.
Decision criteria
- Safety and data integrity for fleet and customer records.
- Client commitment: can a phased or manual interim service protect the relationship?
- Cost to complete against the penalty cap and the value of the client contract.
- Vendor capability and willingness, including replacement of the architect.
- Exit and transition cost if the vendor is replaced.
Proposed course
- Impose a 30-day independent review of code quality, architecture and progress claims before any further payment.
- Split scope: a minimum viable release covering the client-critical functions (job allocation, proof of delivery, portal tracking) and defer secondary features.
- Freeze scope formally. No change without a signed change request, impact assessment and steering committee approval.
- Negotiate the ₦95m claim item by item, validating each against evidence; agree a revised schedule with the vendor.
- Open a commercial conversation with the largest client now: a managed manual interim process plus a committed revised date is usually preferable to a failed launch. Budget for penalties rather than pretend they will not arise.
- Institute weekly steering committee reporting on EVM, defects and test coverage.
Stopping entirely is defensible only if the review finds the architecture unsalvageable or the vendor unable to perform; that should be an evidence-based decision, not a reaction to the numbers.
3. Advise on the contractual and control weaknesses exposed and what should change for future vendor engagements.
Read the worked answer
What went wrong
- No enforceable change control: 31 changes were implemented without approval. The contract allowed the vendor to absorb scope informally and then monetise it later through a large claim.
- Payments not tied to evidence: with ₦310m spent against ₦150m of earned value, the payment schedule was evidently linked to time or milestones that were not verified.
- No environment or quality obligations: the absence of test/production separation and automated testing should have been a contractual minimum, not an aspiration.
- Key-person risk unmanaged: the architect's departure should trigger contractual notification and replacement obligations.
- No exit or escrow provisions: the company's leverage if it terminates is unclear.
Changes for future engagements
- A statement of work with acceptance criteria per milestone, and payment released only on verified acceptance.
- A formal change control procedure with a change board, impact assessment and pricing rules for change.
- Contractual security and quality standards: environment segregation, test evidence, code review, penetration testing before go-live.
- Key-person clauses, named roles, replacement rights and knowledge transfer obligations.
- Retention of 10–15% until warranty expiry, source code escrow, and defined termination assistance.
- Independent assurance at design, mid-point and pre-go-live.
Control lesson for the organisation
Project governance failed before vendor management did. A steering committee that receives earned value, change log and test metrics monthly would have seen this at month two, when the options were cheaper.