Context Assessment, Lifecycle Selection and Tailoring

Introduction

Hybrid project management is not a compromise between predictive and agile practice; it is a deliberate design choice for managing projects in which different components exhibit different levels of uncertainty, regulatory constraint, technical interdependence, or stakeholder involvement. The central managerial task is to determine which work should be planned and controlled predictively, which should be developed iteratively or incrementally, and how the two modes should be integrated.

A lifecycle should therefore be selected only after assessing the project context. A method selected because it is fashionable, mandated by a supplier, or familiar to the project manager may be unsuitable even when its individual practices are sound. Conversely, a hybrid lifecycle can improve control and responsiveness when its design is traceable to project conditions.

This chapter develops a structured approach to context assessment, lifecycle selection, and tailoring. It combines suitability thinking—asking which lifecycle characteristics fit the project—with contingency thinking—asking how the design should change in response to uncertainty, complexity, governance, organizational capability, and product characteristics.

Learning Objectives

By the end of this chapter, the reader should be able to:

1. Distinguish predictive, adaptive, iterative, incremental, and hybrid lifecycles.
2. Assess uncertainty, complexity, compliance, organizational maturity, and product characteristics.
3. Apply suitability and contingency models to lifecycle decisions.
4. Design and justify a hybrid lifecycle with appropriate governance and tailoring.
5. Evaluate the limitations, risks, and ethical implications of lifecycle selection.
6. Explain how evidence, metrics, and digital tools can support lifecycle tailoring.

1. Lifecycle Concepts and the Logic of Hybridization

A project lifecycle is the sequence of phases, decision points, development activities, and governance mechanisms through which a project creates and transitions its deliverable. It is distinct from a project management methodology. A lifecycle describes how work unfolds; a methodology provides principles, practices, roles, tools, and guidance for managing that work.

1.1 Principal lifecycle types

Predictive lifecycle. Scope, requirements, design, schedule, and budget are substantially defined before execution. Change is controlled through formal review. Predictive approaches are useful when requirements are stable, technologies are proven, interfaces are known, and compliance requires extensive prior approval.

Iterative lifecycle. The solution is progressively refined through repeated cycles. Learning from one cycle informs the next. Iteration is particularly valuable when the team understands the problem but not the complete solution.

Incremental lifecycle. Usable portions of the product are delivered successively. Each increment adds capability. Incremental delivery can generate early value and feedback even when the complete product will take considerable time to finish.

Adaptive lifecycle. Scope and solution details evolve through short feedback cycles, while time and resources are often constrained. Adaptive approaches are appropriate where uncertainty is high and stakeholders can provide frequent feedback.

Hybrid lifecycle. Two or more lifecycle logics are intentionally combined. For example, a fixed regulatory architecture may be managed predictively while customer-facing functionality is developed through agile increments.

Hybridization can occur at several levels:

• Component level: different subsystems use different approaches.
• Phase level: predictive initiation and approval are followed by iterative development.
• Governance level: formal stage gates coexist with agile delivery cycles.
• Supplier level: internal teams may work adaptively while contracts and external interfaces remain predictive.
• Scale level: portfolio and release planning may be predictive while team execution is iterative.

The purpose is not to maximize the number of methods. It is to create the minimum coherent system of controls and learning mechanisms needed by the project.

2. Context Assessment

Lifecycle selection begins with diagnosis rather than preference. A useful assessment examines five primary dimensions: uncertainty, complexity, compliance, organizational maturity, and product characteristics. These dimensions interact; none should be treated as an isolated score.

2.1 Uncertainty

Uncertainty concerns what is not known or cannot yet be predicted reliably. It may involve:

• Requirement uncertainty: stakeholders have not agreed what should be delivered.
• Technical uncertainty: the feasibility or performance of a solution is unclear.
• Market uncertainty: customer demand, competitors, or regulation may change.
• Execution uncertainty: productivity, dependencies, or resource availability are difficult to estimate.
• Outcome uncertainty: even a completed deliverable may not produce the expected benefits.

High uncertainty favors short learning cycles, experiments, prototypes, frequent demonstrations, and reprioritization. However, adaptive delivery does not eliminate uncertainty; it exposes and manages it progressively. A project can use adaptive development while retaining predictive controls for safety, funding, or contractual commitments.

2.2 Complexity

Complexity is not synonymous with size. A small project may be complex if it contains many interacting stakeholders, novel technology, political dependencies, or emergent behavior. Relevant sources include:

• number and strength of dependencies;
• technical integration and system interfaces;
• geographic and organizational distribution;
• stakeholder conflict;
• novelty and nonlinearity;
• rate of environmental change;
• consequences of failure.

A complex project benefits from architecture management, dependency visualization, systems thinking, integration planning, and frequent cross-functional coordination. Iterative development may reduce technical uncertainty, but it can also create integration risk if teams do not share architectural constraints and quality standards.

2.3 Compliance and governance

Compliance may arise from law, regulation, industry standards, contractual obligations, internal policy, safety requirements, or data protection rules. Compliance does not automatically require a predictive lifecycle. It requires demonstrable control, traceability, evidence, competent authorization, and appropriate separation of duties.

A hybrid design may, for example, use:

• a predictive compliance baseline;
• formally approved architecture and risk controls;
• iterative development inside approved boundaries;
• automated testing and traceability;
• stage gates for release, validation, and operational acceptance.

The key distinction is between prescribing the outcome and evidence and prescribing every activity sequence. A regulator may require validated requirements, records, tests, and approvals without requiring that every development task follow a sequential model.

2.4 Organizational maturity

Organizational maturity refers to the organization’s ability to perform, learn, govern, and improve project work consistently. Indicators include:

• executive sponsorship and decision speed;
• availability of empowered product or business representatives;
• team stability and cross-functional capability;
• quality of estimation and historical data;
• maturity of risk, change, procurement, and configuration management;
• psychological safety and willingness to expose problems;
• experience with iterative delivery and technical automation.

A sophisticated lifecycle cannot compensate for absent decision rights or weak product ownership. In a low-maturity environment, a staged transition may be safer than a wholesale adoption of agile practices. Basic planning, role clarity, visual work management, and feedback may be introduced before more advanced scaling mechanisms.

2.5 Product characteristics

The product itself strongly influences lifecycle choice. Consider:

• whether value can be delivered in usable increments;
• whether the product is modular or tightly coupled;
• reversibility of design decisions;
• cost of late change;
• safety and reliability expectations;
• physical versus digital composition;
• testability and automation potential;
• expected operational life and maintainability.

A mobile application may be incrementally released and measured in production. A bridge cannot normally be constructed through unrestricted production experiments, although its design, simulation, and noncritical subsystems may be iterated. A medical device may combine predictive design controls with iterative prototyping, provided that verification, validation, and documentation remain rigorous.

3. Suitability and Contingency Models

Two complementary perspectives support lifecycle decisions.

3.1 Suitability perspective

Suitability asks: “How well does a lifecycle’s inherent logic match the project conditions?” Predictive lifecycles suit stable requirements, known technologies, sequential dependencies, and high costs of change. Adaptive lifecycles suit evolving requirements, rapid feedback, modular products, and accessible stakeholders. Hybrid lifecycles suit mixed conditions.

Suitability is not a binary classification. It is a reasoned comparison between alternatives. A project manager should document the evidence supporting the conclusion and identify the assumptions on which it depends.

3.2 Contingency perspective

Contingency theory holds that there is no universally optimal management arrangement. Effectiveness depends on fit among context, structure, behavior, and environment. Lifecycle design is therefore contingent on:

• uncertainty and volatility;
• task interdependence;
• organizational capability;
• governance obligations;
• product architecture;
• stakeholder access;
• commercial and contractual conditions.

A contingency approach also requires dynamic tailoring. The chosen lifecycle is a hypothesis that should be reviewed when evidence changes. For example, a project may begin with predictive feasibility and architecture work, then move toward adaptive delivery after technical feasibility is established. Conversely, a project may introduce more formal controls after a safety concern, audit finding, or major integration failure.

3.3 A structured assessment model

A practical assessment can use a qualitative rating from 1 to 5 for each dimension. The rating is not an objective measurement; it is a disciplined conversation supported by evidence. A possible weighted suitability index for a candidate lifecycle is:

where S_L is the suitability score for lifecycle L, w_i is the importance weight of context dimension i, and f_i,L is the assessed fit of lifecycle L with that dimension. Weights should be non-negative and normally sum to 1; fit scores must use a defined scale, such as 1 for very poor fit and 5 for very strong fit. The model assumes that dimensions can be meaningfully scored and that weighted addition is an acceptable approximation. It does not prove that the highest score is the correct choice, because critical constraints may disqualify an otherwise high-scoring option.

A compliance or safety constraint should therefore be treated as a gate, not merely as another favorable score. If a lifecycle cannot produce required evidence, approvals, or controls, it is unsuitable regardless of its aggregate score.

4. Selecting a Hybrid Lifecycle

A defensible hybrid lifecycle is designed through explicit decisions rather than by attaching an agile label to a conventional plan.

Step 1: Define the decision context

Clarify the product vision, expected benefits, funding horizon, contractual commitments, regulatory obligations, and decision authorities. Identify which constraints are genuinely fixed and which are negotiable.

Step 2: Decompose the product and work

Break the product into capabilities, subsystems, releases, or value streams. For each element, assess uncertainty, coupling, criticality, testability, and potential for independent delivery. A component-level view often reveals that the project is not uniformly predictive or adaptive.

Step 3: Identify control needs and learning needs

Control needs include baselines, approvals, audit trails, configuration control, safety cases, and contractual milestones. Learning needs include discovery, prototyping, user feedback, technical spikes, and empirical measurement. A sound hybrid lifecycle explicitly provides both.

Step 4: Select integration points

Integration points connect predictive and adaptive work. Examples include:

• approved product architecture;
• release planning and funding decisions;
• common definition of done and quality criteria;
• interface control documents;
• compliance reviews;
• integrated testing;
• demonstrations to governance bodies;
• change control for baseline-level decisions.

Step 5: Define decision rights

Specify who may change backlog priorities, approve scope baselines, accept increments, authorize releases, waive controls, and resolve cross-team conflicts. Hybrid failure frequently results from ambiguous authority rather than from the lifecycle model itself.

Step 6: Establish feedback and review cadence

The project may combine daily coordination, iteration reviews, monthly release decisions, quarterly funding gates, and formal validation milestones. Cadence should reflect the speed at which information becomes obsolete and the time required to make responsible decisions.

Step 7: Pilot and inspect

Where organizational experience is limited, pilot the hybrid design on a bounded product area. Review evidence such as defect escape, cycle time, decision latency, requirement volatility, audit findings, and stakeholder satisfaction. Tailor based on observed performance rather than ideology.

5. A Worked Assessment Example

Consider an illustrative project to implement a digital claims platform for a regulated insurer. The platform must comply with privacy and financial-control requirements. Customer interaction features are poorly understood, while data migration and regulatory reporting are more predictable.

The assessment identifies:

• high requirement uncertainty in customer-facing workflows;
• medium technical uncertainty in integration with legacy systems;
• high compliance needs;
• medium organizational maturity, with experienced developers but limited agile product ownership;
• a modular product in which front-end features can be released independently.

The selected lifecycle is hybrid:

1. A predictive initiation establishes business case, funding, regulatory obligations, target architecture, data governance, and major release boundaries.
2. Customer-facing capabilities are developed in two-week iterations, using prototypes and demonstrations.
3. Data migration proceeds through planned rehearsal cycles with formal entry and exit criteria.
4. Each release passes integrated security, privacy, financial-control, and operational-readiness reviews.
5. Product priorities are revised at monthly release planning based on evidence from users and testing.
6. A formal change process applies to architecture, regulatory scope, production data, and contractual baselines; teams retain local flexibility for implementation details.

This design does not treat all work identically. It preserves learning where requirements are uncertain and imposes stronger control where errors could create regulatory or financial harm.

6. Detailed Illustrative Case: Connected Medical Monitoring Device

The following is a fictional teaching case.

Background

MedConnect plans a wearable device that records patient indicators and sends alerts to clinicians. The project includes hardware, embedded software, a mobile application, cloud services, clinical workflows, and regulatory submissions.

Problem

The sponsor initially proposes a fully predictive lifecycle because the device is regulated. The engineering team argues for a fully adaptive lifecycle because user needs and technical performance are uncertain. Both positions are incomplete. A sequential model may delay usability learning, while unrestricted iteration may undermine traceability and safety assurance.

Analysis

The product contains different risk profiles. Hardware enclosure dimensions and manufacturing tolerances require disciplined design control. The alert interface requires user research and repeated usability testing. Sensor algorithms need experiments and verification. Cybersecurity controls require planned threat analysis, testing, and documented remediation. Clinical claims require evidence that cannot be improvised at the end.

The project also has strong dependencies: changes in sensor behavior affect software, mobile notifications, clinical interpretation, and validation evidence. Therefore, the lifecycle must support iteration without losing configuration integrity.

Approach and solution

The team adopts a hybrid lifecycle with five layers:

• Predictive governance: intended use, risk classification, regulatory strategy, quality plan, and major design reviews are approved early.
• Iterative discovery: clinicians and patients participate in time-boxed usability and workflow cycles.
• Incremental technical development: firmware, mobile features, and cloud services are delivered in controlled increments.
• Formal verification and validation: each configuration baseline has traceable requirements, test results, anomaly records, and approval status.
• Integrated release gates: no increment enters clinical evaluation or production without quality, cybersecurity, safety, and operational review.

The team maintains a configuration-controlled repository linking user needs to system requirements, design elements, tests, and unresolved risks. Iteration teams may change implementation details within approved boundaries, but changes affecting intended use, safety classification, critical interfaces, or regulatory claims require formal review.

Outcome

The approach identifies a usability problem early: clinicians misinterpret a warning priority. The interface is redesigned before clinical evaluation, reducing rework. At the same time, a sensor algorithm change reveals an impact on validation evidence, and the traceability system triggers additional testing before approval. The project does not eliminate delay, but it prevents late discovery of both usability and compliance failures.

Learning points

1. Regulation requires evidence and control, not necessarily a purely predictive lifecycle.
2. Product decomposition enables different work modes within one coherent governance system.
3. Traceability is an integration mechanism between iterative development and formal assurance.
4. Hybrid designs require explicit thresholds for escalation and change authority.
5. Early user feedback and disciplined verification are complementary, not competing, practices.

7. Tailoring the Management System

Tailoring involves adapting practices, artifacts, roles, controls, and measures to the project context. It should be documented in a lifecycle and governance plan.

Scope and requirements

Use a product vision and outcome measures for stable direction, a product backlog for evolving detail, and formal requirements baselines where safety, contractual, or regulatory obligations demand them. Requirements should be written at an appropriate level of precision; excessive detail can constrain learning, while insufficient detail can undermine acceptance and traceability.

Planning and estimation

Predictive planning is useful for funding, procurement, major dependencies, and external commitments. Adaptive planning is useful for sequencing uncertain work and revising priorities. Estimates should be expressed with their assumptions and confidence rather than presented as false precision.

Risk and issue management

Risk registers and iterative risk reviews should coexist. High-uncertainty work may be addressed through experiments, prototypes, or technical spikes. A risk response is not complete merely because an activity has been scheduled; the project should define the evidence that will show whether exposure has reduced.

Quality and configuration

A shared definition of quality should cover functional acceptance, nonfunctional performance, security, accessibility, reliability, maintainability, and compliance. Continuous integration and automated tests can support rapid feedback, but automation does not replace independent review, exploratory testing, or professional judgment in high-consequence domains.

Procurement and contracts

Fixed-price, fixed-scope contracts can conflict with evolving requirements. More suitable arrangements may define fixed outcomes, time periods, service levels, interface standards, or option-based increments. Contractual flexibility must not become an excuse for unclear accountability or uncontrolled cost.

Metrics and evidence

Useful measures include lead time, cycle time, throughput, escaped defects, rework, decision latency, forecast accuracy, risk exposure, audit findings, customer outcomes, and benefits realization. Metrics should support learning, not punish teams for revealing problems. A metric that becomes a target may distort behavior; this is a form of Goodhart’s law and requires balanced interpretation.

8. Governance, Ethics, and Responsible Use of Technology

Lifecycle choices distribute power and visibility. Adaptive methods can improve stakeholder voice, but an empowered product representative may still privilege dominant users. Predictive governance can protect accountability, but excessive approval layers can silence operational knowledge and delay urgent learning.

Ethical tailoring requires attention to:

• inclusion and accessibility in stakeholder research;
• privacy and lawful processing of user data;
• transparency of automated decisions;
• equitable distribution of project benefits and burdens;
• psychological safety when reporting defects or risks;
• independence of assurance and acceptance decisions.

Digital tools and AI can assist with backlog analysis, dependency detection, risk signal identification, test generation, forecasting, and document traceability. Their outputs should be treated as advisory unless validated. AI-generated requirements may contain omissions or bias; automated risk scores may reproduce historical data limitations; confidential project information may be exposed through inappropriate tools. Human accountability, data governance, access control, explainability, and review remain essential.

9. Challenges and Limitations

Hybrid lifecycles have significant failure modes.

Method fragmentation occurs when teams use incompatible terminology, artifacts, or definitions of completion. A common governance language and integrated planning view are necessary.

Ceremonial hybridization occurs when organizations retain predictive documents and add agile meetings without changing decision processes. This increases workload without improving learning or control.

Dual authority occurs when a product owner, project manager, functional manager, and quality authority give conflicting direction. Decision rights must be explicit.

Local optimization occurs when teams improve their own throughput while system-level integration deteriorates. End-to-end measures and integrated testing are required.

False adaptability occurs when scope changes frequently but priorities, funding, architecture, or acceptance criteria do not adapt. Change is not agility unless it improves expected value within agreed constraints.

Governance overload occurs when every small decision requires escalation. Thresholds should distinguish reversible local decisions from material changes requiring formal authorization.

No model removes trade-offs. A hybrid lifecycle may increase coordination costs, require more capable leadership, and make performance comparisons difficult. Its justification depends on whether the benefits of differentiated control and learning exceed those costs.

10. Contemporary Developments and Best Practice

Current project environments increasingly combine product operating models, digital engineering, DevOps, systems thinking, and evidence-based governance. Digital twins, automated compliance checks, continuous delivery pipelines, and integrated data platforms can shorten feedback loops while strengthening traceability. However, technology does not create maturity automatically; it can amplify both sound and defective processes.

Best practice is to:

1. select a lifecycle from evidence, not fashion;
2. treat safety, legal, and compliance obligations as explicit constraints;
3. decompose the product before assigning lifecycle modes;
4. integrate adaptive teams through architecture, quality, and release controls;
5. define decision rights and escalation thresholds;
6. make assumptions and confidence visible;
7. measure outcomes and learning as well as activity;
8. review the lifecycle when context changes;
9. tailor documentation to its decision and assurance purpose;
10. preserve human accountability for consequential decisions.

Chapter Summary

Lifecycle selection is a contextual design problem. Predictive approaches provide structure and control where requirements, interfaces, and obligations are stable or where evidence must be authorized in advance. Iterative and adaptive approaches provide learning where requirements or solutions are uncertain. Incremental delivery creates value and feedback progressively. Hybrid lifecycles deliberately combine these properties across components, phases, governance layers, or organizational levels.

A rigorous assessment examines uncertainty, complexity, compliance, organizational maturity, and product characteristics. Suitability models compare the fit between lifecycle options and context; contingency models emphasize that effectiveness depends on the relationship among environment, work, organization, and controls. Quantitative scoring can structure discussion, but safety and compliance constraints should operate as gates rather than merely as weighted preferences.

Successful tailoring integrates control and learning. It specifies decision rights, integration points, quality standards, traceability, feedback cadence, and evidence for review. The lifecycle should be treated as a revisable hypothesis, not a permanent label. Ethical governance, responsible technology use, and attention to human behavior are essential because lifecycle choices shape visibility, authority, accountability, and stakeholder influence.

Key Terms

Lifecycle: The pattern of phases, activities, decisions, and transitions through which a project creates its deliverable.

Predictive lifecycle: A lifecycle in which scope and the solution are substantially defined before execution.

Iterative lifecycle: A lifecycle that refines the solution through repeated cycles of learning and development.

Incremental lifecycle: A lifecycle that delivers usable portions of the product over time.

Adaptive lifecycle: A lifecycle designed for evolving requirements and frequent feedback.

Hybrid lifecycle: An intentional combination of predictive, iterative, incremental, or adaptive elements.

Uncertainty: Lack of knowledge about requirements, technology, environment, execution, or outcomes.

Complexity: The degree of interaction, interdependence, novelty, and nonlinearity in a project system.

Compliance: Conformance with applicable laws, regulations, standards, contracts, or policies.

Organizational maturity: The capability to perform, govern, learn, and improve project work consistently.

Product characteristic: A property of the deliverable, such as modularity, criticality, testability, or reversibility.

Suitability: The degree to which a lifecycle fits the conditions of a project.

Contingency theory: The view that effective management arrangements depend on contextual conditions.

Tailoring: Deliberate adaptation of practices, controls, roles, artifacts, and measures.

Traceability: The ability to link needs, requirements, designs, tests, decisions, and evidence.

Decision rights: Explicit authority to make specified project decisions.

Stage gate: A formal review point at which continuation, change, or termination is authorized.

Configuration baseline: An approved version of a product or set of project artifacts subject to controlled change.

Technical debt: Future cost created by expedient technical decisions or deferred quality work.

Definition of done: Shared criteria determining when a work item or increment is complete and acceptable.

Review Questions

Short Answer Questions

1. What is the difference between an iterative lifecycle and an incremental lifecycle?
2. Why should compliance requirements not automatically lead to a purely predictive lifecycle?
3. Identify three sources of project uncertainty.
4. What is meant by tailoring a project lifecycle?
5. Why should safety or regulatory constraints often be treated as gates rather than weighted scores?

Long Answer Questions

1. Explain how uncertainty, complexity, compliance, organizational maturity, and product characteristics jointly influence lifecycle selection.
2. Compare suitability and contingency perspectives in the design of hybrid project lifecycles.
3. Describe a method for decomposing a project into components that may require different lifecycle approaches.
4. Discuss how traceability and configuration management can integrate adaptive development with formal assurance.
5. Critically evaluate the principal failure modes of hybrid lifecycles and propose controls for each.

Analytical / Application Questions

1. A public-sector data platform has stable reporting obligations but uncertain user workflows and low organizational experience with agile delivery. Design and justify a hybrid lifecycle, including governance gates, iteration practices, and capability-building actions.
2. A project’s weighted suitability scores favor an adaptive lifecycle, but the lifecycle cannot produce evidence required by a safety regulator. Explain how the decision should be made and redesign the lifecycle.
3. Using the illustrative medical-device case, identify two decisions that should remain within an iteration team’s authority and two decisions that require formal escalation. Justify each classification.

Multiple Choice Questions with Answers

Question 1

Which condition most strongly supports an adaptive lifecycle?

A. Stable requirements and proven technology

B. High requirement uncertainty with frequent stakeholder access

C. Fixed design and sequential physical construction

D. A requirement for extensive pre-approval evidence

Correct Answer: B. High requirement uncertainty with frequent stakeholder access

Question 2

What is the principal purpose of a hybrid lifecycle?

A. To use as many methodologies as possible

B. To eliminate all project uncertainty

C. To combine different control and learning mechanisms according to context

D. To avoid defining decision rights

Correct Answer: C. To combine different control and learning mechanisms according to context

Question 3

Which item should generally be treated as a lifecycle constraint or gate rather than only as a weighted preference?

A. Team meeting duration

B. Developer familiarity with a tool

C. A safety or regulatory evidence requirement

D. Preferred estimation technique

Correct Answer: C. A safety or regulatory evidence requirement

Question 4

In the suitability model S_L = ∑(w_i × f_i,L), what does w_i represent?

A. The lifecycle name

B. The importance weight of context dimension i

C. The number of project iterations

D. The total project budget

Correct Answer: B. The importance weight of context dimension i

Question 5

Which characteristic most favors incremental delivery?

A. The product cannot be divided into usable capabilities

B. Usable portions can provide value independently

C. No stakeholder feedback is available

D. Every decision is irreversible

Correct Answer: B. Usable portions can provide value independently

Question 6

What is a common risk of adding agile ceremonies to a conventional project without changing decision processes?

A. Ceremonial hybridization

B. Improved traceability

C. Reduced governance workload

D. Automatic organizational maturity

Correct Answer: A. Ceremonial hybridization

Question 7

In the medical-device case, which decision would most likely require formal review?

A. A minor implementation refactoring within approved boundaries

B. Changing the intended use or regulatory claim

C. Choosing the order of two development tasks

D. Selecting a team retrospective format

Correct Answer: B. Changing the intended use or regulatory claim

Question 8

Why is product decomposition important in hybrid lifecycle design?

A. It ensures every component uses the same method

B. It reveals which components have different uncertainty and control needs

C. It removes the need for integration testing

D. It transfers all decisions to the sponsor

Correct Answer: B. It reveals which components have different uncertainty and control needs

Question 9

Which practice best integrates adaptive development with formal assurance?

A. Eliminating all documentation

B. Using traceability between requirements, designs, tests, and evidence

C. Allowing uncontrolled baseline changes

D. Measuring only the number of meetings

Correct Answer: B. Using traceability between requirements, designs, tests, and evidence

Question 10

What is the most appropriate view of a selected lifecycle in a changing project context?

A. A permanent label that cannot be revised

B. A hypothesis that should be reviewed using evidence

C. A substitute for governance

D. A contract that prevents learning

Correct Answer: B. A hypothesis that should be reviewed using evidence