The first quarter of an implementation should change the quality of the program’s commitments. By the end of that period, leaders should understand the intended business outcome, the major dependencies, the evidence behind the delivery plan and the conditions that would require a different approach. A large collection of workshop slides is a weak substitute.
For a program sponsor, the central question is whether the team is reducing consequential uncertainty while establishing a workable delivery system. Configuration can begin early where decisions are sufficiently clear. Other work should wait for a targeted investigation rather than turning assumptions into expensive commitments.
The 90-day structure below is a planning heuristic, not a universal implementation timetable. A small deployment may complete sooner; a complex multi-entity program may need longer discovery. The suggested periods organize attention around evidence and decisions, not a promise that every organization will reach the same milestone on the same day.
“Day one” can mean contract signature, formal mobilization or the arrival of a delivery team. Specify the boundary. A program that has already completed process design and data profiling begins with different evidence from one that has only selected software.
List what is genuinely decided, what is assumed and what remains open. Confirm the business reason for the implementation and the operating consequences of doing nothing. Identify constraints such as a contract end date or seasonal blackout, while distinguishing hard external limits from internal preferences.
Name the accountable sponsor, operational process owners, technical authority and delivery lead. Clarify which decisions each can make and which require escalation. A responsibility chart becomes useful when it resolves an actual question, such as who can approve a change in customer-credit policy or accept a temporary manual control.
Also confirm business capacity. A workshop invitation does not establish that a subject-matter expert has time to prepare, decide, test and train others. Record the expected contribution in calendar terms and resolve conflicts with normal operations before the plan depends on unavailable people.
Use the first period to define a bounded release and the business scenarios it must support. Avoid translating every existing screen or spreadsheet into a requirement before understanding why the work exists.
Select representative scenarios that cross departmental and system boundaries. Include routine work, meaningful exceptions and at least one recovery situation. These scenarios create a shared reference for requirements, architecture, data and acceptance testing.
Inspect the major data sources early. Establish ownership, access, obvious quality issues, historical scope and reconciliation expectations. The objective is not to cleanse every record immediately. It is to discover whether the migration assumption in the plan is plausible and which decisions could change it.
Map external dependencies: supplier access, interfaces, environments, security review, specialist availability and business-calendar constraints. Give each a named owner and a date by which evidence is needed. A dependency with no response from its owner should remain uncertain, rather than appearing as a firm milestone.
The output of this period is a short, decision-ready boundary: what the release will enable, what it excludes, which scenarios prove it and which uncertainties could materially change the plan.
Do not prioritize prototypes only because they are easy to demonstrate. Choose investigations whose results could change scope, architecture, cost or timing. Examples include a disputed data model, a difficult interface, a critical performance assumption or an unusual approval requirement.
Build enough of an end-to-end scenario to expose the boundary conditions. A prototype can use limited data and controlled environments, but it should make clear what is real, what is simulated and what remains untested. Otherwise, a polished demonstration may create more confidence than its evidence supports.
Turn findings into decisions. If an integration cannot supply the required status promptly, determine whether the business can tolerate delay, needs a different workflow or requires a different interface. Do not leave the finding as a risk entry while the rest of the program continues to assume the original design.
Develop acceptance criteria with the people who will use and operate the process. Include the expected result, required evidence, relevant exceptions and recovery behavior. A statement that users will “validate the system later” postpones the definition of success.
Use the third period to revise the integrated plan based on what the team learned. Confirm the release boundary, sequencing, resources, unresolved assumptions and evidence required before go-live. The plan should show dependencies between business decisions and technical work, not just separate workstream lists.
The US Government Accountability Office’s 2015 Schedule Assessment Guide describes an integrated schedule as a model of time that helps assess whether major events and their supporting activities are realistic, and how changes affect the program. Its government-program context does not prescribe a commercial ERP schedule, but the planning principle is useful: a date needs a credible chain of work behind it. GAO Schedule Assessment Guide.
Establish how changes will be evaluated and how progress will be reported. Keep a visible relationship between the business outcome, scenario evidence, remaining work and next commitment. Completed configuration tasks are useful information, but should not be the only sign of readiness.
Decide whether to proceed, narrow the release, extend a targeted investigation or reconsider the approach. A justified reduction in scope can be a successful first-quarter outcome if it protects the core business result and replaces an unrealistic promise with a credible one.
Consider a hypothetical specialty retailer implementing a shared order and finance platform across several locations. The example is illustrative. Its early plan assumes that standard sales and returns can be configured independently, with integration testing near the end.
During the first period, the team selects a cross-location return as a representative scenario. A customer buys at one location and returns at another after the original period has closed. The scenario raises questions about item condition, authorization, stock ownership, refund processing and the records finance needs. It is selected because several operating boundaries meet there, not because it represents every transaction.
During the second period, a limited test reveals that the receiving location cannot reliably identify the original transaction in the proposed process. The issue changes both the integration design and the work employees must perform. The team must decide which evidence is required and how to handle an uncertain match; a generic “returns supported” requirement is insufficient.
By the third period, the program has revised the interface scope, added explicit exception handling and assigned business owners to the acceptance scenarios. It also changes the delivery sequence so transaction identity is tested before broad returns configuration is declared complete.
The first quarter has not necessarily produced a live system. It has produced a better-founded commitment and reduced the chance of discovering a material operating gap during final testing. The program should record what the limited test did not establish, including scale and all relevant transaction variations.
Maintain an outcome-and-scope statement, a decision log, a dependency map, representative scenarios, a risk-and-assumption record and an integrated plan. These artifacts should refer to one another rather than repeat the same information inconsistently.
The decision log should record the question, options, accountable owner, evidence, outcome and conditions that would justify revisiting it. The dependency map should show what blocks what and who can unblock it. The scenario set should connect requirements to observable business results.
Keep the artifacts proportional to the program. A small implementation may use a concise shared document and a manageable task board. A large program may need stronger configuration control and formal assurance. The test is whether the records help people make and execute decisions, not whether the methodology appears sophisticated.
Retire information that is no longer useful, while preserving the history needed for accountability. An assumption that has been resolved should become a decision or verified fact, rather than remaining indefinitely on a risk register.
Early delivery pressure can encourage teams to report activity instead of uncertainty. Sponsors should ask what has been learned, which assumption changed and what decision is now better supported. An unpleasant finding can be valuable progress if it arrives before a costly commitment.
At the same time, discovery needs discipline. Repeated workshops without a decision, test or clearer boundary can become a way to avoid commitment. Give each investigation a purpose, owner, expected evidence and point at which management will act on the result.
Do not demand false precision from early estimates. Show the assumptions and ranges that matter, and explain how planned investigations will narrow them. A detailed schedule based on untested dependencies can be less useful than a shorter plan that honestly identifies its constraints.
At the 90-day review, ask whether the business can explain the release it is funding, the work needed to deliver it, the evidence already obtained and the conditions that would change the decision. If those answers are stronger than they were at mobilization, the first quarter has done its most important job: making the next commitment more credible.
