Strategy, Economics and Program Leadership

Introduction

A data warehouse is not merely a database implementation. It is an organizational capability through which data is acquired, governed, integrated, analyzed and converted into decisions. Consequently, warehouse success depends as much on strategy, economics, leadership and adoption as on dimensional modeling, query performance or pipeline engineering.

Organizations often begin with a technical request—such as building an enterprise data warehouse, migrating reporting to the cloud or introducing a lakehouse. The deeper management question is whether the proposed capability will produce benefits that justify its total cost and risk. A sound program therefore connects business outcomes, information architecture, operating responsibilities, sourcing choices, financial controls, delivery sequencing and organizational change.

This chapter examines how to construct a business case, select an operating and sourcing model, evaluate costs and benefits, manage cloud consumption, assess organizational readiness and lead a phased warehouse program. It also considers vendor lock-in, governance, responsible use of data and the role of artificial intelligence in contemporary warehouse programs.

Learning Objectives

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

1. Construct and critically assess a data-warehouse business case.

2. Distinguish capital expenditure, operating expenditure, direct cost, indirect cost and total cost of ownership.

3. Compare centralized, federated and hub-and-spoke operating models.

4. Evaluate insourcing, outsourcing, managed services and hybrid sourcing strategies.

5. Develop a phased roadmap with measurable outcomes and decision gates.

6. Analyze cloud consumption, benefits realization, risks and vendor lock-in.

7. Assess organizational readiness, adoption and change-management requirements.

8. Apply governance and leadership principles to a warehouse transformation.

1. From Technical Project to Strategic Capability

A project produces a defined deliverable within a temporary period; a program coordinates related projects to achieve sustained organizational benefits. A warehouse program may include platform modernization, source-system integration, data governance, reporting redesign, master-data improvement, security enhancement and user adoption. Treating all these activities as one software project commonly produces narrow technical success but weak business value.

A strategic warehouse capability has five linked dimensions:

• Information value: trusted data supports decisions, compliance, operational control and innovation.
• Technical capability: platforms, pipelines, semantic models, metadata, security and resilience are fit for purpose.
• Operating capability: roles, processes, service levels and accountability sustain the environment.
• Economic viability: benefits exceed lifecycle costs and risks.
• Organizational adoption: people use the information and alter decisions or processes accordingly.

The strategic unit of analysis should therefore be the business capability and its outcomes, not the technology product. For example, “reduce inventory stock-outs by improving demand visibility” is a stronger objective than “implement a cloud warehouse.”

2. Constructing the Business Case

2.1 The logic of a business case

A business case explains why an investment should be made, what alternatives exist, how value will be created, what resources are required and how uncertainty will be managed. A credible case contains:

1. Problem or opportunity: the current performance gap, regulatory requirement or strategic opportunity.

2. Baseline: current costs, cycle times, error rates, risks and user experience.

3. Options: including doing nothing, incremental improvement, modernization and replacement.

4. Benefits: measurable improvements attributable to the program.

5. Costs: one-time and recurring costs across the whole lifecycle.

6. Risks and assumptions: conditions that may invalidate the forecast.

7. Delivery approach: roadmap, governance and decision rights.

8. Benefits-realization plan: owners, measures, targets and review dates.

The “do nothing” option is essential. It is not cost-free: technical debt, duplicated reporting, manual reconciliation, delayed decisions, audit exposure and security weaknesses may continue or increase. However, the cost of inaction must be evidenced rather than used as an exaggerated threat.

2.2 Benefits categories

Benefits may be financial or non-financial, direct or indirect, and tangible or intangible.

Revenue benefits include improved customer retention, cross-selling, pricing and demand forecasting. Cost benefits include retiring legacy platforms, reducing manual data preparation, lowering report-development effort and improving resource utilization. Risk benefits include better regulatory reporting, stronger access control, improved lineage and reduced dependence on spreadsheets. Strategic benefits include faster experimentation, a common view of performance and improved organizational learning.

Benefits should be expressed as changes from a measured baseline. “Better reporting” is not a benefit metric; “reduce monthly close reporting from ten business days to four” is testable. Every material benefit should have an accountable owner, a measurement method, a target date and an explanation of how the warehouse contributes to the result.

Benefits must not be double-counted. If reduced manual effort is already included in a business unit’s cost-saving estimate, the same labor saving should not also be counted as a platform benefit. Similarly, an increase in revenue should be discounted when the warehouse merely improves attribution rather than causing additional sales.

2.3 Financial evaluation

A simple net benefit is:

Net benefit = Present value of benefits − Present value of costs

This relationship is useful only when amounts are measured over the same period and expressed in comparable monetary units. Future amounts are commonly discounted because money received or spent at different times has different economic value. For a single future amount, present value can be represented as:

PV = F / (1 + r)^t

where F is the future amount, r is the discount rate per period, and t is the number of periods. The formula assumes a constant rate, a clearly defined period and a payment occurring at the end of that period. It should not be applied without considering taxation, inflation, financing conventions or risk-adjusted assumptions.

For a multiyear program, net present value is:

NPV = Σ[(B_t − C_t)/(1+r)^t] − I_0

where B_t and C_t are benefits and operating costs in period t, r is the chosen discount rate, and I_0 is initial investment. A positive NPV indicates that the modeled economic value exceeds the investment under the stated assumptions; it does not prove that the program is strategically wise.

Return on investment is often stated as:

ROI = (Total benefits − Total costs) / Total costs

ROI is easy to communicate but can conceal timing and risk. Payback period indicates how long it takes for cumulative benefits to recover cumulative investment, but it may undervalue benefits that occur after payback. Advanced cases should therefore use NPV, sensitivity analysis and scenario analysis rather than a single ratio.

Worked example: evaluating a warehouse initiative

An illustrative organization estimates an initial implementation cost of $900,000. It expects benefits of $500,000 in year 1, $650,000 in year 2 and $700,000 in year 3. Recurring operating costs are $180,000, $220,000 and $250,000 respectively. Using an illustrative annual discount rate of 8%, the net cash flows are $320,000, $430,000 and $450,000.

The approximate present values are:

• Year 1: $320,000 / 1.08 = $296,296
• Year 2: $430,000 / 1.08² = $368,656
• Year 3: $450,000 / 1.08³ = $357,007

The NPV is therefore approximately $296,296 + $368,656 + $357,007 − $900,000 = $121,959. Under these assumptions the initiative is economically attractive. Nevertheless, the result is sensitive to benefit realization. If only 70% of forecast benefits materialize, the NPV may become negative. This illustrates why adoption, benefit ownership and sensitivity testing are central to the case.

2.4 Total cost of ownership

Total cost of ownership (TCO) includes more than subscription or infrastructure expenditure. A warehouse TCO model should consider:

• discovery, architecture and implementation;
• data acquisition, integration and transformation;
• platform licenses, cloud storage, compute and networking;
• monitoring, support, incident response and service management;
• data quality, metadata, governance and security;
• backup, disaster recovery and business continuity;
• training, change management and user support;
• testing, compliance and audit;
• migration, decommissioning and exit costs.

Costs should be separated into one-time and recurring categories. Cloud services may reduce capital expenditure while increasing variable operating expenditure. This changes financial control requirements: architecture and usage behavior directly affect the monthly bill.

A useful cost model identifies cost drivers rather than merely totals. Examples include data volume, query frequency, concurrency, retention period, refresh frequency, geographic replication, number of environments and number of supported users. Cost allocation should be sufficiently precise to influence behavior but not so complex that it becomes administratively unreliable.

3. Operating Models and Accountability

An operating model defines how work is organized, who makes decisions, how services are delivered and how performance is measured. It should not be confused with an organization chart. It includes governance forums, processes, roles, capabilities, service interfaces and funding mechanisms.

3.1 Centralized model

In a centralized model, one enterprise data function owns the platform, integration standards, core models and often delivery. Advantages include consistency, stronger control, concentrated expertise and reduced duplication. Disadvantages include bottlenecks, distance from domain needs and the risk that the central team becomes a report factory.

Centralization is appropriate where regulatory consistency, scarce skills or enterprise-wide integration are dominant concerns. It should still establish domain engagement and clear service priorities.

3.2 Federated model

In a federated model, business domains retain substantial responsibility for data products and analytical delivery while enterprise governance sets common policies and interoperability standards. This can improve responsiveness and domain ownership, but it requires mature governance, shared definitions and strong architecture. Without these, federation becomes fragmentation.

3.3 Hub-and-spoke model

A hub-and-spoke model combines a central platform, security, architecture and governance “hub” with domain “spokes” responsible for local data products and use cases. It often provides a practical balance between control and responsiveness. Success depends on explicit decision rights: the hub should not control every dashboard, while domains should not redefine enterprise-critical measures independently.

3.4 Data-product and platform thinking

A data product is a managed data asset designed for a defined consumer, with documented meaning, quality expectations, ownership, access controls and support. Platform teams provide reusable capabilities; domain teams provide trustworthy products. This approach can increase reuse and accountability, but it is not a substitute for modeling discipline or enterprise definitions.

Important roles include the executive sponsor, program director, product owner, enterprise architect, data owner, data steward, security officer, platform engineer, analytics engineer and change lead. A RACI matrix can clarify who is responsible, accountable, consulted and informed, but responsibility must be supported by authority, capacity and measurable service obligations.

4. Sourcing Strategy and Vendor Management

Sourcing decisions concern which capabilities should be built internally, purchased, outsourced or shared with a provider. The decision should evaluate strategic importance, internal capability, speed, cost, risk, knowledge retention and reversibility.

Insourcing preserves knowledge and control but may be slower and constrained by recruitment. Outsourcing can provide specialist capacity and predictable delivery, but may create dependency and knowledge loss. Managed services reduce operational burden, particularly for infrastructure, but require effective service-level management. Hybrid sourcing is common: an organization may retain architecture, data ownership and product management while using vendors for platform operations or specialist engineering.

A sourcing evaluation should examine:

• security, privacy and regulatory controls;
• interoperability and open interfaces;
• data portability and exit assistance;
• skills transfer and documentation;
• service levels, support hours and incident obligations;
• pricing transparency and escalation rules;
• subcontractor dependence;
• financial stability and product roadmap;
• intellectual property and reuse rights.

Vendor lock-in

Lock-in occurs when changing provider becomes prohibitively costly, risky or slow. It may arise from proprietary storage formats, specialized APIs, embedded transformation logic, undocumented operational knowledge, contractual restrictions or user dependence on vendor-specific tools. Lock-in is not always irrational: a proprietary capability may create substantial value. The issue is whether the dependency is understood and economically justified.

Mitigation includes open data formats where practical, portable orchestration, documented interfaces, separation of business logic from infrastructure, tested extraction procedures, multi-skilled teams, contractually defined exit support and periodic portability exercises. A multi-cloud strategy is not automatically a solution; it can increase complexity, duplicate controls and raise costs.

5. Cloud Economics and FinOps

Cloud economics differs from traditional infrastructure economics because consumption is elastic, services are granular and costs may be generated by many teams. FinOps is a collaborative operating practice connecting engineering, finance and business teams to maximize value from cloud expenditure.

A useful cloud cost-control cycle is:

1. Inform: make expenditure visible through tagging, allocation, budgets and forecasts.

2. Optimize: improve workload design, scheduling, storage tiers, query efficiency and commitments.

3. Operate: establish accountability, policies, alerts and continuous review.

Cost allocation may be based on business unit, product, environment, workload or usage metric. Shared services require transparent allocation rules. Cost per dashboard is often a poor metric if dashboards trigger very different workloads; cost per successful analytical workload or cost per governed data product may be more meaningful.

Optimization must not damage reliability, security or analytical usefulness. Reducing refresh frequency may save money but undermine a time-critical operational decision. Similarly, aggressive data deletion may violate retention obligations. Every optimization should therefore state its service and compliance impact.

6. Roadmapping and Program Leadership

A roadmap is a sequence of outcomes, dependencies and decisions, not a list of technologies. A credible roadmap normally progresses through stages such as:

Stage 1: Mobilize and discover

Define strategic outcomes, stakeholders, baseline measures, critical data domains, constraints and governance. Establish the sponsor, program team, architecture principles, funding controls and initial risk register.

Stage 2: Establish the foundation

Implement identity and access management, environments, connectivity, metadata, monitoring, data-quality controls, development standards and a thin but useful platform capability. The foundation should support a real business use case rather than become an indefinite infrastructure exercise.

Stage 3: Deliver priority products

Select high-value, feasible use cases with committed business owners. Deliver integrated data products, semantic definitions, quality measures and user workflows. Measure adoption and decision impact, not merely pipeline completion.

Stage 4: Scale and industrialize

Expand domains, automate testing and deployment, improve performance, establish reusable patterns, formalize service management and retire redundant assets. Reassess the operating model as demand grows.

Stage 5: Optimize and renew

Review benefits, usage, cost, risk and architecture. Rationalize unused assets, renegotiate contracts where appropriate, improve portability and identify emerging analytical opportunities.

Each stage should have entry and exit criteria. Examples include an approved security assessment, a named data owner, a tested recovery procedure, defined quality thresholds and evidence of user adoption. Stage gates prevent sunk-cost thinking from driving continued investment in an underperforming initiative.

Program leadership requires balancing delivery pressure with architectural integrity. Leaders should communicate a small number of strategic outcomes, make trade-offs explicit, protect technical teams from uncontrolled scope and create channels through which users can challenge definitions and priorities. A steering committee should make decisions, not merely receive status reports.

7. Readiness, Adoption and Change Management

Organizational readiness concerns whether the organization has the motivation, capability, capacity and conditions required to adopt the new way of working. Assessment should cover:

• executive sponsorship and decision alignment;
• data literacy and analytical skills;
• role clarity and availability of data owners;
• process maturity and documentation;
• technology and integration constraints;
• incentives, performance measures and workload;
• trust in data and willingness to retire familiar reports;
• privacy, security and regulatory competence.

Adoption is not equivalent to login counts. Meaningful adoption may be evidenced by use of certified data products, reduction in manual reconciliation, changed planning behavior, improved decision cycle time or retirement of duplicate reports.

Change management should begin during discovery. A practical approach includes stakeholder mapping, communication of the case for change, role-based training, demonstrations using real decisions, champions in business domains, support channels and feedback loops. Resistance may indicate rational concerns—poor data quality, loss of autonomy, unrealistic workload or fear of surveillance—rather than simple unwillingness. Effective leaders investigate the cause and adjust the program.

8. Risk, Governance and Responsible Data Use

A warehouse program risk register should cover strategic, financial, technical, operational, security, privacy, vendor and adoption risks. Risks should have owners, likelihood and impact assessments, response actions, triggers and review dates. Quantitative scoring is useful for prioritization but should not create false precision.

Governance must address data ownership, classification, access, retention, lineage, quality, ethical use and incident response. Privacy principles such as purpose limitation, data minimization, access control and retention limitation should be built into architecture and operating processes. Sensitive information should not be copied into analytical environments merely because storage is inexpensive.

Artificial intelligence can assist with metadata classification, anomaly detection, documentation, query assistance and cost optimization. However, AI-generated classifications or code require human review, testing and auditability. Models trained on warehouse data can reproduce bias, expose confidential information or produce unsupported conclusions. Governance should define approved uses, data boundaries, validation requirements and accountability for AI-assisted decisions.

9. Illustrative Case: Northstar Health Supplies

Background

Northstar Health Supplies, an illustrative regional distributor, operates five warehouses and serves hospitals and clinics. Its finance, sales and logistics teams maintain separate reports. Monthly performance reconciliation takes twelve business days, inventory data differs between systems and executives cannot reliably compare service levels across regions.

Problem

The organization proposes a cloud data warehouse. The initial technical proposal focuses on migrating all historical data within nine months. Interviews reveal that the most valuable decisions concern stock-out prevention, supplier performance and customer service-level measurement. The organization also has limited data-engineering capacity and strict obligations concerning personal and health-related information.

Analysis

The program team establishes a baseline: 12 days for monthly reconciliation, 18% of priority reports requiring manual correction, and frequent stock-out investigations lasting several days. It identifies three options: continue with local improvements, build a centralized warehouse, or adopt a phased hub-and-spoke model using a managed cloud platform.

The third option is selected. The central team will own security, platform operations, enterprise definitions and shared services. Supply-chain and commercial domains will own certified data products. The business case includes implementation, training, quality controls, support, cloud consumption, recovery, vendor exit and legacy decommissioning. Benefits are assigned to the chief operating officer, chief financial officer and domain leaders rather than to the IT department alone.

Approach and solution

The first release integrates orders, inventory and shipment data for two regions. It introduces a common definition of “available stock,” role-based access, automated quality checks and a service-level dashboard. A data council resolves conflicting definitions. The program uses monthly cost reviews, workload tagging and a query-performance budget. A contract requires export in documented formats and assistance with transition if the provider is replaced.

Change activities include training planners, appointing regional champions and embedding dashboard review into the weekly supply meeting. Legacy reports are not immediately deleted; they are catalogued, compared and retired only after users accept the certified replacement.

Outcome

After the pilot, reconciliation falls from twelve to five business days, manual corrections fall substantially and planners identify stock-out risks earlier. The organization does not claim that every improvement is caused by the warehouse; it records contributing operational changes and continues measurement. The pilot also reveals that cloud compute costs are higher than forecast because exploratory queries scan excessive data. Partitioning, workload controls and user guidance are introduced before expansion.

Learning points

The case demonstrates that a convincing program starts with decisions and measurable baselines. A phased release reduces risk, while federated ownership improves relevance. Financial governance must continue after implementation. Finally, adoption and data-quality work are not secondary activities: they are mechanisms through which technical capability becomes organizational value.

10. Challenges and Limitations

Business cases are predictions, not facts. Benefits may be uncertain, attribution may be difficult and external factors may influence outcomes. Financial models can privilege measurable savings over strategic resilience or public value. NPV depends on assumptions about discount rates, timing and risk. Operating models can fail when authority is unclear or when governance becomes bureaucratic.

Cloud platforms can create rapid innovation but also uncontrolled consumption and dependency. Centralized governance can protect consistency yet slow delivery. Federation can empower domains yet reproduce silos. No model is universally optimal; the appropriate design depends on regulatory context, organizational maturity, data criticality, skills and strategic priorities.

A mature program makes assumptions visible, tests them through pilots, revises forecasts and records both realized and unrealized benefits. It also recognizes that some outcomes—trust, resilience, learning and improved accountability—may be difficult to monetize but remain strategically important.

Best-Practice Principles

1. Start with business decisions and outcomes, not platform features.

2. Include the do-nothing option and make assumptions explicit.

3. Model full lifecycle cost, including exit and decommissioning.

4. Assign benefit ownership to business leaders.

5. Use a governance model that combines enterprise standards with domain accountability.

6. Treat cloud consumption as an operating discipline, not merely a finance report.

7. Design for portability proportionate to the strategic and economic risk of lock-in.

8. Deliver in thin, valuable increments with measurable adoption.

9. Build privacy, security, quality and lineage into the operating model.

10. Reassess the roadmap as evidence changes.

Chapter Summary

A data warehouse program creates value only when technology, economics, governance and organizational behavior work together. A business case should define the problem, establish a baseline, compare alternatives, quantify costs and benefits, expose assumptions and assign responsibility for realization. NPV and related financial tools support decision-making but must be interpreted alongside strategic, risk and non-financial considerations.

Centralized, federated and hub-and-spoke operating models each offer different balances of control and responsiveness. Sourcing decisions should consider capability, security, knowledge retention, portability and exit cost. Cloud adoption requires FinOps practices that connect visibility, optimization and accountability. A phased roadmap should establish foundations, deliver priority data products, scale responsibly and include decision gates.

Readiness and adoption determine whether a warehouse changes decisions in practice. Effective leadership therefore includes stakeholder engagement, role-based capability building, data-quality accountability and benefits management. Governance must address privacy, security, ethics, lineage and responsible AI use. The central strategic lesson is that a warehouse is an enduring organizational capability whose value must be deliberately designed, measured and renewed.

Key Terms

Business case: Structured justification for an investment, including options, costs, benefits, risks and assumptions.

Benefits realization: Process of ensuring that intended organizational benefits are achieved and measured.

Cloud economics: Management of the financial consequences of consuming cloud services.

Data product: Managed data asset designed for defined consumers with ownership, quality and support expectations.

Data steward: Person responsible for maintaining agreed data meaning, quality and use practices.

Federated operating model: Model in which domains retain responsibilities while enterprise standards provide coordination.

FinOps: Collaborative practice linking finance, engineering and business teams to manage cloud value and consumption.

Hub-and-spoke model: Operating model combining central platform capabilities with domain-level delivery and ownership.

Lock-in: Dependency that makes changing a supplier or technology costly, risky or difficult.

Net present value: Discounted value of future net benefits minus initial investment.

Operating model: Arrangement of roles, processes, capabilities, governance and service responsibilities.

Organizational readiness: Degree to which people, processes, skills and leadership can support change.

Program: Coordinated group of related projects managed to achieve sustained benefits.

Return on investment: Benefits net of costs divided by costs, usually expressed as a ratio or percentage.

Sourcing strategy: Deliberate choice of internal, external, managed or hybrid provision of capabilities.

Stage gate: Formal decision point determining whether a program should proceed, change or stop.

Total cost of ownership: All relevant acquisition, operation, support, governance, migration and exit costs.

Vendor management: Governance of supplier performance, contracts, risk, service and transition.

Review Questions

Short Answer Questions

1. Why should the do-nothing option be included in a data-warehouse business case?

2. Distinguish a centralized operating model from a federated operating model.

3. What types of expenditure should be included in warehouse total cost of ownership?

4. Define vendor lock-in and identify one mitigation technique.

5. Why is user adoption different from counting dashboard logins?

Long Answer Questions

1. Explain how a data-warehouse business case should connect strategic objectives, measurable benefits, costs, risks and accountability.

2. Compare centralized, federated and hub-and-spoke operating models, including the organizational conditions under which each is appropriate.

3. Discuss the economic and governance implications of moving from on-premises infrastructure to a cloud warehouse.

4. Describe a phased roadmap for a warehouse modernization program and explain the purpose of stage gates.

5. Critically evaluate the role of leadership and change management in converting warehouse capability into business value.

Analytical / Application Questions

1. An organization forecasts an initial investment of $1,000,000 and net cash flows of $300,000, $450,000 and $500,000 over three years. Using an 8% discount rate, calculate the approximate NPV and explain two non-financial factors that should influence the decision.

2. A business wants to use a single cloud vendor for speed but is concerned about lock-in. Design a proportionate portability and exit strategy, identifying technical, contractual and organizational measures.

3. A warehouse has strong technical performance but low business adoption. Diagnose possible causes using readiness and change-management concepts, then propose a ninety-day intervention plan.

Multiple Choice Questions with Answers

Question 1

Which item is most important for avoiding double-counting in a warehouse business case?

A. Using multiple cloud regions

B. Assigning each benefit an owner and distinct measurement basis

C. Increasing the number of dashboards

D. Selecting a proprietary database

Correct Answer: B. Assigning each benefit an owner and distinct measurement basis

Question 2

In the NPV formula, future net benefits are discounted primarily because:

A. Future cash flows have different economic value from present cash flows

B. Cloud services always become cheaper over time

C. All benefits are intangible

D. Technical debt is eliminated automatically

Correct Answer: A. Future cash flows have different economic value from present cash flows

Question 3

Which operating model combines central platform governance with domain-level ownership?

A. Purely centralized model

B. Unstructured model

C. Hub-and-spoke model

D. Single-user model

Correct Answer: C. Hub-and-spoke model

Question 4

Which is a likely source of vendor lock-in?

A. Documented export procedures

B. Open data formats

C. Portable orchestration

D. Business logic embedded in proprietary services

Correct Answer: D. Business logic embedded in proprietary services

Question 5

What is the primary purpose of FinOps?

A. To eliminate all cloud usage

B. To connect cloud consumption with business value and accountability

C. To replace data governance

D. To prevent analytical experimentation

Correct Answer: B. To connect cloud consumption with business value and accountability

Question 6

Which activity normally belongs in the foundation stage of a roadmap?

A. Retiring every legacy report immediately

B. Establishing identity, monitoring and quality controls

C. Ending stakeholder consultation

D. Removing recovery procedures

Correct Answer: B. Establishing identity, monitoring and quality controls

Question 7

Which statement best describes organizational readiness?

A. The number of servers purchased

B. The ability of people, processes and leadership to support the change

C. The number of vendor contracts signed

D. The volume of historical data loaded

Correct Answer: B. The ability of people, processes and leadership to support the change

Question 8

A cloud cost optimization that reduces refresh frequency should first be evaluated against:

A. Only the storage price

B. Its effects on service requirements and decision usefulness

C. The color of dashboards

D. The number of database tables

Correct Answer: B. Its effects on service requirements and decision usefulness

Question 9

Who should normally own a business benefit such as improved inventory availability?

A. Only the database administrator

B. A relevant business leader with authority over the outcome

C. The cloud provider exclusively

D. The procurement department alone

Correct Answer: B. A relevant business leader with authority over the outcome

Question 10

Why are stage gates valuable in a warehouse program?

A. They guarantee that forecasts are correct

B. They prevent all changes to scope

C. They provide evidence-based points to continue, change or stop investment

D. They eliminate the need for testing

Correct Answer: C. They provide evidence-based points to continue, change or stop investment