Readiness Must Be Tested Before Go Live
Implementation approval needs evidence that operations can carry the change.
Test whether people, processes, systems, and support arrangements can work together before authorizing implementation.
Look Beyond Completed Activities
Training has been delivered, procedures issued, and system configuration completed. Yet staff may still be unable to process an exception, obtain an approval, or resolve a failed transaction without the project team’s assistance. Completion records show that preparation occurred; they do not establish that the operation can function reliably.
Readiness assessment examines whether the proposed change works under realistic conditions. Its purpose is to provide an evidence-based decision about implementation, including any limitations, unresolved issues, and support needed during the transition.
Define What Must Be Ready
Readiness criteria should be established before the final implementation meeting. Otherwise, deadline pressure can influence what management is prepared to accept.
The criteria should reflect the change’s operational significance and address:
- People: Can responsible staff perform their tasks and exercise the required authority?
- Processes and controls: Are procedures, approvals, exceptions, and records workable?
- Systems and information: Are access, data, interfaces, and outputs sufficiently tested?
- Support and continuity: Can issues be resolved and essential activities maintained?
Each critical criterion needs an owner and a clear acceptance basis. The depth of evidence should match the consequence of failure.
Test the Work as It Will Be Performed
A demonstration by the implementation team may confirm functionality without establishing that operating staff can use it. Readiness testing should involve representative users completing realistic tasks with the procedures, permissions, and information they will actually have.
Include material exceptions, not only successful routine transactions. For a purchasing process, this could mean an unavailable approver, an invoice discrepancy, or an urgent request outside normal limits. The test should establish whether staff know how to proceed, who can decide, and what evidence must be retained.
Record failures, corrective actions, and retest results. Attendance at training should not substitute for demonstrated ability to perform a critical task.
Reflect the Conditions at Each Location
Readiness at one location does not establish readiness everywhere. Staffing, transaction volumes, access to information, and local support may differ sufficiently to affect implementation.
For assignments in Yemen, assess the operating conditions relevant to the locations concerned. Where material, these may include connectivity, power availability, access to equipment, and the ability to obtain timely technical support. Test essential arrangements against those conditions rather than assuming that central-office results apply throughout the organization.
A phased rollout may help contain exposure and generate useful evidence. Each phase still needs defined entry criteria, an operational owner, and a basis for extending implementation.
Make the Implementation Decision Explicit
Not every unresolved issue should prevent implementation. Management should distinguish critical gaps from matters that can be managed within an authorized, time-bound arrangement.
Possible decisions include proceeding, proceeding within defined limits, or deferring implementation. A conditional approval should identify the remaining exposure, responsible owner, temporary controls, resolution date, and circumstances requiring escalation or suspension.
Temporary arrangements should not bypass mandatory requirements. Nor should a project’s completion target determine whether a material operational weakness is acceptable. The authorized decision-maker needs sufficient evidence to understand the consequences of proceeding.
Support the Transition After Launch
Readiness approval is a decision at a point in time. Early operating experience may reveal problems that testing did not expose.
Before launch, establish issue-reporting routes, support responsibilities, and indicators that will receive heightened attention. Depending on the change, these may include processing errors, unresolved exceptions, backlogs, access failures, or reliance on manual workarounds.
Where feasible, define fallback arrangements and the conditions for using them. Do not assume that reversing a change will be simple once transactions, records, or external commitments have been affected.
Implementation is better supported when readiness rests on observed performance and explicit decisions. The relevant test is whether the organization can operate the change with acceptable control and support—not merely whether the project is ready to announce completion.