Agile, Adaptive and Hybrid Initiation

Introduction

Traditional project initiation assumes that a substantial amount of scope can be defined before execution begins. A business case is prepared, requirements are baselined, a project manager is appointed, and a charter authorizes delivery against an agreed plan. This logic remains appropriate where requirements are stable, technology is well understood, compliance obligations are precise, and change is costly or dangerous.

Many contemporary initiatives do not have these characteristics. Digital products, artificial-intelligence services, platform transformations, data programmes, and customer-facing innovations operate in conditions of uncertainty. Stakeholders may understand the problem but not the solution. User needs may change during development. Technical feasibility may only become clear through experimentation. Competitors, regulations, and market conditions may shift before the original plan is complete.

Agile initiation does not mean eliminating initiation. It means changing what initiation is intended to achieve. Instead of pretending that all scope can be known at the outset, initiation establishes a credible direction, a testable value proposition, an investment boundary, decision rights, and mechanisms for learning. Agile and hybrid initiation therefore combines strategic control with progressive elaboration.

The central managerial challenge is to remain sufficiently disciplined to protect value, ethics, resources, and organisational alignment while remaining sufficiently adaptive to respond to evidence. A successful initiation creates an environment in which teams can discover the right solution without losing sight of why the work is being funded.

Learning objectives

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

1. Distinguish predictive, adaptive, and hybrid approaches to initiation.
2. Construct a product vision, value hypothesis, lean business case, and adaptive charter.
3. Design an outcome-oriented roadmap and select an appropriate minimum viable product (MVP).
4. Explain release funding, capacity-based investment, and guardrails for adaptive governance.
5. Develop a team charter that clarifies authority, collaboration, and accountability.
6. Apply progressive elaboration while preserving strategic, financial, legal, and ethical control.
7. Critically evaluate the limitations and risks of agile and hybrid initiation.

1. Reframing initiation under uncertainty

Initiation traditionally answers five questions:

• What is the project expected to deliver?
• Why is it needed?
• Who is responsible for delivery?
• How much will it cost and how long will it take?
• Who authorizes and governs it?

In an adaptive environment, these questions remain essential, but their answers are expressed differently. A team may know the customer problem, strategic objective, budget envelope, and constraints while still lacking detailed requirements. The initial authorization should therefore distinguish between knowns, assumptions, hypotheses, and unknowns.

A useful initiation statement has four layers:

This structure prevents a common error: treating an early solution concept as if it were a validated business outcome. A proposed mobile application, data platform, or workflow redesign is not itself the business value. It is a means through which value may be created.

Predictive, adaptive, and hybrid initiation

A predictive initiation seeks to establish a relatively complete baseline before execution. An adaptive initiation authorizes a direction and a learning process, with detail emerging through short delivery cycles. A hybrid initiation deliberately combines approaches—for example, adaptive product development within a predictive regulatory, procurement, infrastructure, or funding framework.

The choice should be based on uncertainty, not fashion. Agile is not automatically appropriate for safety-critical construction, statutory compliance, or work requiring fixed interfaces. Conversely, a detailed fixed-scope plan may be irresponsible when user needs and technical feasibility are unknown.

2. Product vision and strategic alignment

A product vision describes the future state the initiative intends to create for users and the organisation. It is broader than a feature list and more concrete than a slogan. A useful vision identifies a target user or beneficiary, a significant problem or opportunity, the desired change, and the strategic relevance of that change.

For example:

For regional hospital patients who struggle to obtain timely appointment information, the service will provide an accessible digital scheduling experience that reduces avoidable contact-centre demand and improves continuity of care.

The statement does not prescribe every screen or technical component. It gives the team a stable purpose while leaving room to discover the best implementation.

A strong product vision should be:

• outcome-oriented rather than feature-oriented;
• meaningful to users and sponsors;
• consistent with organisational strategy;
• sufficiently stable to guide prioritisation;
• open to alternative solutions;
• testable through evidence.

Strategic alignment should be demonstrated rather than asserted. The initiation document can include a traceability chain:

Strategic objective → user or system problem → expected outcome → evidence measure → investment decision.

For instance, a strategic objective to improve customer retention may lead to a problem statement concerning service delays, an outcome target concerning resolution time, and a measure based on verified customer and operational data. This chain makes it harder to justify work merely because a senior stakeholder prefers a particular technology.

3. Value hypotheses and assumptions

A value hypothesis is a provisional claim about how an intervention will create measurable benefit. It is not a promise that the benefit will occur. It should identify the target population, intervention, expected behaviour or outcome, and evidence required for validation.

A practical form is:

We believe that [intervention] for [target group] will produce [desired outcome], because [reason]. We will consider the hypothesis supported if [measure] changes from [baseline] to [target] within [period], without violating [constraints].

Example:

We believe that guided self-service for claims status will reduce avoidable call-centre contacts among retail policyholders because customers mainly call to obtain progress information. The hypothesis will be supported if status-related calls fall by 20% within three months of adoption, while complaint rates and accessibility incidents remain within approved limits.

The hypothesis contains a baseline, target, period, and guardrails. Without these elements, a team may report activity—such as completed features or registered users—instead of value.

Assumption mapping

At initiation, assumptions should be made visible and classified. Common categories include:

• desirability: users experience the problem and want the proposed change;
• viability: benefits justify continuing investment;
• feasibility: the solution can be built and operated;
• usability and accessibility: intended users can use it effectively;
• compliance: legal, regulatory, privacy, and security requirements can be met;
• operational readiness: the organisation can adopt and support the result.

A simple assumption register records the statement, importance, uncertainty, validation method, owner, and review date. High-impact and high-uncertainty assumptions should be tested early. This is more valuable than asking a team to produce detailed estimates for low-confidence requirements.

4. The lean business case

A lean business case is a decision instrument, not a shortened traditional report. It provides enough information to authorize discovery or delivery while explicitly identifying uncertainty. Its contents should be proportionate to the investment and risk.

A useful lean business case includes:

1. Problem or opportunity: What condition requires action?
2. Strategic alignment: Which objective or obligation does it support?
3. Users and beneficiaries: Who gains, and who may be affected adversely?
4. Value hypothesis: What measurable change is expected?
5. Options: What credible alternatives, including doing nothing, exist?
6. Initial scope boundary: What is included, excluded, and deliberately undecided?
7. Evidence and assumptions: What is known, inferred, or untested?
8. Delivery approach: Why is an adaptive, predictive, or hybrid approach suitable?
9. Investment request: What funding, people, suppliers, and environments are required initially?
10. Risks and constraints: Which threats require early treatment?
11. Governance: Who decides, reviews evidence, and can stop the work?
12. Success measures: How will value, quality, adoption, and harm be assessed?

Economic reasoning under uncertainty

Early economic analysis should avoid false precision. A project may use expected value when outcomes and probabilities are sufficiently credible. The expected monetary value of discrete outcomes can be represented as:

Here, p_i is the probability of outcome i, V_i is the monetary value of that outcome, and C is the relevant cost. The probabilities should represent explicit assumptions, not arbitrary optimism. The calculation is applicable when outcomes can reasonably be represented in monetary terms and when the decision-maker accepts the probability model. It does not capture all strategic, ethical, distributional, or irreversible consequences.

For a multi-period investment, discounted cash flow analysis may be used:

CF_t is the net cash flow in period t, r is the discount rate per period, and T is the final period. Cash flows must use consistent time periods and currency units. At t=0, the initial investment is normally represented as a negative cash flow. NPV is informative when cash flows and the discount rate are sufficiently estimable; it should not be treated as a precise fact in highly speculative discovery work.

A lean case may use ranges rather than point estimates. For example, initial discovery funding might be approved as £250,000–£350,000, with a review after six weeks based on evidence. This is not weak governance. It is an explicit recognition that uncertainty has economic consequences.

5. MVPs, experiments, and progressive elaboration

The minimum viable product is the smallest product or service capable of generating valid learning or delivering a meaningful initial outcome to a defined user group. It is not necessarily the smallest technically possible system, nor is it permission to release unsafe or poor-quality work.

An MVP should be defined by the learning or outcome it is intended to establish. A useful design sequence is:

1. Identify the most important uncertain value or feasibility assumption.
2. Define the smallest ethical experiment that can test it.
3. Specify the evidence and decision rule.
4. Build only what is necessary to obtain reliable evidence.
5. Decide whether to persevere, adapt, scale, or stop.

An experiment may be a prototype, service simulation, technical spike, limited pilot, concierge process, or controlled release. The choice depends on the hypothesis. A clickable prototype may test usability but cannot establish production reliability. A pilot may test adoption but not national scalability.

Progressive elaboration means increasing the detail and confidence of plans as knowledge improves. It does not mean changing direction without discipline. Each elaboration should record what new evidence was obtained, which assumptions changed, and what consequences follow for scope, cost, risk, and benefits.

A product backlog is one mechanism for elaboration, but it should not become a substitute for strategy. Backlog items should trace to outcomes, hypotheses, risks, compliance obligations, or enabling capabilities. Items that cannot be connected to a meaningful purpose deserve challenge.

Prioritisation and economic sequencing

Prioritisation should consider value, urgency, risk reduction, dependencies, learning, and effort. One commonly used heuristic is weighted shortest job first (WSJF):

Cost of delay is often estimated as the sum of relative scores for user-business value, time criticality, and risk reduction or opportunity enablement. Job size is a relative estimate of effort or duration. The result is a comparative heuristic, not a measurement of monetary return. It is applicable for ordering work within a common portfolio context, provided the scoring scales are defined consistently. It should not override legal obligations, safety requirements, architectural integrity, or explicit strategic decisions.

6. Adaptive roadmaps and release planning

A traditional schedule predicts detailed activities and dates. An adaptive roadmap communicates direction, themes, outcomes, decision points, and horizons of confidence. It should not imply a level of certainty the evidence cannot support.

A useful roadmap has three horizons:

• Now: work sufficiently understood and actively planned;
• Next: likely priorities requiring further refinement;
• Later: strategic possibilities, dependencies, or options not yet committed.

Roadmaps may be organised by outcomes rather than features. For example, “reduce onboarding abandonment” is a stronger theme than “add three screens.” The team can then evaluate alternative solutions while preserving the intended result.

Release planning should address:

• the user group and operational context for each release;
• the outcome or learning expected;
• readiness, security, accessibility, and compliance criteria;
• dependencies and technical constraints;
• measures to be monitored after release;
• rollback, support, and incident arrangements;
• the decision to expand, revise, or stop.

Dates may be fixed while scope remains variable, or scope may be fixed while the release date remains variable. The choice should be explicit. A fixed-date public commitment with unlimited scope is not adaptive; it merely hides risk.

7. Funding and governance for adaptive work

Adaptive funding shifts attention from approving a total list of features to funding a product capability, value stream, or sequence of validated increments. Several models are possible:

• Discovery tranche: small initial funding to test problem, feasibility, and value assumptions.
• Release funding: funding authorised for a defined release or outcome boundary.
• Capacity funding: funding a stable multidisciplinary team for a period, subject to evidence reviews.
• Guardrail funding: a budget envelope with explicit thresholds for risk, spend, architecture, and compliance.
• Portfolio allocation: periodic allocation across products or strategic themes.

The model should preserve accountability for public money, shareholder resources, and affected communities. Governance questions include:

• Who owns the product outcome?
• Who can change priorities?
• What decisions are delegated to the team?
• What evidence is required to continue funding?
• Which risks require escalation?
• What conditions trigger pause, pivot, or termination?
• How are benefits tracked after delivery?

An adaptive governance forum should review evidence, not merely percentage completion. Useful evidence includes validated user behaviour, operational performance, quality trends, security findings, financial consumption, and progress against outcome measures.

The charter in an adaptive context

An adaptive project or product charter should authorize the system of work rather than freeze every detail. It normally contains:

• purpose, vision, and strategic alignment;
• problem statement and target users;
• initial value hypotheses and success measures;
• scope boundaries and explicit exclusions;
• initial funding and capacity assumptions;
• roles, decision rights, and escalation paths;
• delivery approach and review cadence;
• quality, security, privacy, accessibility, and regulatory constraints;
• major dependencies, risks, and assumptions;
• roadmap horizons and initial release intent;
• termination and transition criteria.

The charter should identify which elements are stable and which may evolve. For example, regulatory obligations may be non-negotiable, while interface design may remain emergent. This distinction prevents adaptive practice from being used to evade obligations.

8. Team charters and empowered delivery

A team charter is a social and operating agreement for the people doing the work. It complements, but does not replace, the project charter. It should clarify:

• team purpose and relationship to the product vision;
• membership, skills, availability, and external specialists;
• responsibilities and decision rights;
• working agreements and communication norms;
• definition of ready and definition of done;
• quality and technical standards;
• conflict-resolution and escalation procedures;
• stakeholder engagement arrangements;
• review, learning, and improvement practices.

Empowerment must be real. A team cannot be held accountable for outcomes if it has no influence over sequencing, design, or technical decisions. At the same time, empowerment does not mean unlimited autonomy. Teams operate within strategic, financial, legal, security, architecture, and ethical boundaries.

The team charter should also address psychological safety and inclusion. Diverse perspectives improve problem framing and risk detection, but only when dissent is welcomed and power differences are managed. A senior sponsor who dominates workshops may create apparent agreement while suppressing important information.

9. Hybrid initiation in regulated and complex environments

Hybrid initiation is particularly valuable where product discovery is uncertain but surrounding obligations are predictable. Consider a healthcare digital service. User interaction design may be explored iteratively, while clinical safety, privacy impact assessment, procurement, records management, accessibility, and deployment approval follow formal controls.

A hybrid model separates the work into control domains:

This separation should be based on risk and knowledge, not on organisational politics. A hybrid plan can become confused if every activity is labelled both agile and predictive without clarifying the actual decision rules.

10. Applied case: municipal benefits service

Background

The fictional City of Northbridge operates a housing-support benefits service. Applicants submit forms through a portal, but many abandon the process and telephone the service centre for assistance. Processing staff also re-enter data manually. The city wishes to improve access while reducing avoidable administrative work.

Problem and initial analysis

The sponsor initially proposes a complete replacement portal with a twelve-month fixed scope. Discovery interviews reveal that the main difficulties are unclear eligibility information, repeated requests for the same evidence, inaccessible language, and uncertainty about application status. A large replacement is therefore not yet justified.

The team records four critical hypotheses:

1. Plain-language eligibility guidance will reduce unsuitable applications.
2. Reusing verified resident information will reduce repeated data entry.
3. Status notifications will reduce “where is my application?” calls.
4. Assisted digital support is necessary for residents who cannot use the portal independently.

The fourth hypothesis prevents digital efficiency from being confused with public value. A portal that excludes vulnerable residents may reduce cost while worsening service equity.

Lean case and approach

The city authorises a ten-week discovery tranche with a cross-functional team consisting of a product manager, service designer, researcher, technical lead, developer, accessibility specialist, benefits officer, data-protection adviser, and contact-centre representative. The tranche has three decision gates:

• after interviews and service mapping: confirm the highest-value problem;
• after prototype testing: confirm usability and accessibility direction;
• after a limited technical pilot: decide whether a release is safe and worthwhile.

The initial MVP is not a full replacement portal. It is a limited status-notification service for one benefits category, integrated with existing case data, accompanied by assisted support. It must meet security, privacy, accessibility, records, and service-continuity requirements before release.

Governance and measures

The product charter specifies that the product manager may reorder backlog items within the approved outcome boundary. Changes affecting statutory eligibility, personal-data processing, or approved funding require formal review. The team tracks:

• reduction in status-related calls;
• application completion rate;
• average processing time;
• accessibility test results;
• error and complaint rates;
• adoption across demographic groups;
• operational cost and support demand.

A reduction in calls alone is not treated as success. Calls might fall because residents cannot obtain help. The outcome review therefore examines both efficiency and access.

Outcome

The pilot shows that status notifications reduce repeat calls, but the integration generates occasional data mismatches. The city does not scale immediately. It funds a short hardening increment, strengthens reconciliation controls, and expands user research with residents requiring assisted support. The original replacement-portal concept is divided into smaller service improvements.

Learning points

The case demonstrates that adaptive initiation can reduce premature commitment, but only when governance is explicit. The MVP is a controlled learning and service increment, not an excuse to bypass quality. The city preserves strategic control by defining outcome measures, funding boundaries, decision rights, and non-negotiable protections while allowing the solution to evolve.

11. Challenges, limitations, and failure modes

Agile theatre

An organisation may adopt stand-ups, backlogs, and iteration names while retaining command-and-control decisions and fixed-scope assumptions. This produces ceremony without adaptability. The remedy is to change decision rights, funding logic, and evidence reviews—not merely vocabulary.

Feature-driven value claims

Teams may count completed stories, releases, or registrations as value. These are output measures. Outcomes require evidence of changed behaviour, performance, benefit, or social condition. Output measures remain useful for flow and delivery management but cannot substitute for benefits evaluation.

Under-specification of risk

“Details will emerge” is not an adequate treatment of cybersecurity, safety, privacy, accessibility, architecture, or operational resilience. Unknown requirements should be discovered, but known obligations must be identified at initiation and embedded in acceptance criteria and governance.

Stakeholder overload and decision latency

Adaptive work requires frequent engagement. Yet excessive meetings, unclear authority, and a large stakeholder group can slow decisions. A stakeholder model should distinguish consultation, collaboration, approval, and information roles.

Local optimisation

An empowered team may optimise its product while creating problems for enterprise architecture, operations, suppliers, or other services. Cross-product dependencies, shared platforms, and portfolio constraints therefore require coordination mechanisms.

Premature scaling

A successful pilot may not prove that a service is secure, affordable, maintainable, or effective at scale. Scaling decisions should consider operational capacity, technical debt, support, inclusion, data quality, and long-term economics.

Ethical and distributional harm

Value is not distributed equally. An initiative may benefit frequent users while disadvantaging people with disabilities, limited connectivity, low digital literacy, or minority language needs. Initiation should ask who benefits, who bears risk, who is absent from the evidence, and what remedy exists when harm occurs.

12. Technology and AI in adaptive initiation

Digital collaboration tools, automated analytics, feature flags, experimentation platforms, and continuous delivery pipelines can support adaptive initiation by shortening feedback cycles. They do not create valid learning automatically. Poorly designed metrics can reward clicks rather than meaningful outcomes, and automated deployment can amplify defects at scale.

AI introduces additional initiation questions:

• What decision or service is AI intended to improve?
• Is the data lawful, relevant, representative, and sufficiently governed?
• What level of human oversight is required?
• How will accuracy, bias, explainability, security, and drift be assessed?
• What is the appeal or correction mechanism for affected people?
• Can the system be withdrawn safely?

An AI initiative should begin with a problem and value hypothesis, not with the availability of a model. A small prototype may establish technical feasibility but says little about fairness or operational suitability. Model evaluation must therefore be connected to the real decision context and its consequences.

13. Best-practice principles

1. Authorize purpose and boundaries before prescribing detailed solutions.
2. Make assumptions and uncertainty visible.
3. Express value as outcomes and evidence, not activity alone.
4. Fund learning in proportion to uncertainty and risk.
5. Define the MVP around a meaningful, ethical learning objective.
6. Separate fixed obligations from emergent design choices.
7. Use roadmaps to communicate intent and confidence, not false certainty.
8. Give teams decision rights that match their accountability.
9. Review evidence at regular investment points.
10. Treat accessibility, privacy, security, safety, and equity as initiation concerns.
11. Preserve the option to stop, pivot, or scale.
12. Maintain traceability from strategy to hypothesis, release, measure, and benefit.

Chapter Summary

Agile, adaptive, and hybrid initiation responds to uncertainty without abandoning governance. Its central outputs are a product vision, value hypotheses, lean business case, adaptive roadmap, funding boundary, team charter, and explicit decision system. These instruments authorize direction and learning rather than pretending that all detail is known at the start.

The product vision connects users, problems, outcomes, and strategy. Value hypotheses make assumptions testable. Lean business cases support proportionate investment decisions and should use ranges, evidence, and explicit uncertainty. MVPs and experiments are designed to test important assumptions, while progressive elaboration increases detail as knowledge improves. Adaptive roadmaps communicate horizons of confidence, and release planning combines outcomes with readiness and safety criteria.

Adaptive governance reviews evidence such as user behaviour, quality, risk, financial consumption, and benefits rather than relying only on completion percentages. Release, capacity, tranche, and guardrail funding can provide flexibility while retaining accountability. Team charters clarify empowerment, collaboration, and constraints. Hybrid initiation is especially suitable where discovery is uncertain but regulatory, financial, technical, or operational controls are stable.

Finally, agility is not a licence to avoid ethics, compliance, accessibility, security, or benefits accountability. Effective initiation protects strategic control while allowing solutions to evolve in response to credible evidence.

Key Terms

Product vision: A concise statement of the future user and organisational outcome a product seeks to create.

Value hypothesis: A testable claim about how an intervention will produce a measurable benefit.

Lean business case: A proportionate investment case that makes value, assumptions, uncertainty, options, and governance explicit.

Adaptive initiation: Initiation that authorizes direction, boundaries, and learning while allowing detail to emerge.

Hybrid approach: A delivery approach combining adaptive and predictive practices for different elements of the work.

Minimum viable product: The smallest ethical product or service increment that can deliver value or generate valid learning.

Progressive elaboration: Increasing plan detail and confidence as evidence becomes available.

Product backlog: A dynamically ordered inventory of work, outcomes, risks, and capabilities.

Roadmap: A communication and planning view showing intended outcomes, themes, horizons, and decision points.

Release funding: Investment authorized for a defined product release or outcome boundary.

Capacity funding: Funding allocated to maintain a stable team or capability for a defined period.

Guardrail: A boundary governing acceptable risk, spend, quality, architecture, or compliance.

Team charter: An agreement defining a team’s purpose, membership, responsibilities, decision rights, and working practices.

Outcome: A measurable change in behaviour, performance, condition, or benefit.

Output: A produced deliverable, feature, service component, or activity result.

Assumption: A proposition accepted provisionally for planning or decision-making.

Experiment: A deliberately designed activity intended to test an assumption or hypothesis.

Empirical governance: Governance based on observed evidence, inspection, adaptation, and explicit decision rules.

Cost of delay: The relative or monetary consequence of postponing work.

WSJF: A prioritisation heuristic calculated as Cost of Delay divided by Job Size.

Review Questions

Short Answer Questions

1. How does adaptive initiation differ from predictive initiation?
2. What elements should a value hypothesis contain?
3. Why is an MVP not simply the smallest technically possible product?
4. Identify three contents of an adaptive charter.
5. What is the purpose of a team charter?

Long Answer Questions

1. Explain how a lean business case can support governance when requirements are uncertain.
2. Compare release funding, capacity funding, and traditional total-scope project funding.
3. Discuss how progressive elaboration can be used without allowing uncontrolled scope expansion.
4. Explain why hybrid initiation is appropriate for regulated digital services.
5. Critically evaluate the claim that agile methods reduce the need for project governance.

Analytical / Application Questions

1. An organisation wants to build a complete customer portal, but user needs and technical integration risks are unclear. Design an initial product vision, two value hypotheses, an MVP, and three evidence-based decision points.
2. A team reports that its project is successful because it released many features, but adoption and customer outcomes have not improved. Analyse the problem and propose a revised measurement and governance approach.
3. Design a hybrid initiation model for an AI-assisted public-sector service. Identify the adaptive elements, fixed controls, funding boundary, team decision rights, and ethical safeguards.

Multiple Choice Questions with Answers

Question 1

Which statement best describes adaptive initiation?

A. It eliminates the need for a business case and sponsor.

B. It authorizes direction, boundaries, and learning while allowing detail to emerge.

C. It baselines all requirements before any user research.

D. It transfers all governance decisions to the delivery team.

Correct Answer: B. It authorizes direction, boundaries, and learning while allowing detail to emerge.

Question 2

Which item is most characteristic of a strong value hypothesis?

A. A complete list of technical features

B. A fixed organisational chart

C. A target group, expected outcome, measure, baseline, and target

D. A detailed procurement schedule only

Correct Answer: C. A target group, expected outcome, measure, baseline, and target

Question 3

What is the primary purpose of an MVP?

A. To deliver every feature requested by stakeholders

B. To test an important assumption or deliver a meaningful initial outcome

C. To avoid accessibility and security testing

D. To guarantee the final architecture

Correct Answer: B. To test an important assumption or deliver a meaningful initial outcome

Question 4

A roadmap organised around “reduce onboarding abandonment” rather than “build three screens” is primarily outcome-oriented because it:

A. Removes the need for delivery dates

B. Focuses on the change to be achieved rather than a prescribed feature

C. Prevents stakeholders from changing priorities

D. Guarantees that the outcome will occur

Correct Answer: B. Focuses on the change to be achieved rather than a prescribed feature

Question 5

Which funding approach provides a stable team with investment for a defined period, subject to evidence reviews?

A. Capacity funding

B. Unlimited contingency funding

C. Fixed-scope procurement funding

D. Post-completion reimbursement

Correct Answer: A. Capacity funding

Question 6

Using WSJF, work with a Cost of Delay score of 24 and a Job Size of 6 has a WSJF score of:

A. 4

B. 18

C. 30

D. 144

Correct Answer: A. 4

Question 7

Which item should generally remain a non-negotiable initiation concern in an adaptive project?

A. The exact wording of every future user story

B. The colour scheme of an untested interface

C. Known privacy, security, safety, and regulatory obligations

D. The final sequence of all backlog items

Correct Answer: C. Known privacy, security, safety, and regulatory obligations

Question 8

What is the principal difference between an output and an outcome?

A. An output is always more valuable than an outcome.

B. An output is produced work; an outcome is a measurable change or benefit.

C. An output can only be financial.

D. An outcome is a task assigned to a team.

Correct Answer: B. An output is produced work; an outcome is a measurable change or benefit.

Question 9

In the Northbridge case, why was a reduction in status-related calls insufficient as the only success measure?

A. Calls are never measurable.

B. Fewer calls might result from exclusion or inability to obtain help.

C. The city had no contact centre.

D. Status notifications cannot affect call volumes.

Correct Answer: B. Fewer calls might result from exclusion or inability to obtain help.

Question 10

Which governance practice best preserves strategic control in adaptive work?

A. Reviewing only the percentage of features completed

B. Allowing unrestricted scope changes without escalation

C. Reviewing evidence, outcomes, risk, quality, and financial consumption at decision points

D. Requiring a fully detailed five-year plan before discovery

Correct Answer: C. Reviewing evidence, outcomes, risk, quality, and financial consumption at decision points