Insights

What Good Implementation Plans Signal

Assess a four-week implementation plan, identify the omissions that block launch, and size a first phase the buyer can staff.

By

Updated with a worked example and explicit decision criteria.

A good implementation plan makes a proposed commitment assessable. A calendar can show when a vendor hopes to launch while leaving the buyer unable to decide whether launch is justified. The difference lies in ownership, acceptance evidence, dependencies, and the ability to stop.

I would read the plan as a sequence of decisions: what can be authorized now, what must be learned first, and which finding would change the scope. That produces a more useful assessment than judging how complete the project document looks.

A four-week plan with the wrong final milestone

Hypothetical worked example. A vendor proposes a service that prepares daily reconciliation exceptions. The buyer currently completes the work manually. The following plan is invented to illustrate a review; it does not describe a Haldane engagement or a named institution.

Proposed plan and the decision each stage needs
StageVendor proposalBuyer assessment
Week 1Load sample filesApprove discovery after data access and a source owner are agreed.
Week 2Connect the daily feedRequire completeness checks and an owner for failed arrivals.
Week 3Run a pilotDefine the test cases, reviewer capacity, and acceptance criteria first.
Week 4Launch to all usersReplace automatic launch with a recorded release decision.

The plan contains dates and a vendor project manager. It does not name the buyer's reconciliation owner, explain how missing inputs are detected, or specify what happens to work already in progress when the service stops. I would authorize a bounded discovery phase once its data access is approved. I would not authorize production from this plan.

Suppose the team then proposes a 300-case historical evaluation, including known missing-file and duplicate-record cases, followed by five daily shadow runs. For this example, every run must account for the expected input files, every released exception must have an owner, and no unresolved material discrepancy may enter the official record. These are proposed acceptance conditions for this workflow, not universal standards.

Capacity also changes the decision. At 200 cases a day, a 15 percent exception rate and six minutes per exception create 180 minutes of review work. The buyer can provide only 120 minutes. A 100-case first phase needs 90 minutes on those assumptions and leaves 30 minutes for variability. I would support that smaller phase only after measuring actual review effort and testing a stop and manual handoff. Average arithmetic is a planning screen, not proof that deadline peaks are covered.

Approve the next evidenced step

Approve a phase when its permitted work, accountable owner, dependencies, acceptance conditions, and fallback are specific enough to test. Defer expansion when a missing item could change who is exposed, whether outputs can be trusted, or whether the buyer can recover. Record who can decide that the evidence is sufficient.

In this example, naming the buyer owner, proving input checks, narrowing volume, and demonstrating recovery would change my answer. Adding a polished training deck or a more detailed project chart would not. Those materials can follow if they do not conceal an unresolved operating dependency.

Some changes deserve a smaller plan

An established customer adding a reversible display preference may reasonably use its existing owner, acceptance checks, and recovery process. Requiring a new four-week project would add little. The exception depends on whether data, authority, workload, and downstream effects remain within the previously approved use.

Conversely, a modest interface change that grants write access deserves renewed review. Apparent project size is a poor substitute for understanding what the software can now do.

Planning guidance and operating judgment

The 2023 U.S. interagency third-party guidance, section C.1, ties bank planning to a relationship's risk and complexity. That banking guidance provides context; the proposed plan, thresholds, and approval decisions above are my analysis.