Choosing the Right Implementation Strategy

The Right Strategy Begins with the Business

The same enterprise solution can succeed under one rollout strategy and struggle under another.

A capable project team may still face an impossible transition if too many users, processes and dependencies must change at once. A carefully phased program may also struggle if every release creates another temporary interface and another manual reconciliation.

The implementation strategy determines how the organization moves from its current operating model to the future one.

Chapter 1 established the purpose of enterprise transformation. Chapter 2 explained the ten-stage implementation lifecycle. This chapter addresses a decision that influences every stage: how should the transformation be delivered and introduced into the business?

The answer must connect People, Process, Data and Technology.

A strategy is credible when the organization can explain what will change, who will change first, what must remain connected and what evidence will justify the next step.

3.1 What an Implementation Strategy Must Decide

An implementation strategy is broader than a go-live schedule.

It establishes the scope of each release, the order of deployment, the treatment of legacy systems, the balance between a common solution and local requirements, and the resources needed to sustain the transition.

It should also establish how benefits will emerge and how leadership will respond when evidence changes.

Consider a company introducing project management, resource planning and financial integration across several business units.

“Deploy one business unit each month” sounds like a strategy. Yet it leaves essential questions unanswered.

Can employees work across units? Can one project receive time from resources already using the new system and resources still using the old one? Which system controls customer and project identifiers? How will consolidated reporting remain reliable?

The release schedule becomes meaningful only after these operating questions have answers.

A useful strategy therefore includes scope boundaries, dependency assumptions, readiness criteria, decision authority, coexistence arrangements and a route to the final operating model.

The target is not simply a sequence of deployments. It is a sequence of viable business states.

3.2 Separate Rollout Strategy from Delivery Method

Teams sometimes describe their strategy as “Agile” and assume the deployment question has been answered.

These are different decisions.

The delivery method describes how work is planned, designed, built and validated. It may use iterative sprints, sequential stages or a combination.

The rollout strategy describes how users and operations move into the new solution.

A team can build through short iterations and still introduce the completed scope to one business unit in a single cutover. Another team can use formal design approvals and deploy across several waves.

A pilot is a controlled first deployment used to test assumptions before wider adoption. Parallel operation is a temporary arrangement in which old and new processing overlap. These concepts can form part of a wider rollout strategy.

Keep the vocabulary precise.

“Hybrid” should identify which approaches are combined and where. “Agile” should not become a reason to leave business readiness undefined. “Pilot” should not mean an unfinished system placed into production without normal controls.

The ten-stage lifecycle remains applicable under each approach. Strategy changes how the work is grouped and repeated, not the responsibility to validate it.

3.3 Big-Bang Implementation

In a big-bang implementation, the agreed deployment population moves to the new solution at one coordinated transition.

Always define that population. A single business unit can have a big-bang cutover within a wider phased enterprise program.

This approach concentrates the transition. It can reduce the period during which old and new operating models must coexist, but it also concentrates the consequences of incomplete readiness.

Consider a distribution company with one warehouse, one finance team and tightly connected purchasing, inventory and sales processes.

Splitting these processes across systems might require complex temporary controls. A coordinated transition may be reasonable if the organization can reconcile opening information, rehearse the full cutover and support all affected roles.

The decision still needs evidence.

What is the maximum tolerable interruption? Can the migration and reconciliation fit within the transition window? Can the business process incoming orders if the planned restart is delayed?

A common weakness is confusing organizational simplicity with technical readiness. One site can still contain complex integrations, poor data and a heavily customized solution.

Leadership question: can the whole deployment population reach the required readiness together, and can the business absorb the consequences if the transition takes longer than planned?

3.4 Phased Implementation

A phased implementation introduces the solution through several releases. The phases may follow business units, locations, capabilities or another defensible boundary.

Its value depends on what can operate independently.

Consider a services organization whose business units use the same project controls but maintain separate billing operations. A business-unit sequence may allow learning and support effort to be concentrated.

Now change one assumption: all units share projects, resources and a central billing process. The same sequence may require substantial coexistence design.

A smaller deployment is not automatically a smaller business risk.

Before approving a phase, trace its transactions across the boundary. Identify the data exchanged, the process owner, the authoritative system and the reconciliation required.

Each phase should deliver an operable scope. Deferring a dashboard may be acceptable. Deferring the only control that prevents duplicate billing may make the release incomplete.

Plan the final phase as carefully as the first. A program can deliver early value while leaving the most difficult entities permanently dependent on legacy systems.

Leadership question: does each phase create a complete operating state, and is the cost of maintaining the intermediate states justified?

3.5 Choosing the Boundary of a Phase

The organization chart is a useful starting point, but it should not determine the rollout boundary by itself.

By business unit

This can align readiness ownership with accountable business leaders. It becomes harder when units share transactions, operational teams or master data.

By country or legal entity

This may group local processes, language needs and accounting responsibilities. Shared services and cross-entity transactions still need an explicit treatment.

By site or warehouse

This can focus training and on-site support. Transfers between migrated and unmigrated sites must remain traceable, including inventory ownership and in-transit positions.

By capability or end-to-end process

This can release value incrementally when the capability has a workable boundary. It requires attention to the activities that precede and follow it.

By module

Module boundaries are convenient for delivery teams but may divide a business process. Procurement, inventory and Finance cannot be treated as unrelated simply because separate consultants configure them.

Take a warehouse rollout. Receiving goods in the new system while purchase orders and supplier invoices remain elsewhere creates a process spanning two systems.

That can be designed, but the design must explain how receipts are matched, corrections are handled and missing transactions are detected.

Choose the boundary after understanding the process, not before.

3.6 Pilot Implementation

A pilot is a bounded deployment chosen to generate useful evidence before wider rollout.

The best pilot is not automatically the smallest unit or the most enthusiastic group.

It should represent the important conditions the program needs to learn about, while keeping operational exposure manageable.

For a project-management transformation, a useful pilot might include different project structures, billing arrangements, resource roles and approval exceptions. A unit containing only simple internal projects may tell the team little about customer billing.

Define the pilot hypothesis.

For example: “The common project structure supports both short consulting assignments and longer delivery engagements without separate custom designs.”

Then define the evidence required to accept or reject it.

Include representative users, realistic data, business cycles and support demands. Record which conditions the pilot does not cover.

Pilot success does not establish readiness for every other country, entity or business unit. Additional scenarios may require further validation.

A production pilot needs the same discipline over security, cutover, data and support as any other production release.

Leadership question: what uncertainty will this pilot reduce, and what evidence must be available before the next wave is authorized?

3.7 Parallel Operation

Parallel operation can help compare results while old and new processing overlap. It also creates additional work and the possibility of inconsistent records.

The team must define what “parallel” means.

There is a significant difference between entering live business transactions twice and using a controlled copy of transactions to compare calculations.

Suppose Finance wants to compare a new project profitability report with its existing report for an agreed period. A shadow comparison may be sufficient. Both systems do not need to issue customer invoices.

Define the authoritative system for every relevant record and output.

Who may update customer details? Which system issues the final invoice? How are corrections reflected? Which report is used for official business decisions?

Suppress duplicate external effects where appropriate. Comparison activities should not accidentally send two notifications, create two shipments or post two financial transactions.

Agree the comparison population, explanation of differences, responsible owners and exit conditions.

A parallel run should have a clear purpose and a clear end. Otherwise, the temporary arrangement can become permanent extra work that hides adoption problems.

Leadership question: which specific risk requires parallel validation, and can the organization control duplicate processing while obtaining that evidence?

3.8 Hybrid Implementation

A hybrid strategy combines approaches deliberately.

For example, a program may establish a common solution, pilot it in one representative business unit and then deploy remaining units in waves. Within each unit, tightly connected processes may move together in one cutover.

Another organization may introduce customer-service capabilities incrementally while replacing an inseparable financial process at one coordinated transition.

The value comes from matching the method to the boundary.

The risk comes from complexity that nobody owns.

If different workstreams choose their own rollout approaches independently, their milestones may conflict. A resource-management release may depend on project master data that another workstream plans to migrate later.

Document the overall sequence in business terms. Identify which components remain common, which vary by wave and which temporary connections will be retired.

Every hybrid strategy should be understandable without requiring the reader to reconstruct several separate project plans.

Leadership question: does the combination reduce a specific risk, or does it merely combine preferences without resolving dependencies?

3.9 Comparing the Options

Use the following comparison as a starting point. It is not a substitute for evidence from the actual business.

Several approaches may be feasible. The task is to choose the one whose consequences the organization can manage and whose intermediate states support useful business outcomes.

Do not choose solely because another customer, another partner or a previous project used the same approach successfully.

3.10 Start with Constraints, Then Compare Preferences

Some factors are preferences. Others are conditions that an option must satisfy.

A preferred quarter-end date is different from a confirmed date on which a critical legacy service becomes unavailable. Even a genuine deadline does not make an unready deployment safe; it creates an urgent need for a feasible transition or continuity alternative.

Establish the hard constraints first.

These may include an unavailable coexistence mechanism, an indivisible operational process, a limited shutdown window or a business-critical service dependency.

An option that cannot meet an essential constraint should be rejected, redesigned or escalated before numerical scoring begins.

Then compare feasible options against the factors that matter:

• Business continuity and the scale of potential disruption.
• Readiness of People, Process, Data and Technology.
• Dependencies across systems, entities and business units.
• Time to measurable business value.
• Total transition and ongoing ownership cost.
• Availability of delivery teams, business users and support capacity.
• Learning value and the ability to correct course.

A score can organize judgment. It cannot replace it.

Record the evidence and uncertainty behind each assessment, including assumptions that could change the recommendation.

3.11 A Practical Decision Record

The strategy should be captured in a concise decision record that leadership can review and revisit.

Begin with the business objective and the scope of the decision. Describe the feasible options and explain any options rejected because of constraints.

Record the recommended approach, the reasons for it, the main disadvantages and the conditions that make it workable.

Include named decision owners and the date for the next review.

An illustrative recommendation might read:

“We recommend a representative business-unit pilot followed by two deployment waves. Each unit will transition its complete project-to-billing process together. The recommendation depends on confirmed separation of billing populations, tested shared-resource interfaces and sufficient capacity to support the live pilot while preparing the next wave.”

This statement is more useful than “phased rollout is lower risk.”

It exposes what must be true.

Add the consequences if a condition is not met. The team may need to regroup the waves, change scope, secure capacity or revise the transition date.

Approval should acknowledge the trade-offs. It should not erase them from the record.

3.12 Common Template and Local Requirements

A multi-business-unit strategy must also decide what will remain common.

Chapter 1 introduced the principle: standardize wherever possible and differentiate only where business value requires it.

A common template may define shared processes, data structures, security principles, reporting definitions and integration patterns.

It is more than a copy of the first deployment.

Before treating a pilot solution as the enterprise template, assess whether it represents the broader operating model. A local workaround should not become a global standard simply because it was implemented first.

At the same time, local differences should not be dismissed without investigation.

A genuinely different approval responsibility, operational constraint or statutory need may require a controlled variation. A preference for an old screen layout may be addressed through training or configuration.

Classify the difference, document its reason and assess its effect on the shared solution.

Assign ownership of the template and authority to approve deviations. Reusable improvements should be evaluated for the common design; local exceptions should remain visible and supportable.

The strategy should reduce uncontrolled divergence as the program expands.

3.13 Plan Coexistence as an Operating Model

When old and new systems coexist, the business is operating a temporary architecture.

That architecture needs the same clarity of responsibility as the target solution.

Define where each type of data is created and maintained. Establish identifiers, synchronization rules, timing, error handling and reconciliation.

Consider an employee who supports projects in two business units while only one unit has migrated.

Where does the employee enter time? How are approvals assigned? How does cost reach the correct project? Who detects an entry sent to the wrong system?

These are operating-model decisions.

Document the treatment of transactions already in progress at cutover. New transactions, open transactions and completed history may require different approaches.

For a purchase order, moving only the header without its receipt and invoicing context may create a misleading open position. The migration boundary should reflect the business state, not merely the available file extract.

Every temporary interface and manual control needs an owner, monitoring method, expected lifespan and retirement condition.

Include access to retained history after legacy retirement. Turning off an application should not leave the business unable to explain its prior transactions.

A strategy is unfinished if it describes arrival at the new platform but not departure from the old one.

3.14 Resource Capacity, Cost and Wave Timing

Phased delivery can spread transition effort, but it can also make several demands compete for the same people.

The architect may be needed for a production issue in the first wave, a design decision in the second and discovery in the third. The customer’s Finance lead may face the same conflict.

Build a capacity plan that separates stabilization, current-wave preparation and future-wave work.

Do not assume that the team becomes fully available the day after go-live.

Wave spacing should reflect the business cycles and learning the program needs to observe. A time-entry process may provide evidence quickly; a monthly billing or period-close process takes longer to exercise meaningfully.

The total strategy cost includes repeated migration rehearsals, deployment effort, temporary integration support, dual-system operation, business participation and legacy retention.

Big bang can also carry significant costs through concentrated readiness work, contingency capacity and potential disruption.

Compare the whole transition, not only the development estimate or the first deployment invoice.

When the rollout strategy changes, review contracted responsibilities, effort assumptions, milestones and support arrangements through the agreed change-control process.

3.15 When to Revisit the Strategy

A strategy is a controlled decision, not an untouchable promise.

Revisit it when a material assumption changes: data quality proves worse than expected, a critical interface becomes unavailable, the pilot reveals a missing business scenario or support demand exceeds the planned capacity.

Define review triggers early so reassessment is treated as governance rather than failure.

The response should be proportionate.

A training-material correction may not require a new rollout strategy. A discovery that two planned waves cannot transact independently may require one.

Assess the effects on business continuity, benefits, scope, cost, schedule, resources and the final operating model.

Obtain approval from the appropriate authorities and communicate the revised baseline with reasons.

Preserve Chapter 2’s distinction between progress and readiness. Work completed under the old plan remains useful, but it does not automatically prove that the revised transition is ready.

The objective is to protect business outcomes while adapting delivery to evidence.