A product can be finished while the project is not ready.

The software works, but support has not been trained. The equipment passes inspection, but operating procedures are incomplete. The migration is technically ready, but rollback has never been rehearsed. The new service can launch, but the receiving organisation has no capacity to absorb the change. The site is built, but a critical permit is still unresolved.

Project readiness management is the discipline of proving that the whole delivery system—not only the product—is sufficiently prepared for the next consequential transition.

That transition might be entering testing, starting production, launching a service, migrating data, handing over an asset, opening a facility, releasing a publication, beginning operations or closing the project.

Readiness therefore asks a harder question than “Is the work complete?” It asks: Is the project, product, receiving environment, people, evidence, support system and decision authority ready enough for what happens next?

The one-sentence answer

Project readiness management works by defining the conditions required for a consequential transition, gathering evidence across product, people, process, infrastructure, operations and governance, exposing gaps and residual risks, assigning corrective actions, and allowing an authorised go/no-go decision only when the evidence supports proceeding.

1. Readiness is a state, not a meeting

A readiness review may happen on Tuesday at 10:00. Readiness itself is not created by the meeting.

The meeting examines evidence that has accumulated through design, build, testing, training, documentation, rehearsals, operations preparation and risk treatment.

This distinction prevents ceremonial readiness.

If the project begins preparing for the readiness review two days before the meeting, it may be assembling slides rather than building readiness.

Readiness should be engineered through the project life cycle and demonstrated at the decision point.

2. Current PMI terminology: readiness assessment

The Project Management Institute’s current Lexicon of Project Management Terms defines a readiness assessment as an assessment occurring as an organisation approaches solution deployment. Its purpose is to understand how prepared the organisation is for the transition and how ready it is to integrate and sustain the solution. Source: Project Management Institute, Lexicon of Project Management Terms, Version 5.0.

That definition is important because it moves readiness beyond the deliverable itself.

A solution can function technically while the organisation remains unprepared to absorb, operate or sustain it.

3. NASA’s readiness logic: system plus support system

NASA’s operational and flight readiness frameworks provide a rigorous example of the same idea in a high-consequence environment.

Its operational readiness review criteria examine not only hardware and software but also personnel, procedures, user documentation, supporting facilities, contingency arrangements, unresolved anomalies and operational support. NASA’s current program and project management handbook similarly describes readiness reviews as evaluating projects and supporting systems for safe, successful progression. Source: NASA Space Flight Program and Project Management Handbook.

Most projects do not need aerospace-level formality. The transferable principle is powerful: readiness belongs to the whole operating system around the deliverable.

4. Readiness management is not Project Assurance

Project Assurance owns independent or semi-independent challenge of project evidence and controls.

Readiness management owns the work of making the project ready and assembling the evidence that readiness exists.

Assurance may challenge readiness. It should not have to manufacture it.

A strong project can therefore have both:

• a readiness owner coordinating preparation and evidence;
• an assurance function independently challenging whether that evidence is sufficient.

5. Readiness management is not Quality Management

Project Quality Management asks whether outputs and processes meet defined requirements and are fit for purpose.

Readiness asks whether the wider system is prepared to use, support, sustain and govern those outputs at the next transition.

A technically conforming machine may still be unready if operators are untrained.

A correctly tested application may still be unready if monitoring, support, rollback or user communication is missing.

Quality is necessary for readiness. It is not the whole of readiness.

6. Readiness management is not Closure and Handover

Project Closure and Handover owns the transfer from temporary delivery into stable ownership and operations.

Readiness management asks whether that transfer is safe and credible before it occurs.

The two connect directly:

readiness evidence → go/no-go decision → controlled handover → operational acceptance.

7. Readiness is transition-specific

A project is not simply “ready” or “not ready” in the abstract.

It is ready—or not ready—for a specific next state.

Examples:

• ready to begin detailed design;
• ready to procure;
• ready to integrate;
• ready to test;
• ready for pilot;
• ready to launch;
• ready to migrate;
• ready to hand over;
• ready for normal operations;
• ready to close.

Each transition requires different evidence.

8. Define the transition before defining the checklist

Readiness checklists become generic when the project has not defined what decision the checklist supports.

“Launch readiness” should answer a specific question:

Is the product and operating environment prepared to expose real users and operations to the new state within the authorised risk tolerance?

“Test readiness” answers a different question:

Are the test item, environment, procedures, data, personnel, instrumentation and success criteria sufficiently prepared for valid testing?

Start with the transition. Then define what must be true to cross it responsibly.

9. Readiness dimensions

A useful readiness model examines several dimensions rather than one aggregate status.

Dimension	Core readiness question
Product / solution	Does the deliverable meet the required maturity and acceptance evidence?
People	Are users, operators, support teams and decision-makers capable and available?
Process	Are procedures, workflows and responsibilities defined and tested?
Technology / infrastructure	Are environments, interfaces, facilities, networks and tools ready?
Data	Is required data accurate, migrated, protected and available?
Support	Can incidents, maintenance, defects and user needs be handled?
Security / safety	Are critical controls and authorisations in place?
Continuity	Can the organisation respond if the transition fails or degrades?
Governance	Are ownership, decision rights, residual risks and approvals clear?
Stakeholders	Do affected groups understand the change and what they must do?
Operations	Can the receiving organisation sustain the new state after project support reduces?

The exact dimensions should be tailored. The table is a completeness lens, not a mandatory universal model.

10. Product readiness

Product readiness asks whether the deliverable itself has reached the necessary maturity.

Questions may include:

• Are requirements sufficiently satisfied?
• Have required tests passed?
• Are unresolved defects understood?
• Are waivers or deviations authorised?
• Is the configuration known?
• Are interfaces compatible?
• Does the solution perform under representative conditions?

Project Requirements Management provides traceability from need to verification. Readiness asks whether that evidence is mature enough for the intended transition.

11. People readiness

A system can be technically ready while its users and operators are not.

People readiness considers:

• training completion;
• demonstrated competence;
• staff availability;
• role clarity;
• support escalation;
• leadership alignment;
• change fatigue;
• capacity during transition.

Training attendance alone is weak evidence if people cannot perform the required task.

Where consequence warrants it, readiness should test capability rather than count participation.

12. Process readiness

New products often require new operating processes.

Readiness should ask:

• Are procedures written?
• Have people used them in rehearsal?
• Are exceptions handled?
• Are approvals and handoffs clear?
• Do procedures match the deployed configuration?
• Can incidents be escalated?

NASA operational-readiness criteria explicitly include approved operations documentation and trained users and operators. The transferable lesson is that the procedure itself is part of the operational product, not administrative decoration. Source: NASA Systems Engineering Processes and Requirements, Operational Readiness Review criteria.

13. Infrastructure readiness

Infrastructure may include facilities, devices, environments, networks, tools, access, monitoring, physical space, utilities or cloud resources.

An application may be fully tested while the production monitoring account is still missing.

A laboratory may have the equipment but not the calibration certificate.

A school programme may have curriculum materials but insufficient rooms or devices for the intended class structure.

Readiness requires the support environment to exist in the state the transition actually needs.

14. Data readiness

Data readiness is often the hidden limiter of digital transitions.

Questions include:

• Has required data been identified?
• Is migration complete?
• Has reconciliation passed?
• Are privacy and access controls correct?
• Are retention and backup requirements implemented?
• Is the receiving system using the expected version and schema?

If data quality remains based on a planning assumption, link readiness to Project Assumption Management and validate before irreversible cutover where possible.

15. Support readiness

A launch creates a new obligation: someone must support what was launched.

Support readiness asks:

• Who receives incidents?
• What are support hours?
• Who can diagnose the main failure modes?
• Are knowledge articles or runbooks available?
• Are spare parts or replacement paths available?
• What is the escalation route?
• Who owns unresolved defects after launch?

If those answers remain inside the project team’s heads, the receiving organisation is not fully ready.

16. Safety and security readiness

High-consequence transitions require explicit safety and security evidence.

Depending on the domain, readiness may require:

• safety certification;
• security authorisation;
• penetration or vulnerability testing;
• hazard controls;
• emergency procedures;
• regulatory approvals;
• residual-risk acceptance.

Readiness management does not replace specialist safety, legal, regulatory or security judgement. It ensures those necessary judgements are present before transition.

17. Continuity and contingency readiness

A project is stronger when it knows what happens if the transition does not behave as expected.

Possible readiness questions include:

• Can the organisation roll back?
• Is fallback service available?
• Are contingency procedures tested?
• Are recovery time expectations defined?
• Who can authorise fallback?
• Can data be restored?
• Can essential service continue if one dependency fails?

NASA’s readiness criteria specifically include contingency planning and training for contingency operations. Again, the principle transfers: readiness includes preparedness for credible failure, not only the happy path.

18. Stakeholder readiness

A technically perfect transition can still fail socially.

Stakeholder readiness considers:

• awareness of the change;
• understanding of new responsibilities;
• support for the transition;
• availability during the transition window;
• communication channels;
• known resistance;
• user preparation.

Project Stakeholder Management identifies and engages affected groups. Readiness management asks whether the engagement has produced enough preparation for the transition to work.

19. Governance readiness

Projects sometimes prepare every technical detail and still arrive at launch without knowing who can say go.

Governance readiness requires clarity about:

• decision authority;
• go/no-go criteria;
• residual-risk acceptance;
• waiver authority;
• escalation path;
• ownership after transition;
• required approvals and certifications.

Project Governance defines authority. Readiness management ensures the required governance decisions can actually occur when the transition arrives.

20. Readiness criteria should be defined early

If launch criteria are defined the week before launch, they can be shaped unconsciously by what the project has already managed to complete.

Define important readiness criteria early enough that they influence planning.

For example, if the project knows that operational readiness requires trained support staff, a tested rollback, reconciled data and signed operational ownership, those items belong in the integrated plan from the start.

Readiness then becomes work, not paperwork.

21. Entrance criteria vs success criteria

High-quality readiness reviews distinguish between conditions required to hold a meaningful review and conditions required to pass it.

Entrance criteria answer: is there enough mature evidence to conduct the review?

Success criteria answer: has the evidence demonstrated readiness?

NASA readiness frameworks explicitly use both. That distinction prevents projects from convening decision boards before the evidence set is mature enough to support a responsible decision.

22. Go/no-go criteria

A go/no-go decision should not depend on mood.

Criteria may include:

• mandatory tests complete;
• critical defects resolved;
• residual risks accepted;
• required approvals obtained;
• operations ready;
• support ready;
• contingency proven;
• data reconciled;
• communications prepared;
• ownership accepted.

The criteria should distinguish hard blockers from conditions that can be accepted with controlled qualification.

23. Hard blockers

A hard blocker is a condition that prevents responsible transition regardless of how well other areas score.

Examples may include:

• unresolved life-safety risk;
• missing regulatory authorisation;
• critical security exposure;
• no recoverable data backup before irreversible migration;
• no competent operator for a safety-critical process;
• unverified configuration mismatch that invalidates testing.

Hard blockers create a non-compensatory readiness model. Ten green categories do not cancel one unacceptable safety condition.

24. Readiness scoring should not hide blockers

Readiness dashboards often use scores.

Scores can help summarise many dimensions, but they can create false permission if critical conditions are averaged away.

A project that is “92 percent ready” may still be entirely unready if the missing eight percent includes legal approval or rollback capability.

Use scores for visibility, not to overrule explicit hard gates.

25. Readiness evidence hierarchy

Not all readiness evidence is equal.

Evidence	Strength
Statement of intention	Weak: “We plan to train users.”
Document exists	Better: training material is complete.
Activity completed	Stronger: users attended training.
Capability demonstrated	Stronger: representative users complete the task correctly.
Capability demonstrated under representative conditions	Strongest where consequence justifies it: users perform during a realistic rehearsal or pilot.

The required evidence strength should match consequence. Do not demand expensive demonstrations for trivial conditions. Do not accept intention statements for high-consequence conditions.

26. Readiness evidence must match the deployed configuration

A common failure occurs when testing proves one version while launch deploys another.

Readiness should establish which configuration was tested, which configuration is being deployed, and whether differences are understood and authorised.

NASA’s operational-readiness logic explicitly requires user documentation and procedures to reflect the deployed state. The same principle belongs in ordinary projects.

If the evidence concerns version 4 but production contains version 6, the project needs a reasoned bridge—not an assumption that the old evidence still applies.

27. Open issues can coexist with readiness

A project does not necessarily need zero open issues before transition.

The relevant questions are:

• What is the issue?
• What consequence remains?
• Is a workaround proven?
• Who owns closure after transition?
• Does the issue violate a hard readiness criterion?
• Has the correct authority accepted the residual condition?

Project Issue Management keeps the active problem visible. Readiness management determines whether the unresolved condition is compatible with proceeding.

28. Residual risk acceptance

No transition is risk-free.

The readiness question is whether residual risk is understood, controlled to the required level and accepted by the correct authority.

The project manager should not quietly absorb a risk that belongs to executive, operational, regulatory or specialist authority.

Project Risk Management owns the uncertainty analysis. Readiness management asks whether the remaining exposure is acceptable for the next state.

29. Readiness waivers

Sometimes a project cannot satisfy a criterion exactly but can still proceed responsibly under an authorised waiver or deviation.

A credible waiver should state:

• which criterion is not fully met;
• why;
• what residual risk remains;
• what compensating control exists;
• who has authority to accept it;
• how long the waiver remains valid;
• what follow-up action closes the gap.

A waiver should make the exception more visible, not make the missing condition disappear.

30. A readiness matrix

A compact readiness matrix can show evidence and decision status without reducing readiness to one score.

Dimension	Criterion	Evidence	Status	Owner
Product	Critical requirements verified.	Approved verification report.	Ready	Technical lead
Data	Migration reconciliation complete.	Reconciliation report.	Conditional	Data lead
People	Operators trained and demonstrated competence.	Simulation results.	Ready	Operations lead
Support	Incident route operational.	Support rehearsal.	Ready	Service lead
Continuity	Rollback proven within required window.	Rollback rehearsal.	Not ready	Release lead
Governance	Residual risks accepted.	Signed decision record.	Pending	Sponsor

In this fictional example, the project is not ready merely because four rows look positive. The rollback condition may be a hard blocker.

31. Red, amber, green needs definitions

If colours are used, define them.

For example:

• Green: criterion satisfied with current evidence.
• Amber: criterion not fully satisfied, but an evidenced closure path exists before the decision point.
• Red: criterion not satisfied and current evidence does not support proceeding.
• Unknown: evidence has not yet established the condition.

Unknown should remain different from green. Absence of bad news is not proof of readiness.

32. Readiness reviews should be decision meetings

A readiness review should not be a long presentation of everything the project has done.

The decision-makers need:

• the transition being authorised;
• the readiness criteria;
• evidence against each material criterion;
• open gaps;
• residual risks;
• waivers;
• recommended disposition;
• authority for the final decision.

Supporting detail should be available for challenge without forcing every participant through every task completed since initiation.

33. Possible readiness dispositions

A readiness decision does not need only two states.

• Go: readiness criteria satisfied and residual risk acceptable.
• Go with conditions: transition may proceed subject to explicitly controlled conditions.
• Hold: transition paused until named blockers close.
• Rework: evidence or solution maturity is insufficient and requires material repair.
• Cancel or redirect: new evidence shows the transition should not proceed in the planned form.

Whatever the terminology, the decision should be unambiguous.

34. Conditional readiness must be genuinely bounded

“Go with conditions” can become a loophole if every unresolved item is placed into a post-launch action list.

A condition is credible only when:

• the remaining gap is understood;
• the risk of proceeding is acceptable;
• the action owner has capacity;
• the closure date is realistic;
• the transition does not remove the ability to correct the gap safely.

If launch makes the gap irreversible, “conditional” may be the wrong decision.

35. Readiness and Project Assumption Management

Readiness reviews are natural expiry points for assumptions.

Before launch, the project should ask which planning assumptions must now become evidence.

“The support team should be able to cope” is a planning assumption.

At readiness, the project needs evidence such as staffing, rehearsal and workload analysis.

The newly published Project Assumption Management guide provides the lifecycle for those temporary beliefs.

36. Readiness and Project Estimation

Readiness can expose estimate error.

If the team has three days before launch but training requires a week, the readiness gap becomes a schedule and resource problem.

If operational support costs are far higher than planned, readiness may expose a business-case problem.

Project Estimation should be updated when readiness evidence materially changes remaining effort, duration or cost.

37. Readiness and Project Dependency Management

Many readiness criteria are dependencies expressed at a transition boundary.

The launch team needs reconciled data, trained operators, authorised risk acceptance and a functioning rollback before it can proceed.

Project Dependency Management should identify those inputs early rather than discovering them during the final review.

38. Readiness and Project Decision Management

Readiness exists to support a decision.

Project Decision Management clarifies the decision owner, evidence threshold, timing and reversibility.

The readiness process should know:

• what decision is being made;
• by whom;
• by when;
• using what evidence;
• under what risk tolerance;
• with what fallback if the answer is no.

39. Readiness and Project Change Control

A readiness gap sometimes reveals that the current baseline is no longer realistic.

The project may need to change scope, date, rollout sequence, support model or acceptance condition.

The readiness review should not quietly redefine the promise to make the project pass.

If a controlled commitment changes, route it through Project Change Control.

40. Readiness and Project Sponsorship

Sponsors often own or route the final organisational decision to proceed.

Project Sponsorship should ensure readiness evidence remains honest even when the project is politically or commercially pressured to launch.

A sponsor who decides “we are launching regardless” before the review has occurred turns readiness into theatre.

The sponsor may still decide to accept material residual risk, but that decision should remain explicit and within legitimate authority.

41. Readiness and Project Ethics

Readiness is an ethical control because people can be harmed by premature transition.

Pressure to meet a public date can encourage teams to downgrade defects, hide uncertainty or redefine criteria after the fact.

Project Ethics and Professional Responsibility requires truthful representation of evidence and consequence even when the truthful answer is inconvenient.

42. Readiness in agile delivery

Agile delivery does not remove readiness. It often creates more frequent readiness decisions.

A team may decide whether an increment is ready for release every sprint or every few sprints.

Technical “done” should still be distinguished from release readiness.

An increment may satisfy its definition of done but remain unsuitable for production because operations, security, communications, data migration or support are not ready.

Agile Project Management works best when release readiness is explicit rather than assumed from sprint completion.

43. Readiness in hybrid delivery

Hybrid projects often have several readiness layers.

An agile team may be ready to release software while physical installation remains constrained by a predictive site schedule. The programme may therefore be technically ready in one stream and operationally unready overall.

Hybrid Project Management should define where local readiness rolls up into integrated transition readiness.

44. Readiness in programmes

Programme readiness asks whether multiple capabilities are ready to combine into one outcome.

Individual projects may all be green while the programme remains unready because their interfaces, sequence, operational absorption or benefit dependencies are not aligned.

Programme Management should therefore include integrated readiness for major transitions rather than aggregating project status mechanically.

45. Readiness in megaprojects

Megaproject readiness is particularly demanding because transitions can be difficult to reverse and involve many external systems.

Readiness may need to integrate:

• construction completion;
• system integration;
• regulatory certification;
• staff recruitment and training;
• operational rehearsals;
• emergency services;
• public communication;
• supplier support;
• spares and maintenance;
• commercial settlement;
• benefit-owner readiness.

Megaproject Management needs readiness as a system-of-systems decision, not a checklist attached to one contractor.

46. Readiness in education projects

Education projects illustrate why deliverable completion is not enough.

A new learning programme may have finished lesson materials while teachers remain unfamiliar with the sequence, assessment is not ready, classroom resources are missing, parents have not been informed, or transition between levels is unclear.

Readiness should ask whether the learning environment can actually receive the programme.

A practical education readiness review may examine:

• curriculum completeness;
• teacher preparation;
• student prerequisites;
• assessment design;
• materials and technology;
• safeguarding and accessibility;
• parent communication;
• support for struggling learners;
• feedback and correction routes.

47. Readiness in publishing

Publishing readiness is more than manuscript completion.

A publication may require:

• canonical ownership resolved;
• claims supported;
• rights and privacy cleared;
• metadata correct;
• links functional;
• accessibility checked;
• destination correct;
• correction ownership defined;
• render verified;
• publication state observed.

A manuscript can be excellent and still not be ready to publish.

48. Readiness and AI systems

AI-enabled projects add readiness questions around data, model behaviour, human oversight and monitoring.

Before deployment, teams may need evidence that:

• intended use is defined;
• known limitations are documented;
• evaluation is representative enough for the use case;
• fallback and human escalation exist;
• privacy and access controls are appropriate;
• monitoring can detect material degradation or misuse;
• operators know when not to rely on the model.

AI Project Management owns the broader governance. Readiness management asks whether those controls are actually installed before deployment.

49. Common failure: readiness begins too late

The project reaches final testing and suddenly discovers that operations needs three months to recruit and train staff.

The readiness requirement existed all along. The project simply failed to plan it.

Define the major transition criteria early enough to create real work packages.

50. Common failure: product green means launch green

Technical testing passes and leadership assumes the project is ready.

Operations, support, data, communications or users may still be unready.

Keep product readiness separate from integrated readiness.

51. Common failure: readiness by self-certification

Every workstream marks itself green using its own interpretation of “ready.”

Without shared criteria and evidence expectations, the aggregated dashboard has little meaning.

Define readiness centrally enough that different teams are answering the same question.

52. Common failure: evidence arrives after the decision

The board approves launch subject to “final testing,” but final testing occurs after the launch decision and nobody formally reopens the decision when defects appear.

Evidence should arrive before the decision it is meant to support—or the decision must remain explicitly conditional and be revalidated.

53. Common failure: amber becomes permanent

An amber item stays amber for weeks because everybody knows it is unresolved but nobody defines the closure action.

Every amber condition should identify:

• the missing evidence;
• owner;
• due point;
• what happens if it remains unresolved.

54. Common failure: status becomes negotiation

A workstream argues that its item should be green because “we are almost there.”

Readiness status should describe evidence, not confidence in future completion.

“Ready” means the criterion is satisfied. “Expected to be ready” is a forecast and should remain different.

55. Common failure: the operating owner is absent

The project declares operational readiness without the receiving organisation meaningfully participating.

This is structurally weak.

The people who must sustain the result should help define readiness and accept the transfer.

56. Common failure: readiness is measured only through documents

Every procedure is written. Every training deck exists. Every plan is approved.

None has been rehearsed.

For material transitions, evidence should include demonstrated capability where the consequence justifies it.

57. Common failure: no fallback

The project is ready only if everything works exactly as planned.

That is fragile readiness.

Where failure is credible and consequential, readiness should include contingency, rollback or degraded-mode operation.

58. Common failure: the criteria move when the project struggles

A criterion is important when planning begins. It becomes “nice to have” when the project fails to meet it.

Criteria can change legitimately, but the change should be explicit, evidence-based and authorised.

Do not quietly lower the bar to preserve the date.

59. Common failure: readiness ignores post-launch capacity

The project plans the first day but not the first month.

Support demand, defect resolution, user questions, reconciliation and stabilisation often peak immediately after launch.

Readiness should include the capacity to survive the transition period, not merely execute the cutover moment.

60. A worked example: digital service go-live

Consider a fictional project replacing an appointment-booking service.

The go-live date is Monday morning.

By Thursday afternoon, the readiness matrix shows:

Area	State	Evidence
Functional requirements	Ready	Acceptance test complete.
Performance	Ready	Representative load test passed.
Data migration	Conditional	99.7% reconciliation; remaining records classified and owned.
Support	Ready	Support rota active and incident drill completed.
User communications	Ready	Messages scheduled and help content published.
Rollback	Not ready	Procedure exists but rehearsal failed at the restore step.
Governance	Pending	Sponsor has not yet accepted residual migration risk.

The product is mostly ready.

The project is not yet ready to go live.

The rollback failure is treated as a hard blocker because the migration changes live customer records and the project cannot yet demonstrate safe recovery.

The migration discrepancy may be compatible with go-live if the affected records are understood, operationally contained and accepted by the correct authority.

By Friday, the rollback is successfully rehearsed and the sponsor signs the residual-risk decision.

The project becomes ready because the evidence changed—not because the calendar reached Friday.

61. A practical readiness-management cycle

1. Define the transition: state exactly what next state is being authorised.
2. Define readiness dimensions: identify product, people, process, operations, infrastructure, data, support, governance and other relevant areas.
3. Set criteria: specify what must be true and which conditions are hard blockers.
4. Plan evidence: identify how each criterion will be demonstrated.
5. Assign owners: give every criterion and gap a real owner.
6. Build readiness: integrate training, documentation, testing, support, contingency and transition work into the project plan.
7. Track gaps: distinguish satisfied, forecast, conditional, unknown and blocked states.
8. Rehearse: test people and processes under representative conditions where consequence justifies it.
9. Review residual risk: expose open issues, assumptions and waivers.
10. Decide: route the go/no-go decision to legitimate authority.
11. Transition: execute the authorised move into the next state.
12. Verify after transition: confirm that the receiving system is functioning as expected and that conditional items remain controlled.
13. Learn: update future readiness criteria from observed transition failures and surprises.

62. A practical readiness review

• What exact transition are we authorising?
• Who owns the go/no-go decision?
• What are the hard blockers?
• Which requirements must be verified?
• Which defects remain open?
• Are people trained and demonstrably capable?
• Are procedures aligned with the deployed configuration?
• Are data and interfaces ready?
• Can the receiving organisation sustain the new state?
• Is support ready?
• Is contingency or rollback credible?
• Are safety, security, legal and regulatory conditions satisfied?
• Which assumptions must now become evidence?
• Which residual risks remain and who can accept them?
• Are waivers explicit and bounded?
• What conditions remain after transition?
• Who owns those conditions?
• What evidence would make us say no?

63. The deeper idea

Project readiness management is the discipline of making a transition earn its permission.

Projects are naturally pulled toward milestones. Dates acquire political and emotional weight. Teams work hard, expectations rise and the cost of saying “not yet” becomes uncomfortable.

Readiness management exists to protect the project from mistaking momentum for permission.

The strongest readiness system does not ask whether people feel confident. It asks what must be true, what evidence demonstrates that state, what remains uncertain, what happens if the project proceeds anyway and who has authority to accept that consequence.

A milestone should not become “go” because the date arrived.

It should become “go” because the system is ready enough for the next state—and the evidence is strong enough for an accountable decision-maker to say so.

Sources and boundaries

The readiness-assessment definition and project-readiness concepts in this article were checked against current public PMI terminology in September 2026. Operational, test and launch readiness concepts were checked against NASA systems-engineering and program/project-management materials, including the current 2024 handbook. The readiness matrix, evidence hierarchy, integrated cycle and worked example are original teaching structures and should be tailored to the project’s actual industry, safety, legal, security, regulatory and governance requirements.

1. Project Management Institute — Lexicon of Project Management Terms, Version 5.0. Defines readiness assessment as an assessment approaching deployment that evaluates organisational preparedness to integrate and sustain the solution.
2. Project Management Institute — Operational readiness: system more ready than your environment? Discusses operational-readiness assessment across the project life cycle and the receiving environment.
3. NASA Space Flight Program and Project Management Handbook. Current handbook covering operational and flight readiness review objectives and decision structures.
4. NASA Systems Engineering Processes and Requirements — readiness-review criteria. Includes operational readiness entrance and success criteria involving testing, anomalies, supporting products, procedures, training and contingency.

Continue the Project Management series

• Project Assumption Management
• Project Estimation
• Project Requirements Management
• Project Dependency Management
• Project Issue Management
• Project Assurance
• Project Closure and Handover
• Project Governance