Custom enterprise software · 2009
Epico ERP: taking over the defect stream before taking over the code
Offshore delivery for an ERP vendor: the first three months took over the full test and defect stream, then module development, with module handover completing in November 2009 and defect counts and critical defects both falling.
The situation
Epico sells an ERP system used in manufacturing, distribution, services, retail and hospitality. Its product was mature and its own engineering team was established. What it wanted was additional capacity — which sounds like a staffing problem and is usually a trust problem wearing a staffing problem’s clothes.
Handing modules of a live commercial product to an outside team is a risk the client’s engineers have to price in. They cannot see how you work, they cannot see what you do when a fix turns out to be a design problem, and they cannot see whether you will tell them. Most offshore engagements begin by answering that with a slide deck. This one began with a different arrangement.
The call we made
We asked for the defect stream first, not a module. The conventional entry is a small, isolated piece of new work — something that cannot break anything, so the client can observe you safely. We proposed the opposite: for the first three months, take the entire test and defect stream of their existing product, and be measured on it.
Two things happen when you do that. First, the client’s team can see the only evidence that actually matters: whether you can find, reproduce, fix and explain failures in their code without breaking something else. Second, and this is the part that pays back later, you learn the geography of the codebase — which modules are fragile, where regressions cluster, which areas have thin test coverage, which “quick fixes” are load-bearing. That knowledge does not exist in documentation. It exists in the defect history, and you only get it by owning the defects.
Writing new modules where nobody can see you is easier. It is also a slower route to being allowed to touch anything that matters.
The defect trend was the governance instrument. Instead of milestone presentations, the weekly defect numbers — open, inflow, criticals — were the standing agenda item, and release decisions were tied to them. This is what makes a claim like “defects and critical defects both declined” a measurement rather than a sentence in a case study. It also settled arguments quickly: when a release decision is anchored to a visible trend, nobody has to win a debate about whether the code is ready.
Modules moved one at a time, and the client kept the veto. No big-bang transfer, no parallel teams quietly diverging. A module moved to the offshore team when that team could pass the regression suite for it and the client’s owner agreed. By November 2009 all modules had been handed over — not because a date arrived, but because each one had met the condition. Iterations stayed releasable: every iteration ended in something that could ship, which over a year of work matters more than the scope of any single one.
Across time zones, decisions were written down. The working rhythm was a daily sync plus an iteration review, with decisions recorded so that the next morning was not spent re-deciding what had already been settled. On a distributed engagement the expensive failure is not a missed meeting, it is an undocumented agreement that two teams remember differently.
What we built
- Full test ownership — the regression suite for the product, reproduction standards so a defect report is actionable, and triage rules that separate real regressions from environment noise.
- Defect fixing with root-cause notes — each fix carries what actually failed, not just what was changed, so the same class of defect stops recurring.
- Module-level development and refactoring — new work and structural work inside an existing product, keeping the client’s conventions rather than importing ours.
- Release quality gates — per-iteration releasable output with the regression suite as the gate.
- Defect trend measurement — open, inflow and critical counts tracked over time, used as the basis for release decisions.
- Module-by-module handover — a repeatable transfer procedure, with the client’s team retaining ownership until the condition was met.
Result
Three months to take over testing and the defect stream. By November 2009, all modules had transferred to the offshore development centre. Over the engagement the defect count and the count of critical defects both fell, and the client’s release cadence became something the team could plan against rather than something that happened to them. The cooperation ran for more than a year continuously, which for an ODC is the only review that counts.
What we would say to anyone considering this route: the first three months feel like a detour. You are not shipping features, you are reading other people’s failures. But it is the fastest honest way to earn the right to change a product someone else built — and it gives you the one thing a new team cannot otherwise have, which is a map of where the code actually hurts.
Technology
| Stack | Offshore development centre · Agile iterations · Regression test ownership · Defect triage and root-cause notes · Module-level development and refactoring · Quality gates per release |
|---|---|
| Delivery model | Offshore development centre, agile iterations, cross-timezone |
| Client | Epico — ERP software provider |
| Status | Delivered |
What we cannot show
The product is under NDA: module names, defect counts, release dates and client engineering detail are not published. The two screens are module views with data removed.
Similar problem?
If this looks like something you are dealing with — a legacy system that must keep running, a workflow no product covers, an integration nobody wants to touch — send a short description. We will tell you honestly whether we are the right team, and what the first two weeks would look like.