9. Software Project, Program and Risk Management

Introduction and Context

Software engineering projects rarely fail because programmers cannot write code. They fail more often because objectives are unclear, estimates are treated as promises, dependencies are ignored, risks are hidden, or organizational priorities change without corresponding decisions about scope, resources, and time. Software project management therefore concerns much more than preparing a schedule. It is the disciplined coordination of people, technology, money, suppliers, information, and decisions so that a software investment produces an intended organizational outcome.

A project is a temporary undertaking that creates a defined product, service, or result. A software project may deliver a mobile application, an enterprise platform, a cloud migration, or a safety-critical control system. A program is a coordinated group of related projects and operational activities managed to obtain benefits that would not be achieved by managing them independently. A portfolio is the collection of projects, programs, products, and other investments selected to implement organizational strategy. These distinctions matter because management decisions differ at each level. A project manager optimizes delivery within agreed constraints; a program manager manages interdependencies and benefits; a portfolio manager decides which initiatives deserve scarce investment.

Risk management connects all three levels. A project risk may concern an unstable interface or unavailable specialist. A program risk may arise from shared architecture or conflicting release schedules. A portfolio risk may result from excessive investment in one technology, market, or supplier. Effective leadership requires these risks to be understood together with value, uncertainty, and strategic opportunity.

Learning Objectives

After studying this chapter, the student should be able to:

1. Distinguish projects, programs, portfolios, products, and operations.

2. Define and control software scope using deliverables, requirements, assumptions, and change mechanisms.

3. Apply estimation approaches including expert judgment, analogy, function points, COCOMO, and agile forecasting.

4. Construct realistic schedules, budgets, staffing plans, procurement strategies, and governance arrangements.

5. Identify, analyze, respond to, and monitor software risks.

6. Evaluate trade-offs among scope, time, cost, quality, value, and organizational capacity.

7. Explain how analytics, automation, and AI can support—but not replace—managerial judgment.

8. Make project, program, and portfolio decisions ethically and transparently.

From Individual Projects to Strategic Portfolios

The traditional project constraint triangle presents scope, schedule, and cost as mutually influential constraints, with quality affected by decisions concerning all three. This model remains useful, but it is incomplete. Contemporary software initiatives also depend on organizational capacity, security, regulatory obligations, architecture, user adoption, and expected benefits. Reducing schedule may require additional staff, but adding staff does not always accelerate a late project because communication and integration costs increase. Reducing scope may preserve a release date, but if the removed capability is essential to adoption, the project may be technically successful yet strategically unsuccessful.

Project governance establishes who is authorized to make decisions, how progress is measured, when escalation occurs, and how evidence is recorded. A useful governance arrangement normally defines a sponsor, project or delivery manager, product or business owner, technical authority, quality and security representatives, and a steering body for major decisions. Governance should be proportionate: a small internal tool does not require the same approval structure as a payment system or medical platform.

Program management becomes necessary when initiatives share resources, architecture, data, vendors, or benefits. The program manager coordinates the dependency network rather than merely aggregating project schedules. For example, a digital banking program may contain projects for customer identity, mobile channels, payments, data migration, and regulatory reporting. A delay in identity services can affect several projects, even if each project is individually well managed.

Portfolio management asks a different question: not “Are we delivering this project efficiently?” but “Should we continue investing in this initiative relative to alternatives?” Portfolio decisions may use strategic alignment, expected value, risk exposure, regulatory necessity, resource feasibility, and time to benefit. A high-performing portfolio may deliberately terminate technically competent projects when their expected value falls below that of competing investments.

Defining Scope Before Estimating

Scope describes the boundaries of the work and the capabilities to be delivered. It includes functional requirements, quality attributes, interfaces, data, migration, documentation, training, deployment, support transition, and explicit exclusions. Scope ambiguity is a major source of estimation error because effort is usually spent not only building features but also clarifying them, integrating them, testing them, obtaining approvals, and supporting operational adoption.

A practical scope baseline contains a problem statement, objectives, assumptions, constraints, deliverables, acceptance criteria, exclusions, and a work breakdown structure (WBS). The WBS decomposes the deliverable into manageable work packages. It should describe outcomes rather than merely listing departments or technologies. “Customer registration service tested and deployed” is more useful than “backend work.” Each work package should have an owner, a completion condition, and an estimate.

Requirements traceability links business needs to requirements, design elements, code, tests, and acceptance evidence. Traceability is especially important where compliance or safety is involved. It also helps assess change impact. A request to alter a pricing rule may affect user interfaces, APIs, databases, reports, tests, training, contracts, and regulatory documentation.

Scope control does not mean resisting every change. It means making changes visible and deciding them deliberately. A change control process records the request, analyzes its effect on cost, schedule, quality, risk, and benefits, identifies alternatives, obtains authorization, and updates the baseline. In agile environments, scope is often managed through a prioritized product backlog and release goals rather than a frozen detailed specification. Agile does not eliminate scope management; it changes the timing and granularity of scope decisions.

Estimating Effort, Cost, and Uncertainty

An estimate is a reasoned prediction, not a commitment. The distinction is central to professional management. A commitment includes an agreed target and the conditions under which it will be achieved; an estimate expresses current knowledge about probable effort, duration, or cost. Estimates should therefore include assumptions, confidence, uncertainty, and a date of validity.

Estimation approaches

Expert judgment is fast and valuable when experts have relevant historical experience. It becomes weak when one senior person gives an unchallenged opinion or when organizational pressure converts an optimistic guess into a budget. Wideband Delphi improves judgment by asking several experts to estimate independently, discuss differences, and repeat the process until a reasoned convergence is reached.

Estimation by analogy compares the proposed system with completed projects, adjusting for differences in size, technology, complexity, team capability, and constraints. It works best when the organization maintains reliable historical data.

Bottom-up estimation decomposes work into activities or work packages and sums their estimates. It provides visibility and supports staffing and scheduling, but it can miss integration, management, procurement, and rework effort. Top-down estimation is useful early, when detail is limited, but may conceal difficult components. Good practice uses more than one method and investigates large differences.

Function points

Function points estimate software size from the functionality delivered to users rather than from lines of code. A traditional analysis counts external inputs, external outputs, external inquiries, internal logical files, and external interface files, assigning complexity weights. The unadjusted function point count may then be adjusted for general system characteristics, depending on the adopted method. Productivity data such as staff-hours per function point converts size into effort.

Function points are useful during early planning and for comparing productivity across technologies. However, counting rules require judgment, and modern event-driven, embedded, analytical, and highly automated systems may not fit equally well. The estimate should therefore be calibrated with organizational history rather than treated as a universal constant.

COCOMO and parametric estimation

The Constructive Cost Model (COCOMO) estimates effort as a function of software size and project characteristics. In its basic form, effort can be represented as:

Effort = a × (Size)^b

where size is commonly expressed in thousands of delivered source instructions and the coefficients depend on the project category. Schedule is then estimated using a separate relationship involving effort. More advanced versions, such as COCOMO II, account for scale factors, effort multipliers, reuse, process maturity, platform constraints, required reliability, and personnel capability.

COCOMO is valuable because it makes assumptions explicit and supports sensitivity analysis. If expected size increases by 20 percent, the effect on effort may be greater than 20 percent when the exponent is above one. Nevertheless, the model is only as credible as its calibration, size estimate, and cost drivers. It should not be used to create false precision, especially for novel products, machine-learning systems, or rapidly changing requirements.

Agile forecasting

Agile teams commonly forecast using backlog size, historical throughput or velocity, iteration length, and an uncertainty range. If a team has 240 estimated backlog points, delivers approximately 30 points per iteration, and works in two-week iterations, a simple forecast is eight iterations. This is not a guaranteed completion date. A range based on observed throughput—perhaps using conservative, typical, and optimistic historical performance—provides a more honest forecast.

Velocity is a planning aid, not a productivity ranking. Comparing velocity between teams is misleading because estimation scales differ. Cumulative-flow diagrams reveal work-in-progress accumulation and bottlenecks. Monte Carlo simulation can repeatedly sample historical throughput and provide probabilities for completion dates or scope outcomes. Such forecasts are useful only when the backlog is sufficiently refined and historical data is representative.

Contingency and reserves

Uncertainty should be represented explicitly. A contingency reserve addresses identified uncertainties whose probability or impact can be estimated. A management reserve may address unforeseen work within the manager’s authority, subject to governance rules. Padding estimates without explanation obscures risk; transparent reserves make uncertainty discussable. Three-point estimates—optimistic, most likely, and pessimistic—can be combined using a weighted expected value, but the result remains a model rather than a fact.

Scheduling, Criticality, and Dependencies

A schedule translates scope into ordered work. Activities have durations, dependencies, resources, milestones, and acceptance conditions. A network diagram shows precedence relationships. The critical path is the sequence of activities with the least scheduling flexibility; delay on this path can delay the project unless corrective action changes dependencies, resources, or scope. Critical-chain approaches additionally consider resource constraints and use buffers to protect delivery.

Schedules should distinguish effort from duration. Ten person-days of effort do not necessarily mean two calendar days with five people. Parallel work may be limited by dependencies, scarce skills, onboarding, communication, and integration. Brooks’s Law captures an important principle: adding people to a late software project can make it later because coordination and training increase.

Milestones should represent meaningful evidence, such as an approved architecture, completed integration test, security authorization, or operational readiness—not merely the passage of time. A schedule becomes a management instrument when each milestone has measurable exit criteria and when slippage leads to an explicit decision.

Budgeting, Staffing, and Procurement

A software budget includes direct labor, contractors, licenses, cloud consumption, hardware, travel, training, testing environments, security assessment, data migration, support transition, and reserves. Total cost of ownership may also include operations, maintenance, technical debt, vendor renewal, and retirement. A low initial bid can be economically poor if recurring costs or lock-in are ignored.

Staffing is a capability problem, not simply a headcount problem. The plan should identify required roles, skills, availability, learning curves, succession, and decision authority. Cross-functional teams reduce handoffs, but highly regulated or technically specialized work may require independent review. Sustainable pace is a risk-control mechanism: chronic overtime increases defects, turnover, and unsafe decisions.

Procurement strategy should follow the nature of uncertainty. A fixed-price contract can provide budget predictability when requirements and acceptance criteria are stable, but it transfers risk through price and may encourage disputes or defensive behavior when scope changes. Time-and-materials arrangements provide flexibility but require strong product ownership, cost controls, and transparent reporting. Agile contracts may use fixed teams and time periods while allowing backlog reprioritization within agreed boundaries. Procurement evaluation should examine security, data ownership, interoperability, exit rights, service levels, supplier viability, accessibility, and auditability—not only price.

Risk Management as a Continuous Decision Process

A risk is an uncertain event or condition that may affect objectives positively or negatively. A negative risk is a threat; a positive risk is an opportunity. An issue is a problem that has already occurred. Treating issues as risks can delay action, while treating risks as certain events can distort plans.

Risk management begins with establishing context: objectives, assumptions, stakeholders, risk appetite, regulatory environment, and categories. Risks can then be identified through workshops, interviews, checklists, lessons learned, architecture reviews, premortems, dependency analysis, and analysis of assumptions. A useful risk statement has a cause, an uncertain event, and an effect—for example: “Because the external identity provider has an unproven throughput limit, authentication may fail during peak enrollment, causing service disruption and regulatory exposure.”

Qualitative analysis ranks risks using probability and impact, sometimes adding proximity, detectability, or velocity. A risk matrix is easy to communicate but can hide important differences: two risks with the same score may require different responses. Quantitative analysis models cost or schedule exposure using probability distributions, decision trees, sensitivity analysis, or Monte Carlo simulation. Expected monetary value is calculated by multiplying probability by impact, but it should not be interpreted as a precise prediction or as permission to ignore catastrophic low-probability events.

Responses to threats include avoiding the uncertain activity, mitigating probability or impact, transferring or sharing consequences, accepting the risk with monitoring and contingency, and escalating beyond the project’s authority. Responses to opportunities may exploit, enhance, share, accept, or escalate them. Every significant response should have an owner, trigger, due date, required resources, and residual-risk assessment.

Risk registers are useful only when actively maintained. They should not become static lists prepared for governance meetings. Leading indicators—defect arrival rates, unresolved dependencies, staff turnover, build failure frequency, cloud cost variance, or declining test coverage—can provide earlier warning than milestone slippage. Risk reviews should ask what has changed, which assumptions remain valid, and whether the organization is taking more exposure than it intended.

Measuring Performance and Governing Decisions

Earned value management compares planned value, earned value, and actual cost to diagnose cost and schedule performance. It can be helpful in plan-driven work with stable work packages, but it may create misleading signals when value is difficult to measure or when agile teams optimize for completed output rather than accounting units. Agile metrics such as cycle time, throughput, work-in-progress, escaped defects, release frequency, and customer outcomes are more informative when interpreted together. No single metric should become a target without considering its potential distortions.

Benefits realization extends measurement beyond delivery. Benefits may include reduced processing time, increased revenue, improved reliability, regulatory compliance, or lower operational risk. A project can meet its scope and schedule while failing to produce benefits because users do not adopt it, data quality is inadequate, or the business process remains unchanged. Benefit owners should be identified before delivery, and post-implementation evaluation should compare actual outcomes with the original rationale.

Governance must also address escalation. Managers should escalate when a decision exceeds delegated authority, when risk appetite is exceeded, when benefits materially decline, or when safety, security, privacy, or legal obligations may be compromised. Concealing unfavorable information to preserve a status report is a professional failure, not successful project management.

Technology, Analytics, and AI in Management

Digital project-management platforms integrate backlogs, repositories, pipelines, incidents, test evidence, financial data, and dashboards. Automation can calculate lead time, detect build failures, identify dependency changes, forecast cloud expenditure, and produce audit trails. These capabilities reduce clerical work and improve evidence-based decisions.

AI can assist with effort classification, defect prediction, schedule scenario generation, document analysis, dependency discovery, and risk summarization. However, AI-generated estimates may reproduce historical bias, confuse correlation with causation, or express unjustified confidence. Sensitive source code, personal data, contractual information, and security findings must not be entered into tools without appropriate controls. Human managers remain accountable for decisions, explanations, fairness, and compliance.

Illustrative Case: The National Benefits Portal

Background

A government agency initiated a program to replace several aging benefits applications with a single portal. The program included identity verification, eligibility assessment, payment integration, case-worker tools, data migration, analytics, and a public mobile channel. The strategic goals were to reduce processing time, improve accessibility, and lower maintenance costs.

Situation and problem

The initial business case promised a complete portal in eighteen months using a fixed budget. Early estimates were based on a previous website project and did not include data cleansing, accessibility certification, external payment interfaces, or training. Six months into delivery, requirements continued to grow, two suppliers reported interface delays, and the agency discovered that legacy records contained inconsistent identities. Executives considered adding staff and requesting overtime to preserve the original date.

Analysis

The program office separated the initiative into projects and mapped dependencies. It found that identity verification and data migration were on the critical path, while several reporting features were not necessary for the first public release. A function-point estimate and a calibrated parametric estimate both indicated that the original scope exceeded available capacity. A risk workshop identified privacy breaches, payment failure, supplier insolvency, inaccessible design, and public resistance as high-impact risks. A Monte Carlo schedule analysis showed that the promised date had a low probability under the existing scope.

Approach and strategy

The steering committee approved a staged release. The first release supported a limited set of high-volume benefits, strong accessibility, secure identity verification, and manual fallback procedures. Nonessential dashboards were moved to a later release. A joint supplier team adopted clear interface contracts and automated integration tests. Data migration began with a pilot and reconciliation controls rather than waiting until the end. The contract was modified to use outcome-based milestones and transparent backlog prioritization. A risk owner was assigned for each major threat, and weekly indicators tracked identity-match rates, payment-test failures, unresolved dependencies, and support-readiness measures.

The program also established a benefits baseline: processing time, successful self-service completion, accessibility defects, support contacts, and operational cost. A privacy impact assessment and independent security review were treated as release conditions, not post-release paperwork.

Outcome

The first release delivered fewer features than the original promise but supported the most important user journeys with a controlled operational transition. The staged approach exposed data-quality problems early, reduced integration uncertainty, and allowed later investments to be evaluated using actual adoption evidence. The original eighteen-month full-scope target was abandoned in favor of a sequence of governed releases. This was not a failure of ambition; it was a correction from schedule optimism to evidence-based portfolio and program management.

Learning points

The case illustrates that scope reduction can protect value when it is guided by user outcomes rather than arbitrary feature removal. It also shows why estimates must include enabling work, why program dependencies can dominate individual project performance, and why privacy, accessibility, security, and operational readiness belong inside the delivery plan. Most importantly, transparent escalation allowed leaders to choose a viable strategy before failure became unavoidable.

Common Failure Modes and Professional Responsibilities

Several recurring mistakes deserve explicit attention. A single-point estimate hides uncertainty. A schedule created before scope is understood creates false confidence. Measuring percentage complete without objective evidence encourages optimistic reporting. Treating all risks as equal distracts from exposure concentration. Adding people without examining bottlenecks increases coordination cost. Freezing an agile backlog to satisfy a fixed plan defeats adaptive learning. Conversely, using agility as an excuse for indefinite scope, weak documentation, or absent accountability is equally harmful.

Ethical management requires truthful reporting, respect for privacy, protection of confidential information, fair treatment of suppliers and staff, and attention to the people affected by software decisions. Managers should not manipulate estimates to obtain approval, suppress defects to meet a milestone, or transfer unreasonable risk to contractors. Accessibility and inclusion are quality and justice concerns, not optional enhancements. Automated decision systems require explainability, bias assessment, appropriate human review, and mechanisms for appeal where people may be materially affected.

Current Developments and Best Practices

Software organizations increasingly manage products continuously rather than delivering isolated projects. Product operating models connect persistent teams with measurable outcomes, while platform engineering provides reusable capabilities for delivery and operations. FinOps practices link cloud consumption to business value. Value-stream management examines the movement from idea to customer outcome, revealing queues and handoffs that traditional project reports may miss.

Useful practices include:

• establish a clear product vision, measurable outcomes, and decision rights;
• estimate with multiple methods and record assumptions and confidence;
• maintain an integrated view of scope, dependencies, capacity, cost, and risk;
• use staged investment and evidence-based continuation decisions;
• distinguish forecasts from commitments and revise them when evidence changes;
• assign owners to risks, dependencies, benefits, and operational readiness;
• combine delivery metrics with quality, security, user, and outcome measures;
• preserve independent assurance for high-consequence systems; and
• conduct retrospectives and post-implementation reviews that produce actual process change.

The central professional habit is to make uncertainty visible early enough for responsible choice. Project management is not the art of defending an obsolete plan. It is the discipline of creating credible options, learning from evidence, and directing resources toward valuable and responsible outcomes.

Chapter Summary

Software project management coordinates scope, estimation, scheduling, budgeting, staffing, procurement, quality, and delivery. Program management adds coordination of interdependent projects and benefits, while portfolio management selects and governs investments according to strategy, value, capacity, and risk. Scope must be defined through deliverables, assumptions, acceptance criteria, and controlled change. Estimation may use expert judgment, analogy, function points, COCOMO, bottom-up analysis, and agile forecasting; all estimates require assumptions and uncertainty ranges. Schedules must reflect dependencies, resource constraints, and criticality. Budgets should include total ownership costs and reserves, and staffing should address capability and sustainable pace. Risk management is continuous: identify, analyze, respond to, monitor, and escalate threats and opportunities. Analytics and AI can strengthen evidence and forecasting but cannot replace accountability. Ethical governance requires transparency, privacy, accessibility, security, fair procurement, and honest reporting. Strategic success is measured not only by delivery but by realized organizational and user benefits.

Key Terms

Project: A temporary undertaking that creates a defined product, service, or result.

Program: A coordinated group of related projects and activities managed to realize shared benefits.

Portfolio: A collection of investments managed to achieve strategic objectives.

Scope baseline: The approved description of deliverables, boundaries, assumptions, and exclusions.

Work breakdown structure: A hierarchical decomposition of project deliverables into manageable work packages.

Requirements traceability: Linking business needs through requirements, design, implementation, tests, and acceptance evidence.

Estimate: A reasoned prediction of effort, duration, cost, or resources under stated assumptions.

Function point: A measure of software functionality based on user-recognizable functions and interfaces.

COCOMO: A parametric software cost model relating size and project attributes to effort and schedule.

Velocity: An agile team’s observed amount of estimated work completed per iteration.

Critical path: The dependency path with the least schedule flexibility.

Contingency reserve: Time or money allocated for identified uncertainties.

Risk: An uncertain event or condition that may affect objectives.

Issue: A problem or event that has already occurred.

Risk appetite: The amount and type of uncertainty an organization is willing to accept.

Risk register: A maintained record of risks, analysis, owners, responses, and status.

Residual risk: Risk remaining after a response has been implemented.

Benefits realization: The process of measuring and achieving intended outcomes from an investment.

Governance: The decision rights, controls, accountability, and oversight arrangements for an initiative.

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

Review Questions

Short Answer Questions

1. Distinguish a project, a program, and a portfolio.

2. Why should an estimate be separated from a delivery commitment?

3. What information should a scope baseline contain?

4. Differentiate a risk from an issue.

5. Why is velocity unsuitable as a direct productivity comparison between teams?

Long Answer Questions

1. Explain how function points and COCOMO support software effort estimation, including their assumptions and limitations.

2. Discuss the relationship among scope, schedule, cost, quality, and organizational capacity in software initiatives.

3. Describe a complete risk-management process from identification through monitoring and escalation.

4. Compare fixed-price, time-and-materials, and adaptive procurement approaches for software work.

5. Explain how program and portfolio management differ from project management and why the distinction matters strategically.

Analytical / Application Questions

1. A team has 180 backlog points and historical throughput ranging from 20 to 30 points per two-week iteration. Forecast the likely delivery range and explain why a single date would be misleading.

2. A project is six months late because a shared identity service is unfinished, while several low-value reports are complete. Analyze the situation using scope, dependency, risk, and program-management concepts, and recommend a response.

3. An executive asks a manager to report that a project is “90 percent complete” despite unresolved security testing and data-migration defects. Explain the ethical and governance issues and propose a more credible reporting approach.

22. Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes program management from project management?

A. Program management focuses only on reducing project cost.

B. Program management coordinates related initiatives and manages shared benefits and dependencies.

C. Program management eliminates the need for project managers.

D. Program management applies only to software maintenance.

Correct Answer: B. Program management coordinates related initiatives and manages shared benefits and dependencies.

Question 2

A software estimate is revised after discovering substantial data migration and accessibility work. What is the most professional interpretation?

A. The revised estimate is evidence of poor programming performance.

B. The original estimate should be retained to preserve commitment.

C. The scope and assumptions have changed, so the forecast should be updated transparently.

D. The additional work should be hidden in management reserve.

Correct Answer: C. The scope and assumptions have changed, so the forecast should be updated transparently.

Question 3

Which technique estimates software size using external inputs, outputs, inquiries, files, and interfaces?

A. Function point analysis

B. Critical-chain analysis

C. Earned value analysis

D. Monte Carlo scheduling

Correct Answer: A. Function point analysis

Question 4

Why can adding staff to a late software project make it later?

A. New staff always reduce code quality.

B. Additional people increase communication and onboarding overhead.

C. Late projects cannot use specialists.

D. Staffing has no relationship to schedule.

Correct Answer: B. Additional people increase communication and onboarding overhead.

Question 5

Which response is most appropriate when a threat can be reduced through an early prototype and performance test?

A. Mitigate the threat

B. Exploit the threat

C. Transfer the threat without analysis

D. Ignore the threat because it is uncertain

Correct Answer: A. Mitigate the threat

Question 6

A team completes 30 backlog points per two-week iteration. What is the main limitation of forecasting 240 points as exactly sixteen weeks?

A. Backlog points are always measured in hours.

B. Velocity is a guarantee rather than an observation.

C. Throughput can vary and backlog estimates may change.

D. Agile teams cannot forecast dates.

Correct Answer: C. Throughput can vary and backlog estimates may change.

Question 7

Which item is an issue rather than a risk?

A. A supplier may become insolvent next quarter.

B. A security vulnerability has already been discovered in production.

C. A payment interface may exceed its capacity limit.

D. A key specialist may become unavailable.

Correct Answer: B. A security vulnerability has already been discovered in production.

Question 8

What is the primary purpose of a work breakdown structure?

A. To rank employees by performance

B. To decompose deliverables into manageable work packages

C. To replace requirements analysis

D. To calculate portfolio value automatically

Correct Answer: B. To decompose deliverables into manageable work packages

Question 9

Which portfolio decision best reflects strategic management?

A. Continue every project that is under budget.

B. Select investments by considering value, alignment, risk, and organizational capacity.

C. Approve the project with the longest schedule.

D. Choose projects solely by technical novelty.

Correct Answer: B. Select investments by considering value, alignment, risk, and organizational capacity.

Question 10

Why should AI-generated project forecasts remain subject to human review?

A. AI cannot process any project data.

B. AI forecasts may reproduce bias, misuse historical patterns, or express false confidence.

C. Human review makes estimates less transparent.

D. AI tools are useful only for writing code.

Correct Answer: B. AI forecasts may reproduce bias, misuse historical patterns, or express false confidence.