Run — Deciding when support can take over from the project team

This is the thirteenth and final chapter in "Inside a Large ERP Program." The earlier chapters set out the triple lens the book reads each phase through, then walked scoping, selection, architecture, design, build, testing, authorizations, data migration, reporting, change management, and cutover. This final section deals with the landing: the transition to the Run phase, where the project ceases to be a temporary endeavor and becomes the permanent operational engine of the enterprise.

The illusion of the calendar ceiling

Every large ERP program has a date on a slide marked "Hypercare Exit." In smaller brownfield implementations, this period typically spans a manageable two to four weeks. For complex, global greenfield programs, it stretches to anywhere between one and three months. This timeframe is usually negotiated a year in advance during the scoping phase, driven by industry benchmarks and budgetary constraints rather than actual project realities.

The trap is treating this calendar ceiling as an objective signal of operational readiness. It is not. It is merely a commercial buffer.

When the calendar date arrives, the project team is eager to pack their bags and transition to the next rollout or project phase. The business, meanwhile, is often drowning in a backlog of unresolved issues, yet lacks any measurable framework to contest the transition. Treating hypercare exit as a function of time assumes that stability is something that happens passively as days pass. In reality, an ERP system does not stabilize because the clock ticks; it stabilizes because business processes successfully survive their initial operational cycles.

The two gates of true operational readiness

To secure a stable landing, a program must abandon subjective feelings and calendar dependencies. Hypercare must only conclude when the system and the organization pass two strict, concurrent gates: the Quantitative Gate and the Qualitative Gate.

1. The quantitative gate

The quantitative gate removes emotion from the room by relying on hard trend lines over a continuous, rolling window—typically ten consecutive business days. You do not exit hypercare because you had one good day. You exit because:

• P1 and P2 backlogs are below a strictly defined threshold that the standard support organization is staffed to handle.
• The net volume of incoming incidents is strictly decreasing or has plateaued at a sustainable baseline.
• The rate of defect resolution outpaces the rate of incident creation.

2. The qualitative gate: The matrix of firsts

The qualitative gate acknowledges a fundamental truth of core enterprise software: some business processes are executed daily, while others happen only once a month, once a quarter, or once a year. This is what we call the Matrix of Firsts.

If a greenfield ERP goes live in June, the local support team might successfully handle thousands of daily sales orders and shipping notifications over a four-week period. The hypercare metrics look pristine. But if that organization has not yet executed its first complex month-end close, its first quarterly tax consolidation, or proven its ability to generate year-end reporting assets on live production data, the system is not truly in a "Run" state.

True readiness dictates that hypercare cannot close for a functional stream until that stream has successfully executed its most critical "first-time" operational events under close supervision from the project team.

Structural friction and the handoff failure

The transition from a project environment to an operational environment is rarely smooth, primarily due to structural pressures and cognitive gaps.

In modern ERP delivery, teams are frequently caught in a rolling deployment schedule. The project engine cannot afford to stall; it must move its best resources to the next wave of scoping and design. This creates an institutional rush to force the current wave into the Run phase prematurely. When combined with a highly distributed or offshore support model, the friction multiplies.

Offshore support models introduce structural realities that project management regularly underestimates: longer onboarding ramps, high turnover rates, and a cultural aversion to challenging poorly designed solutions under pressure. When the project team attempts a standard "HR transfer"—handing over a mountain of documentation, functional specifications, and a Jira backlog over a series of brief knowledge-transfer sessions—the model breaks.

A successful transition is not an administrative asset transfer; it is a deep cognitive transfer. A project team troubleshoots an incident by looking at code variables, custom tables, and technical configuration. A business user experiences an incident as a broken process: an invoice that cannot be cleared, a truck that cannot leave the warehouse. If the support team is trained only to look at the bug and the variable rather than the upstream business flow, their competence is effectively neutralized. They will absorb technical debt, struggle to diagnose root causes, and slow down operational velocity.

Shift the center of gravity: Support-first governance

The most effective organizational counter-measure to handoff failure is simple yet radical: who runs the hypercare must lead the hypercare.

Traditionally, the project team owns the hypercare phase, while the support consultants sit in the passenger seat, observing and taking notes until the formal handoff date. This architecture incentivizes bad behavior. The project team, driven by deadlines, implements quick patches and workarounds to make the hypercare metrics look acceptable, knowing they will not be around to support those patches long-term.

Instead, the permanent support organization must take the steering wheel on day one of go-live.

Under a support-first governance model, every incident created after the system cutover lands directly in the support team's queue. The project team is repositioned as a secondary tier of elite engineering support, pulled in only when the core support team identifies a fundamental design flaw or structural defect.

This flip in the organizational matrix forces immediate, active engagement. The support team cannot afford to remain passive spectators because they are actively managing the business's frustration. Concurrently, it forces the project team to deliver cleaner, more sustainable configurations during the build phase, because they know any shortcuts will be immediately rejected by an operational team that holds true veto power over hypercare exit.

The SLA ticketing trap

When a support organization is structured around rigid, outsourced contracts without face-to-face alignment, it inevitably falls into the SLA Ticketing Trap.

Consider an anonymized scenario from a global manufacturing rollout: a critical interface failure prevents a major supplier from uploading pricing updates, stalling production lines. The ticket is opened with a P2 priority. Under the contractual Service Level Agreement, the support partner must acknowledge the ticket within two hours and provide an update within forty-eight hours.

The offshore support consultant opens the ticket, identifies a minor ambiguity in the data field, and changes the ticket status to "Awaiting Customer Clarification." The SLA clock pauses. Three days later, the business responds. The consultant reviews it, realizes it requires an infrastructure check, and routes the ticket to the Basis infrastructure team. The SLA clock resets or pauses during the transfer. The Basis team reviews it, finds the infrastructure is fine, and routes it back to the functional team with a request for more logs.

In one actual enterprise case, a single high-priority ticket underwent 16 consecutive internal owner changes over a span of several months. On paper, every single SLA metric was green. Response times were perfect, acknowledgment rates were flawless, and the dashboard looked spectacular to executive leadership. In reality, the business process remained completely broken for months, until a senior independent consultant was brought into a physical room and resolved the root cause in less than forty-eight hours.

The SLA tool had ceased to be a system for issue resolution; it had become a sophisticated cultural refuge designed to hide accountability.

To shatter the SLA trap, leadership must break the tool's monopoly on communication. You do not fix a broken hypercare phase by adding more fields to a ticketing dashboard. You fix it by establishing high-cadence, small-committee triage meetings held every 48 hours. In these sessions, support managers, functional stream leads, and business process owners review open tickets face-to-face. A ticket cannot be passed to another team without verbal arbitration and immediate accountability. The focus shifts entirely from keeping an SLA clock green to clearing the operational road blocks for the business.

Final reflections on the journey

The Run phase is not an afterthought to an ERP program; it is the ultimate judge of its value.

You do not secure a successful operational lifecycle by throwing more money at an extended calendar window or by expecting an offshore ticketing factory to decipher poorly documented custom code. You secure it by enforcing hard quantitative trend lines, respecting the Matrix of Firsts, establishing support-led governance from the very first hour of go-live, and refusing to let your support organization hide behind the corporate fiction of green SLA dashboards.

With this landing, the long loop that began with Scoping concludes. The software, once an abstract list of requirements on a steering committee slide, is now interwoven with the daily survival of the enterprise. The project ends, the program fades, and the continuous flow of standard operations takes its rightful place.