E-commerce Replatform Case Study: Defect, Change Order or Retainer at a Diesel Parts Distributor

Summary

Trident Engine Supply distributes marine and industrial diesel engine parts internationally, selling online to trade and retail buyers across multiple currencies and shipping regimes.

Its platform rebuild is a fixed-scope engagement worth 345,000 United States dollars, integrating a new storefront with the distributor's order management system, a duties and taxes service, a customer communication platform and a messaging provider.

An engagement that size generates two kinds of pressure that have nothing to do with code quality. The first is defect pressure: at go-live, every difference between what the platform does and what someone expected arrives as a report, and each one is either a defect the builder fixes at no cost or a change the client pays for. The second is adjacency pressure: a business with a capable partner mid-build discovers a dozen unrelated things it would like done, and each request either becomes an uncosted addition to the build or does not happen.

This case study describes the commercial architecture that handles both: a numbered defect and change register with distinct series, and a separate monthly retainer that exists specifically to take work that does not belong to the build at all.

Client details are pseudonymised at the client's request. Figures are as measured.

Background: the two pressures on a fixed-scope build

A fixed-scope contract is a promise about a boundary, and the boundary is under attack from both sides from the day it is signed.

From the client's side, any behaviour that surprises a user looks like a defect, because the difference between a defect and a change is invisible from outside the specification. From the builder's side, every request that can plausibly be read as new scope is a candidate for a change order, and a builder who classifies aggressively converts a partnership into a negotiation.

Poppo and Zenger (2002) find that formal contracts and relational governance function as complements rather than substitutes: firms that write more detailed contracts also rely more, not less, on relational mechanisms. The arrangement described here is that finding as an operating structure. The contract holds the scope boundary and the retainer holds the relationship, and each one works because the other exists.

Holland and Light (1999) place change management among the critical success factors in enterprise system implementation, alongside the technical ones. A build that gets the architecture right and the change process wrong fails commercially while succeeding technically.

Pre-engagement position

Build engagement value: 345,000 United States dollars, fixed scope, in flight.

Systems the storefront integrates with at go-live: four. An order management system receiving orders as structured documents, a cross-border duties and taxes service, a customer communication platform, and a messaging provider.

Classifications available for an incoming request: two, and both sat inside the build contract. Anything that was not a defect had to become a change order against the build, which meant every adjacent idea competed with the build for the same budget and the same delivery team.

Adjacent initiatives with no home: at least eight categories, spanning telephony onboarding, marketing automation discovery, executive workflow automation, artificial intelligence evaluation, ongoing discovery and general overflow.

Mechanism for small asks that did not warrant a statement of work: none. Each one required its own scoping conversation, its own document and its own signature, which is a fixed cost that exceeds the value of a small request.

Reinartz, Krafft and Hoyer (2004) find implementation weakest at the maintenance stage of the customer relationship, and an agency engagement is subject to the same finding from the other side. Initiation is well instrumented, because a statement of work exists for it. Maintenance, which here means everything a capable partner could usefully do between projects, may have no instrument at all, and what has no instrument does not happen.

The build

Phase one: two numbered series, not one list

Go-live reporting runs on two separate registers, and the separation is the control.

Defects carry a D-series identifier. Changes carry a C-series identifier. Each entry is a document rather than a line, carrying reproduction detail, the affected integration and the observed against expected behaviour. By go-live the defect series had passed its seventy-sixth entry.

A change entry can be revised, and revisions are numbered decimally under the parent, so a sixth revision of the twentieth change item is identifiable as such. That is the same problem the quoting revision carries in any engineered-to-order business: a change that is negotiated three times is one change, and a register that treats each revision as a new item over-counts the scope movement.

The series a request lands in is also decided before the work is estimated, not after. Estimating first and classifying afterwards lets the estimate influence the classification, which is precisely the pressure the register exists to remove.

Phase two: the third destination

The register handles requests that belong to the build. The retainer exists for requests that do not.

It is a six-month auto-renewing subscription at 5,000 United States dollars a month, covering roughly sixteen to twenty hours. Hours roll over inside a month and not beyond it. Overage is billed at 250 dollars an hour with prior approval.

What it covers is broad and deliberately unspecific: CRM administration, dashboards, workflows and enablement; telephony provisioning and integration tuning; marketing automation discovery; executive automation planning; artificial intelligence evaluation and proof-of-concept guidance; continued discovery on new initiatives; strategic advisory including quarterly reviews; and overflow work too small to warrant its own document.

What it excludes is narrow and precisely named, which is what makes the breadth safe.

Phase three: the exclusions that make the retainer work

Three exclusions protect the build, and six named initiatives protect the retainer.

Change orders on the build do not come out of retainer hours. Modifications and scope changes to work already under contract go through the change process under that contract. Without this rule the retainer becomes a discount on the build, funded monthly and invisible in any scope report.

Ongoing maintenance of the delivered codebase is excluded, to be scoped separately after launch. Next-generation platform work is excluded and would need its own engagement of comparable size to the current one.

Six specific large initiatives are named as requiring their own statements of work: full telephony and outbound infrastructure, a full migration of the legacy storefront's data into the CRM, a full marketing automation system, a full executive automation system, a full artificial intelligence agent system, and video sales letter automation. Each of those appears inside the retainer as discovery, evaluation and scoping, and none of them appears as delivery.

The distinction is the whole design. The retainer buys thinking about a thing. Building the thing is a separate transaction.

Phase four: a cadence that makes utilisation visible

Weekly asynchronous coordination with a thirty-minute synchronous call. Monthly priority planning with a utilisation review. A quarterly business review.

The monthly utilisation review is the part that keeps the arrangement honest in both directions. A retainer consistently underused is a client paying for capacity they do not need, and a retainer consistently overrun is a builder absorbing unpaid work or a scope boundary that has stopped holding. Reviewing the number every month makes both visible while they are still small.

Wang and Strong (1996) define quality as fitness for the consumer's use, and a utilisation figure has two consumers who need different things from it. The client needs to know whether the subscription is earning its cost. The builder needs to know whether the scope boundary is holding, because sustained overrun may indicate build work leaking across it rather than genuine demand. One number, read monthly by both, tends to surface either condition before it becomes an argument.

Outcomes

Classifications available for an incoming request: from 2 to 3. Defect under the build contract, change order under the build contract, or retainer work outside it.

Registers maintained during go-live: 2, with distinct identifier series and a decimal revision scheme on the change series.

Defect series entries by go-live: past 76, each documented individually with reproduction detail rather than listed.

Retainer: 5,000 United States dollars a month, on a six-month auto-renewing term, covering roughly 16 to 20 hours, with overage at 250 dollars an hour subject to prior approval.

Hour roll-over window: within the month, and not beyond it. A rule that prevents both a bank of unused hours and a month of unpaid catch-up.

Exclusions protecting the build contract: 3. Change orders on the build, maintenance of the delivered codebase, and next-generation platform work.

Large initiatives named as requiring their own statement of work: 6.

Governance cadence: 3 recurring reviews. Weekly coordination, monthly priority and utilisation review, quarterly business review.

Lessons learned

A request has to be classified before it is estimated. Estimating first makes the classification negotiable, because both parties can see what the answer costs. Classifying first makes the estimate a consequence rather than an input.

Breadth in a retainer is safe only when the exclusions are specific. A retainer that lists what it covers and stops there gets read as covering everything adjacent to those words. Naming six large initiatives as needing their own engagements is what allows the inclusion list to stay broad enough to be useful.

The rule protecting the build protects the client more than the builder. A retainer that quietly absorbs change orders looks generous and destroys the client's ability to see what the build actually cost. The scope report stops being true, and nobody notices until the next estimate is built on it.

Roll-over needs a window, not a policy. Hours that never expire become an unfunded liability and an argument at renewal. Hours that expire nightly punish a client for a quiet fortnight. Within the month is a compromise that both sides can hold in their head.

A defect register at this scale is a document set, not a spreadsheet. Each entry carries reproduction steps and the integration it touches, because at seventy-six entries the difference between two similar reports is the detail neither summary contains.

Limits

No business outcome is reported. This describes a commercial and governance structure. Whether the platform performs, converts or sells is not established here, and the engagement structure is not evidence about the platform.

The defect count is a register size, not a quality measure. A build with seventy-six documented defects at go-live may be more rigorously tested than one with twelve, and the number does not establish anything on its own about the code. It is reported as the scale of the register, and no inference about defect density should be drawn from it.

The retainer had not completed its first term at the point described. The terms, cadence and exclusions are as agreed. Whether utilisation settled inside the sixteen to twenty hour band across six months is a question for the utilisation reviews, and the answer is not published here.

This structure suits a particular shape of engagement. A large fixed-scope build running alongside a client with appetite for adjacent work is where the three-way classification earns its complexity. A small project with a defined end does not need it, and adding it would be overhead.

The classification rule still requires judgement. Distinguishing a defect from a change is easy at the extremes and contested in the middle, and no register removes that, although a register does make the contested cases countable. What the structure provides is a place to have the argument once, in writing, before money is attached to the answer.

Nothing here addresses what happens when the two parties disagree. The build contract governs that, and the retainer deliberately does not attempt to.

Conclusion

The technical work in a platform rebuild is the part that gets written about. The part that decides whether the engagement survives is the boundary around it.

A fixed-scope contract without a channel for adjacent work forces every good idea into one of two bad outcomes: an uncosted change order that inflates the build, or a refusal that makes a capable partner look unwilling. Adding a third destination, priced separately and bounded explicitly, is what lets the build stay the size it was signed at.

Poppo and Zenger (2002) find detailed contracts and relational governance reinforcing each other rather than trading off, and the arrangement here is a small instance of that result. The register keeps the contract honest. The retainer keeps the relationship working. Removing either one puts the entire load on the other, and neither carries it alone.

References

Holland, C. P., & Light, B. (1999). A critical success factors model for ERP implementation. IEEE Software, 16(3), 30–36. https://doi.org/10.1109/52.765784

Poppo, L., & Zenger, T. (2002). Do formal contracts and relational governance function as substitutes or complements? Strategic Management Journal, 23(8), 707–725. https://doi.org/10.1002/smj.249

Redman, T. C. (1998). The impact of poor data quality on the typical enterprise. Communications of the ACM, 41(2), 79–82. https://doi.org/10.1145/269012.269025

Reinartz, W., Krafft, M., & Hoyer, W. D. (2004). The customer relationship management process: Its measurement and impact on performance. Journal of Marketing Research, 41(3), 293–305. https://doi.org/10.1509/jmkr.41.3.293.35991

Wang, R. Y., & Strong, D. M. (1996). Beyond accuracy: What data quality means to data consumers. Journal of Management Information Systems, 12(4), 5–33. https://doi.org/10.1080/07421222.1996.11518099

Conflict of Interest Statement

RevOps HQ is the builder in the engagement described and is paid under both the fixed-scope contract and the monthly retainer. The classification rules set out here determine which of those two instruments a given piece of work is billed against, so the firm has a direct financial interest in where the boundary sits. The rules are reproduced from the signed agreements rather than described from memory, and the exclusions that constrain the firm are stated as fully as the inclusions that pay it.

Acknowledgments

The defect and change registers are maintained jointly with the client's own design and quality team, whose numbering scheme the identifiers follow.