Understand Project Readiness in engineering: criteria for Stage-Gate, PDRI, Construction Readiness, procurement, risks, commissioning, operations, and advancement decisions.
Check it out!
Project Readiness is the structured assessment of how effectively a project is prepared to advance to a new phase, make an investment commitment, launch procurement, start construction, execute commissioning, or enter operations. The analysis does not seek to demonstrate that all risks have disappeared; it verifies whether requirements, engineering, decisions, resources, interfaces, contracts, permits, planning, and operational conditions have reached a level of maturity compatible with the next step.
In engineering, readiness must be contextual. A project may be ready to start FEED and still not be ready for procurement. It may be ready to issue a specific construction package but not to mobilize all work fronts. It may be mechanically complete and still not be ready for operation. Therefore, the right question is not simply “is the project ready?”, but “ready for what, against which criteria, evidence, residual risks, and conditions?”.
Project Readiness works as a Project Assurance discipline. It consolidates evidence from different functions and turns a diffuse perception of preparedness into an explicit decision: go, conditional go, hold, or rework. The higher the cost of advancing prematurely, the greater the value of a well-structured readiness assessment.
Readiness does not mean zero open items
No complex project reaches a relevant decision with zero uncertainty. Requiring absolute closure of every open item can paralyze delivery; ignoring them can transfer problems to a much more expensive phase.
The function of a readiness assessment is to distinguish three situations: open items acceptable for the next stage, open items that require conditions or mitigation before advancement, and blockers incompatible with the intended decision.
This logic changes the discussion from “do we have open items?” to “are the open items compatible with the risk we are about to assume?”.
Project Readiness is relative to the gate
The required maturity depends on the decision.
| Gate or decision | Dominant readiness question |
| authorize study/FEED | do the need, alternative, and economic basis justify further development? |
| authorize investment | do scope, CAPEX, schedule, and risks have sufficient maturity? |
| launch procurement | do requirements and interfaces allow comparable proposals? |
| start construction | are engineering, materials, access, permits, and work fronts truly available? |
| start commissioning | are systems complete, configured, and safe for testing? |
| transfer to operations | are people, procedures, documentation, maintenance, and performance ready? |
A criterion suitable for one gate may be completely insufficient for another.
Readiness as part of Stage-Gate
Stage-Gate in engineering projects establishes formal decision points. Project Readiness provides the preparedness analysis that supports those gates.
Stage-Gate answers when and by whom a decision should be made. Readiness answers whether the conditions required for that decision are present and which exposures remain.
A mature organization avoids gates based solely on the calendar. Reaching the scheduled date does not mean the project has reached the state required to advance.
Calendar is not a maturity criterion
Annual budget pressures, supplier commitments, team availability, or management expectations often create a narrative that “we need to start”.
These factors may be legitimate, but they must be treated as decision constraints, not as evidence of readiness.
If the organization decides to advance with gaps, the decision should record what they are, who assumes the risk, which conditions must be met, and what contingencies have been established.
Project Readiness and PDRI are not synonymous
PDRI — Project Definition Rating Index primarily assesses project definition maturity during Front End Planning. It is an extremely relevant tool for readiness, but it covers only part of the question.
Project Readiness may include dimensions that extend beyond scope definition: team availability, contracting, materials, permits, access, logistics, constructability, temporary systems, test procedures, training, spare parts, operations documentation, and organizational capability.
Thus, PDRI can be an input to a broader readiness assessment.
Readiness must be multidimensional
Projects fail when they advance prematurely because maturity in one dimension masks a critical weakness in another.
For example, engineering may be 90% complete, but the remaining 10% may include interfaces that prevent installation. Materials may have been purchased while the area is still not released. The system may be installed while operating procedures or validated backups do not yet exist.
A readiness framework must assess the whole.
The diagram does not represent universal weights. Each project should calibrate the dimensions according to its gate and risk profile.
Dimension 1: need, strategy, and Business Case
Before assessing execution, it is necessary to confirm whether the decision remains aligned with the business need.
Changes in demand, technology, regulation, corporate strategy, or cost may make original assumptions obsolete. A technically mature project may still not be economically or strategically ready to advance.
The Business Case, benefits, selected alternative, and success criteria must be updated to the level required by the gate.
Dimension 2: requirements and scope
Scope readiness means the project knows what it must deliver, for whom, and under which criteria.
Critical requirements must be identified, approved, and traceable. Inclusions, exclusions, assumptions, boundaries, and interfaces need sufficient maturity for the next commitment.
Contract Scope in Engineering shows how gaps at these boundaries turn into changes, conflicts, and claims during execution.
Dimension 3: engineering maturity
Percentage of engineering completed is only one indicator. Readiness requires identifying which documents and decisions are mature and which remain open.
Ten percent of pending engineering may be irrelevant, or it may contain the information that defines foundations, loads, interfaces, I/O lists, routing, protection, selectivity, network architecture, or operational logic.
The analysis should prioritize criticality and dependency, not merely the number of drawings issued.
Engineering completeness must be measured by intended use
A more useful way to assess engineering is to ask whether the deliverables required for the next activity are released and stable.
For procurement, there must be enough information to specify and compare. For construction, IFC drawings, details, specifications, and interfaces must support execution. For commissioning, configuration, cause-and-effect, point lists, and functional criteria must be controlled.
The degree of completeness must be related to downstream use.
Dimension 4: interfaces
Interfaces are one of the main causes of false readiness. Each package appears ready when assessed in isolation, while the boundaries between them remain unresolved.
An interface matrix should identify the owner, requirements, status, dependencies, and closure evidence. Open critical interfaces must appear as a risk or blocker.
System Architecture reinforces that interfaces are engineering objects, not merely lines between blocks.
Dimension 5: risks and opportunities
A project may be ready even with high risks, provided they are understood, accepted, and treated consistently with the decision.
Readiness should verify whether critical risks have an owner, response, trigger, contingency, and known impact. Risks without a response may be more concerning than risks with a higher nominal impact that are already mitigated.
Emerging risks created by advancement itself should also be considered: early contracting, fast-track execution, construction with incomplete engineering, or dependence on a single supplier.
Residual risk must be explicit
After mitigation actions, residual risk remains. The gate decision should record whether that risk falls within the organization’s risk appetite.
This is relevant because readiness should not present an image of absolute safety. The assessment states what is ready, what remains exposed, and which risk the authority is accepting by advancing.
Governance requires transparency, not a promise of certainty.
Dimension 6: cost estimate and funding
Financial readiness involves more than having budget available. The estimate must be compatible with technical maturity and include appropriate bases, assumptions, contingencies, and risks.
It is also necessary to confirm funding for the next phase, cash flow, foreign-exchange exposure when applicable, commitments already made, and the impact of long lead items.
A project without authorized funding or with an estimate inconsistent with its definition may not be ready for procurement or execution.
Dimension 7: schedule and execution logic
The schedule must represent how the work will actually be performed. Milestones, interfaces, calendars, constraints, procurement, engineering, construction, and commissioning must be integrated.
Execution readiness requires particular attention to real predecessors: released drawing, available material, accessible area, mobilized team, issued permit, and closed interface.
An activity scheduled to start is not ready simply because its date has arrived.
Lookahead and constraints
For construction readiness, a short-term analysis should verify constraints by work front.
A lookahead can identify planned work, start requirements, and impediments. The objective is to prevent mobilizing teams to fronts that still depend on design, material, equipment, scaffolding, release, access, or a decision.
This logic reduces waiting time, improvisation, and unplanned resequencing.
Dimension 8: procurement
Critical materials and equipment must be aligned with the schedule and the current technical configuration.
Readiness should consider RFQs, proposals, technical bid evaluation, issued purchase orders, vendor data, manufacturing, FAT, logistics, delivery, storage, and preservation.
Buying too early with immature engineering creates change risk. Buying too late creates delay risk. Readiness helps balance these exposures.
Vendor data is part of engineering
In many systems, detailed design depends on supplier data. Dimensions, loads, power, protocols, heat dissipation, connections, and installation requirements feed downstream development.
An issued purchase order does not mean the package is ready. It is necessary to verify whether the required data will be delivered on time, reviewed, and incorporated into the configuration.
This dependency must appear in the schedule and in the readiness assessment.
Dimension 9: contracts and responsibilities
Before mobilizing or contracting, responsibilities must be sufficiently clear.
Who provides temporary power? Who performs integration? Who provides access? Who performs tests? Who provides instruments? Who resolves interfaces? Who issues As Built documentation? Who requests acceptance?
Scope of Work in Engineering is one of the foundations of contractual readiness because it turns the solution into verifiable obligations.
Dimension 10: permits, approvals, and regulatory requirements
A project may have completed engineering and still not be authorized to execute.
Environmental permits, permissions, operating authorizations, client approvals, utility requirements, access, and legal documents must be verified according to the stage.
The absence of a single critical approval can block an entire work front and generate unproductive mobilization cost.
Dimension 11: site conditions
Brownfield, retrofit, and infrastructure projects depend heavily on the quality of existing information.
As-built surveys, topography, geotechnical data, interferences, structural conditions, utilities, existing networks, access, and operational constraints must be characterized at an appropriate level.
Advancing with an unknown site transfers uncertainty to the field, where the cost of discovery is higher.
Dimension 12: constructability
Constructability asks whether the solution can be executed safely and efficiently under actual site conditions.
Sequence, access, lifting, laydown areas, work in operating facilities, isolation, interferences, modularization, and temporary systems must be considered.
A project may be “designed” and still not be construction-ready.
When a project is pressured to advance by the calendar, governance must separate urgency from readiness. Clear criteria, blockers, and gate conditions make it possible to accelerate consciously — without turning engineering open items into unproductive work, changes, and disputes during execution.
Structure gates, criteria, and decisions with Project, Program, and Portfolio Governance
Construction Readiness as a specific discipline
CII developed the Construction Readiness Assessment (CRA) specifically to evaluate whether projects are prepared for construction.
Research RT-DCC-02 identified 228 readiness factors grouped into 15 categories and developed a Construction Readiness Score to classify projects and identify improvement areas. The study compared projects considered construction-ready and construction-not-ready and found performance differences in cost and schedule.
This research reinforces a practical idea: starting construction before essential conditions are resolved does not necessarily accelerate the project; it may only bring unproductive work forward.
Engineering release is not construction readiness
Issuing an IFC drawing is important, but not sufficient.
The work front may also depend on material, labor, tools, access, predecessors, inspection, permits, procedures, safety, and logistics.
Therefore, construction readiness must be assessed by package or work front, not only by engineering document status.
Workface readiness
At the operational level, workface readiness means the crew can start and continue work without foreseeable blockers.
The organization can use simple constraint-removal criteria: information, material, equipment, area, crew, tools, safety, quality, and predecessor.
A work front released without these elements creates start-stop cycles that reduce productivity and increase exposure to claims.
Dimension 13: organization and resources
Projects also fail because of insufficient organizational capability. Having the scope ready does not guarantee that the owner and suppliers have the capacity to execute it.
Readiness should assess governance structure, organization chart, roles, authority, team capacity, discipline coverage, availability of technical supervision, and escalation channels.
Phase changes usually increase the load on specific functions. Procurement may become overloaded during contracting; supervision grows during mobilization; commissioning requires dedicated competencies.
Competence is different from headcount
Adding headcount does not solve an expertise gap.
Critical systems may require specialists in protection, automation, networks, software, quality, functional safety, or commissioning. The readiness assessment must verify competencies, not merely a filled organization chart.
It should also consider excessive dependence on a single person for critical decisions.
Dimension 14: governance and decision-making
Readiness depends on decisions being made at the right time. A team may have complete information and still remain blocked because authority or the approval process is unclear.
Authority matrices, forums, decision SLAs, change control, and escalation must be established before high-speed phases.
The Project, Program, and Portfolio Governance solution organizes these mechanisms so decisions do not depend on informal arrangements.
Dimension 15: documentation and configuration
A ready project must know which configuration is current.
Drawings, specifications, lists, models, software, firmware, parameters, and vendor documents must have controlled revisions. The field team must access the correct version.
Readiness should also verify RFI, redline, NCR, punch list, test, and As Built workflows so execution generates adequate evidence for handover.
Document Control is execution infrastructure
Document Control is often perceived as an administrative function, but in complex projects it is operational infrastructure.
Without controlled distribution, a work front may execute an obsolete revision. Without records, the team cannot reconstruct decisions. Without a baseline, tests may be performed on an unidentified configuration.
Therefore, document readiness must be part of the execution gate.
Dimension 16: quality
The quality plan, ITPs, inspection criteria, hold points, procedures, and responsibilities must keep pace with execution maturity.
It is not enough to “inspect later”. Criteria must exist before the work to guide execution and evidence collection.
This is particularly critical for activities that will be concealed, energized, or inaccessible in later phases.
Dimension 17: HSE and operational safety
Readiness must ensure that safety risks associated with the next phase have been identified and controlled.
Work permits, risk assessments, isolation, LOTO, work at height, confined spaces, energy, lifting, access, and interfaces with operations are examples of conditions that can block mobilization.
In brownfield projects, coordination with operating facilities is part of engineering and planning, not a last-minute task.
Readiness for commissioning
Commissioning readiness begins well before testing. Systems must have an appropriate completion status, available documentation, controlled configuration, classified punch items, personnel, instruments, power, communication means, and approved procedures.
System and subsystem boundaries, energization sequence, and safety conditions must also be defined.
A physically installed system may still not be ready for commissioning.
Mechanical Completion does not mean operational readiness
CII emphasizes in its Planning for Startup practice that the objective of a capital project is not merely to complete construction, but to deliver a functional unit within the business environment.
Mechanical Completion indicates a physical milestone. Functional tests, training, procedures, spares, integration, documentation, performance testing, and formal transfer may still be outstanding.
Readiness must follow this transition.
Operational Readiness
Operational Readiness verifies whether the organization receiving the asset is prepared to operate it safely and with the required performance.
This includes trained personnel, procedures, maintenance, contingency plans, spares, tools, support contracts, asset data, documentation, permits, and acceptance criteria.
CII maintains Planning for Startup as a best practice across multiple phases, reinforcing that preparation for operations should begin early.
Operations must participate before handover
Involving users only at the end creates the risk of unmet requirements and low system ownership.
Operations and maintenance should contribute to requirements, architecture, maintainability, testing, and validation criteria during development.
This participation reduces the gap between “system built according to design” and “system usable in the real context”.
Readiness and the V-Model
The V-Model in Systems Engineering connects requirements defined during development to verification and validation evidence.
Readiness uses this traceability to ask whether enough evidence exists to advance to the next level of integration or acceptance.
A test should not begin without criteria and configuration. A handover should not occur without evidence for critical requirements.
Readiness and MBSE
In projects using MBSE — Model-Based Systems Engineering, part of readiness can be supported by digital traceability.
Requirements, architecture elements, interfaces, risks, and verification cases can be related in the model. This makes it easier to identify open items and the impact of changes.
Even so, readiness also depends on physical and organizational conditions outside the model: delivered material, mobilized teams, issued permits, and completed training.
How to structure a Readiness Assessment
The first step is to define the gate being assessed. The team then establishes dimensions, criteria, evidence, blockers, and owners.
A robust structure must support both an executive view and traceability to the detail.
The result should not be just a percentage. It should show where the main exposures are and which conditions must be satisfied.
Clear criteria prevent optimistic self-assessment
Terms such as “adequate”, “sufficient”, and “nearly complete” must be translated into evidence.
Instead of “engineering almost complete”, a criterion may require critical IFC documents, closed interfaces, and incorporated vendor data. Instead of “team defined”, it may require critical positions mobilized and formal authority established.
The more objective the criterion, the less room there is for readiness by perception.
Classification system
An organization may use RAG — red, amber, green — or another scale.
- Green: condition satisfied and evidenced;
- Amber: condition partially satisfied, with controllable risk and a defined plan;
- Red: condition incompatible with advancement or without acceptable mitigation.
The important point is to establish meaning before the assessment. Changing criteria after seeing the result destroys comparability.
Blockers must be separated from the score
An aggregate score can hide a critical failure. Therefore, blockers must be treated independently.
Examples include a missing mandatory permit, unresolved safety requirement, critical material without a date, essential drawing not released, lack of protection for energization, or an external interface without agreement.
A single blocker may justify a hold even if most criteria are green.
Conditional go
Not every open item requires a hold. The decision may be a conditional go when specific actions can be completed without compromising safety or the logic of the phase.
The condition must have an owner, deadline, and verification mechanism. There should also be a consequence if it is not met.
Conditional go cannot be used simply to push blockers into execution.
Waiver and formal risk acceptance
In exceptional cases, the authority may accept advancement without meeting a specific criterion.
This should be treated as a waiver or explicit risk acceptance, with justification, impact, compensating measures, and responsible authority.
Recording the exception preserves governance and prevents a criterion from being informally ignored merely to protect the schedule.
Readiness heatmap
An executive view can represent dimensions and status by gate.
| Dimension | Status | Main gap | Owner | Condition to advance |
| scope/requirements | green | — | engineering | satisfied |
| interfaces | amber | utilities interface | integration | close ICD |
| procurement | amber | long lead equipment | procurement | PO by deadline |
| construction | red | area not released | owner | physical release |
| commissioning | amber | procedure under review | Cx | approve before energization |
This matrix directs the discussion toward the items that change the decision.
Readiness by package or system
Large projects do not need to wait until all areas reach the same level before advancing selectively.
Readiness can be assessed by Work Package, area, system, or subsystem. This strategy supports progressive execution provided interfaces and risks are understood.
For example, foundations in one area may be ready while another is awaiting definition. The gate must clearly state the exact scope of the authorization.
Partial Release requires a clear boundary
Partial release without defining scope creates ambiguity.
The decision should define what is authorized, which documents support the release, which interfaces remain frozen, and which activities may not start.
This reduces the chance that a limited authorization is interpreted in the field as general approval.
Fast-track increases the importance of readiness
Fast-track overlaps engineering, procurement, and construction. This can reduce schedule, but it increases the dependency between maturity and sequence.
Readiness should not prevent fast-track; it should make explicit where the organization is assuming the risk of advancing with incomplete information.
Early packages must be selected based on sufficient stability and low exposure to downstream changes.
Readiness in brownfield projects
Projects in existing facilities face conditions that are not fully documented, continuous operations, and access constraints.
Surveying, scanning, testing, operational windows, isolation, interfaces with legacy systems, and contingency plans gain importance.
An apparently simple work front may not be ready if it depends on a shutdown that has not yet been approved.
Readiness in technology systems
Automation, electronic security, telecommunications, and digital infrastructure systems have dependencies on software, licensing, servers, networks, identity, data, and integrations.
Installed hardware does not mean the system is ready. Versions, credentials, certificates, APIs, firewalls, synchronization, storage, and environments must be considered.
Rollback and backup must also be planned before changes to production systems.
Cybersecurity readiness
In connected systems, security requirements must be validated before entry into operation.
Default accounts, firmware, hardening, segmentation, backups, logging, remote access, and vulnerability management are examples of conditions that can affect acceptance.
Operational readiness must include the ability to keep the system secure after handover, not just configure it once.
Readiness and data
Digital projects depend on correct data for configuration, testing, and operations.
User records, assets, tags, addresses, point lists, naming conventions, and parameters must be available in the required format and at the required time.
Incomplete data can block commissioning even when all physical infrastructure is ready.
Readiness and Change Management
Changes close to the gate can invalidate previous evidence.
If architecture, requirements, equipment, or sequence changes, the team must assess which readiness criteria need to be reviewed.
Engineering Change Management provides governance to control impacts and preserve the baseline.
Readiness and Claim Management
Advancing under incomplete conditions can create contractual impacts. Delayed access, late information, undisclosed constraints, and sequence changes are frequent sources of events.
Claim Management helps record and address these events, but readiness acts preventively: it seeks to identify exposure before mobilization.
Prevention is less expensive than reconstructing causation months later.
Independent Project Review
For critical decisions, an independent review can reduce bias from the team that developed the project.
The reviewer does not need to redesign the solution. The role is to verify whether criteria were met, whether evidence supports the statements, and whether risks and gaps were presented transparently.
Owner’s Engineering, the PMO, or a third party may perform this role depending on governance and criticality.
In projects with multiple contracts, each supplier may declare its package ready while the complete system remains exposed. The Owner needs to consolidate requirements, interfaces, documents, tests, and operational conditions into a single view before authorizing the next phase.
Use Owner’s Engineering to conduct independent readiness and integration assessments
Readiness in Owner’s Engineering
Owner’s Engineering is particularly well suited to readiness because it works transversally across multiple suppliers.
The Owner needs to know whether the whole is ready, not merely whether each contractor has declared its scope complete.
An independent assessment can integrate engineering, contracts, documents, interfaces, tests, and operating conditions before recommending advancement.
Readiness as a continuous system, not a last-minute audit
Assessing only on the eve of the gate limits the ability to correct problems.
Best practice is to monitor readiness progressively, updating gaps and trends. By the time the formal decision arrives, most blockers should have been identified weeks or months earlier.
The final assessment consolidates; it should not discover everything for the first time.
Leading indicators of readiness
Leading indicators show whether the project is building the conditions for success.
Examples include critical interfaces closed, engineering deliverables released on time, long lead items contracted, constraints removed, procedures approved, and requirements with planned evidence.
These indicators are more useful preventively than indicators of delays that have already materialized.
Readiness debt
When an organization decides to advance with open items, it accumulates a kind of readiness debt: work that should have been completed earlier and must now be resolved under greater pressure.
The debt may be manageable if small and explicit. It becomes dangerous when successive gates transfer open items into the next phase.
The result is execution carrying concept decisions, procurement carrying requirement uncertainties, and commissioning discovering architecture problems.
Avoid chronic transfer of open items
Good governance tracks the origin and age of gaps.
If an interface opened during FEED remains unresolved in construction, the problem is not merely technical; it is a failure of the decision process.
The readiness assessment should flag aging items and require resolution or formal risk acceptance.
Readiness and contingency
Contingency should not be used to justify every gap.
Cost contingency absorbs cost uncertainty; schedule reserve absorbs time uncertainty. Neither replaces a requirement, permit, interface, or essential physical condition.
The team must distinguish acceptable uncertainty from insufficient definition.
Readiness and executive decision-making
The executive summary must be clear: recommendation, blockers, relevant gaps, residual risk, conditions, and the impact of not advancing.
A dashboard with dozens of indicators can obscure the decision. The role of assurance is to translate technical detail into an executive position without hiding complexity.
The authority needs to know what it is accepting.
Recommended structure for a readiness report
A report may contain the objective and gate, assessment scope, criteria, participants, evidence, result by dimension, blockers, risks, actions, waivers, and recommendation.
The document should also record the date and configuration assessed. Readiness is a snapshot of a state; subsequent changes may invalidate it.
For critical gates, the authority’s decision should be attached to the record.
How to define the owner of each criterion
Each criterion needs an owner responsible for the condition and, where appropriate, an independent party responsible for verification.
Engineering may own a drawing; Project Controls the schedule; Procurement the equipment; Operations a procedure; HSE a permit. The readiness assessor consolidates without absorbing all responsibilities.
This division prevents the process from becoming a “PM audit” without discipline accountability.
Assessment cadence
Frequency depends on project speed and the gate.
Front End Planning may use checkpoints at maturity milestones. Construction may monitor readiness weekly by work front. Commissioning may require system reviews before energization.
The cadence should allow action between assessments.
Thresholds must be calibrated
Universal percentages are dangerous. An appropriate threshold depends on the tool, project type, phase, and risk.
CII has its own benchmarks for tools such as PDRI and the Construction Readiness Assessment. An organization can also develop internal thresholds based on historical performance.
The important point is not to invent an “85% ready” status without a relationship to performance or criticality.
Internal benchmarking and continuous improvement
By recording readiness and project outcomes, a company can learn which gaps actually anticipate problems.
Projects with low interface maturity may show more changes; low procurement readiness may generate delays; low operational readiness may increase post-handover punch lists.
These correlations make it possible to improve criteria and gates over time.
Readiness should measure outcomes, not document quantity
A complete folder can hide an immature system. The criterion needs to look at decisions and conditions.
A document is evidence when it demonstrates something: an approved requirement, a closed interface, a validated calculation, a completed test, or an issued permit.
Generating a document merely to tick a checklist creates compliance without readiness.
Main mistakes in Project Readiness
The most common mistakes are assessing too late, using generic percentages, confusing document volume with maturity, hiding blockers in average scores, accepting self-assessment without evidence, and advancing according to the calendar.
It is also problematic to assess each discipline in isolation without analyzing interfaces and to treat conditional go as authorization to carry unresolved definitions indefinitely.
Readiness should increase transparency, not produce formal justification for a decision that has already been made.
When to use a Project Readiness Assessment
The discipline adds value whenever the next step significantly increases the cost of change or contractual exposure.
This occurs before investment authorization, significant procurement, mobilization, start of construction, energization, commissioning, handover, and entry into operation.
The more irreversible the commitment, the more rigorous the assessment should be.
Final considerations
Project Readiness turns the decision to advance into an assessment of actual conditions. Instead of assuming readiness because the date has arrived or because the team is “almost finished”, the organization verifies requirements, engineering, interfaces, risks, procurement, contracts, construction, people, documentation, commissioning, and operations according to the specific gate.
The discipline does not seek projects with no open items. It seeks conscious decisions: which gaps are acceptable, which require conditions, and which are blockers. This allows conditional go and risk acceptance to be used under governance without masking exposure.
Integrated with Stage-Gate, PDRI, Front End Planning, and Owner’s Engineering, Project Readiness works as an assurance layer between planning and commitment. Its main benefit is preventing the organization from discovering, only in the next phase, that what looked like progress was merely the transfer of unresolved work.
Technical references
[1] CONSTRUCTION INDUSTRY INSTITUTE. Construction Readiness Assessment for Productivity Improvement. RT-DCC-02. Austin: CII. Available at: https://www.construction-institute.org/rt-dcc-02
[2] CONSTRUCTION INDUSTRY INSTITUTE. Construction Readiness Assessment for Productivity Improvement. Austin: CII. Available at: https://www.construction-institute.org/construction-readiness-assessment-for-productivity-improvement
[3] CONSTRUCTION INDUSTRY INSTITUTE. Project Definition Rating Index (PDRI) Overview. Austin: CII. Available at: https://www.construction-institute.org/pdri-overview
[4] CONSTRUCTION INDUSTRY INSTITUTE. Planning for Startup. IR121-2. Austin: CII. Available at: https://www.construction-institute.org/planning-for-startup
[5] CONSTRUCTION INDUSTRY INSTITUTE. Achieving Success in the Commissioning and Startup of Capital Projects. IR312-2. Austin: CII, 2015. Available at: https://www.construction-institute.org/achieving-success-in-the-commissioning-and-startup-of-capital-projects
[6] U.S. DEPARTMENT OF ENERGY. DOE G 413.3-12A — Front-End Planning and Project Definition Rating Index for Nuclear and Non-Nuclear Construction Projects. Washington, DC: DOE, 2023. Available at: https://www.energy.gov/documents/front-end-planning-and-project-definition-rating-index-nuclear-and-non-nuclear
Frequently asked questions
It is the structured assessment of the conditions required for a project to advance with controlled risk to a specific gate or phase, considering technical, organizational, contractual, regulatory, construction, and operational dimensions.
No. Open items may exist as long as they are compatible with the next stage, evidenced, and have defined treatment. Blockers and risks incompatible with advancement should prevent or condition the decision.
PDRI has a strong focus on project definition maturity during Front End Planning. Project Readiness is broader and may include resources, contracts, materials, permits, construction, commissioning, and operational capability.
It is readiness specifically for construction execution. It considers engineering, materials, work fronts, resources, planning, logistics, safety, interfaces, and other conditions required for productivity and continuity of work.
It is authorization to advance subject to specific conditions, with defined owners, deadlines, and verification mechanisms. It should not be used to transfer blockers to the next phase.
The assessment should be multidisciplinary. At relevant gates, the PMO, Owner’s Engineering, or an independent third party may facilitate or review the analysis to reduce bias and integrate evidence from multiple suppliers and disciplines.
Complementary technical materials
Main content on the topic
- PDRI — Project Definition Rating Index in Engineering
- Stage-Gate in engineering projects: phases, criteria, and decision gates
- FEL: the stage that prevents a project from becoming a legal, financial, and operational problem
Related technical content
- V-Model in Systems Engineering: requirements, integration, verification, and validation
- System Architecture: how to structure the architecture of complex systems
- Claim Management in Engineering Projects
Related solutions
- Project, Program, and Portfolio Governance
- Requirements, Evidence, and Acceptance Criteria Management
