A Software Project Management Case Study: Launching Four Regulated Markets in One Year

Most project management case studies describe a success and stop. The useful ones show the decisions, the framework in use, the thing that broke and what it cost. This is one of ours: the programme that launched four regulated payment markets in a single year at Simpaisa, during which I held the product role and acted as CTO. It is written in the format I would want any case study to follow, and the last section explains that format so you can reuse it.

Context

Simpaisa runs payment infrastructure that connects international merchants and aggregators to local rails (wallets, bank transfers, telecom billing, cards) in frontier markets. Each new market needs regulatory approval, a local settlement partner, integrations to that market's rails, localisation of the product, an operations team ready for that market's failure modes, and a first cohort of merchants. In 2024 the company committed to four such launches in one calendar year, with a product and engineering organisation of roughly fifty people that was also running the existing markets.

Objective and measures

The programme objective was four markets live and processing merchant volume within the regulatory conditions of each licence, by year end, without degrading the existing markets' service levels. The measures: each market live by its target quarter, first merchant volume within thirty days of go-live, no regulatory findings in the first review, and existing-market straight-through processing and uptime held at their standing targets.

The framework

We ran the hybrid described in PMBOK plus Agile: a programme charter and stage-gated milestone plan for the outside audiences (regulators, partner banks, the board), with the engineering teams delivering inside each milestone in sprints.

Each launch was a workstream with the same seven gates: regulatory application complete; approval received and conditions mapped to requirements with owners; settlement partner contracted with a written go-live date; rails integrated and passing end-to-end tests with real partner responses; product localised and compliance sign-off recorded; operations runbook rehearsed with the market's failure modes; pilot merchants onboarded and first transactions reconciled.

The programme layer held a dependency map across the four workstreams, because they shared engineering teams, the compliance function and, in two cases, the same regional partner. A fortnightly steering committee took decisions; a weekly dependency walk took the rest.

What the plan looked like

The four launches were staggered by a quarter each on paper, with engineering capacity split between the launch in flight, the launch in preparation, and the existing markets. Regulatory timelines were planned with the regulator's stated processing time plus a buffer, and the buffer was the first thing to be consumed.

What went right

The gate criteria did their job. Two launches reached a milestone date with the criteria unmet, and both were reported as not passed rather than as green with caveats. In one, the settlement partner's go-live date had slipped and the gate could not be evidenced; the programme re-sequenced the pilot instead of discovering the slip at launch.

Operations readiness as a gate, rather than a task, meant each market's support and reconciliation teams had rehearsed the failure modes before merchants arrived. The first month's exception rates in the new markets were within the range of the established ones.

The existing markets held their service levels. That was the quiet success: uptime and straight-through processing did not move while half the engineering capacity was on launches.

What went wrong

One dependency was noted and not owned. A regulator's approval came with a condition that changed the allowed transaction types on day one, and the requirement change reached product two weeks after the conditions letter, because the mapping from conditions to requirements had an owner in compliance but no date, and the weekly walk did not chase it. The product scope for that market was re-cut late, and the pilot moved by three weeks.

The lesson went into the gate criteria for the remaining launches: conditions mapped to requirements within five working days of the letter, with product as the owner, not compliance.

The second problem was capacity accounting. The plan counted engineering capacity and undercounted compliance capacity. Compliance was on the critical path of all four launches and the existing markets' reporting. The steering committee added a compliance hire earlier than budgeted, which was the right decision and would have been better made a quarter sooner.

Outcome

All four markets launched in the year. Merchant volume arrived in each within the target window. The regulatory reviews in the first period produced no findings. The existing markets held their targets. The programme's post-launch benefits review ran for two further quarters, because "launched" and "operating within conditions" are different outcomes, and the second is the one that matters.

The case-study format, so you can reuse it

A project or programme case study that is useful to someone else contains, in this order:

Context: the organisation, the constraint, the scale, in three sentences. Objective and measures: what success meant, as numbers, decided before the work. Framework: what method was used and why, with the gates named. Plan: the shape, not the detail. What went right, with the mechanism that made it go right. What went wrong, with the mechanism, the cost and the change made. Outcome, measured after the work ended, not at go-live. Lessons that transfer.

Case studies that omit the "what went wrong" section are marketing. The ones that include it are the ones I read when hiring, and the ones I ask candidates to produce.

FAQ

What is a project management case study? A structured account of a real project or programme: the context, the objective and measures, the method used, what happened, what went wrong and what it cost, the measured outcome, and the transferable lessons.

What should a project management case study include? Context, objective with numbers, framework and gates, plan shape, successes with mechanisms, failures with mechanisms and costs, outcome measured after completion, and lessons. Omitting the failures makes it marketing rather than a case study.

What is a stage gate in a software project? A checkpoint with written criteria that must be evidenced before the project proceeds, such as regulatory conditions mapped to requirements or a partner's go-live date confirmed in writing.

How do you manage multiple projects at once? Run them as a programme: a shared dependency map with owners, a single steering committee for cross-project decisions, capacity accounted across all functions on the critical path, and gates that are reported as passed or not passed rather than as colours.

What is the most common cause of project delay in fintech? Dependencies on regulators and partners whose timelines the project does not control, and dependencies inside the organisation that are recorded but not owned.