Developing the Project Charter

Introduction

The project charter is the foundational authorization document for a project. It converts an organizational need, opportunity, compliance obligation, or strategic intention into an authorized temporary endeavor. Although the charter is usually concise, its importance is disproportionate to its length: it establishes why the project exists, what it is expected to achieve, who is accountable, what authority the project manager possesses, and how the organization will judge success.

A charter is not merely an administrative form. It is a governance instrument, a boundary-setting device, and a shared interpretation of the project’s business case. It provides a reference point for later decisions concerning scope, resources, priorities, risks, changes, and stakeholder expectations. In practice, many project failures can be traced to weak initiation: objectives are vague, benefits are assumed rather than defined, authority is unclear, or stakeholders hold conflicting interpretations of the intended outcome.

At postgraduate level, chartering should therefore be understood as both a design activity and a negotiation process. The project manager must synthesize strategic intent into operational commitments while recognizing uncertainty, competing interests, organizational politics, ethical constraints, and the limits of available information.

Learning Objectives

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

1. Explain the purpose, governance role, and characteristics of a project charter.
2. Integrate purpose, justification, objectives, scope, milestones, budget, assumptions, risks, stakeholders, authority, and success measures into a coherent charter.
3. Distinguish outputs, outcomes, benefits, constraints, assumptions, risks, and exclusions.
4. Critique charter quality using tests of clarity, coherence, feasibility, traceability, and authorization.
5. Identify and resolve conflicts among sponsors, project managers, users, delivery teams, and other stakeholders.
6. Establish an appropriate sponsor–project manager authorization relationship.
7. Apply chartering principles to a complex project situation and recognize ethical and governance implications.

1. The Charter as a Governance Instrument

A project charter formally recognizes the existence of a project and authorizes its initiation. In many organizations, the sponsor approves the charter, while the project manager contributes substantially to its development. The exact approval authority depends on organizational governance, portfolio controls, delegated financial authority, and regulatory requirements.

The charter performs four connected functions:

• Strategic function: It links the project to organizational strategy, policy, customer need, regulatory obligation, or a clearly articulated opportunity.
• Authorization function: It establishes that the project may proceed and identifies who may commit organizational resources.
• Coordination function: It creates a common reference for stakeholders who may otherwise interpret the project differently.
• Control function: It defines the initial boundaries against which scope changes, risks, progress, and decisions can be assessed.

The charter should not attempt to replace the project management plan. The charter is produced during initiation and establishes high-level commitments. The project management plan is progressively elaborated during planning and explains how the work will be executed, monitored, controlled, and closed. Similarly, the charter does not replace a detailed business case, requirements specification, contract, benefits realization plan, or risk register. It should, however, be consistent with those documents where they exist.

1.1 Project output, outcome, and benefit

A recurring source of charter weakness is the failure to distinguish three concepts:

• An output is a deliverable produced by the project, such as a software platform, facility, policy, or training program.
• An outcome is the change enabled by using the output, such as reduced processing time or improved service access.
• A benefit is a measurable improvement in organizational or stakeholder value, such as lower operating cost, increased revenue, reduced risk, or improved safety.

For example, a project may deliver a digital claims platform (output), enable faster claims processing (outcome), and reduce average claims cost by 12 percent (benefit). A charter that states only “implement a new platform” describes activity and output but not the value the project is intended to create.

1.2 The charter and the business case

The business case explains why investment is justified. It may contain options analysis, cost estimates, expected benefits, financial evaluation, strategic alignment, risk exposure, and assumptions. The charter translates the selected investment decision into an authorized project. If the business case is weak or unresolved, the charter should not conceal that weakness through confident language. Instead, it should identify unresolved matters, decision gates, and conditions of authorization.

2. Anatomy of a High-Quality Charter

A useful charter is concise but sufficiently complete to support informed authorization. The following elements are normally integrated rather than written as disconnected fields.

2.1 Project identity and purpose

The charter should state the project name, sponsoring organization, proposed project manager, date, version, and decision status. The purpose statement should answer: Why is this project being undertaken now?

A strong purpose statement identifies the organizational problem, opportunity, or obligation. For example:

The project will modernize the regional hospital’s appointment system to reduce patient waiting time, improve clinician scheduling, and meet new accessibility requirements.

This is stronger than “implement an appointment system” because it communicates the problem and intended direction of value creation.

2.2 Justification and strategic alignment

Justification should make the case for action. It may refer to:

• strategic objectives;
• customer or citizen needs;
• legal, regulatory, or safety obligations;
• operational inefficiency;
• market opportunity;
• technology obsolescence;
• risk reduction; or
• social, environmental, or public value.

Strategic alignment should be explicit. A project can be well managed yet strategically inappropriate. The charter should identify which organizational objective the project supports and, where possible, the contribution pathway from deliverable to benefit.

2.3 Objectives and success criteria

Objectives describe intended results. They should be specific enough to guide decisions and assess achievement, but not so detailed that the charter becomes a requirements document. A useful objective identifies an outcome, a target, a timeframe, and sometimes a measurement method.

For example:

Within six months of implementation, reduce the median customer onboarding time from five business days to two business days without increasing compliance exceptions.

This objective is more useful than “improve onboarding.” It also reveals a potential trade-off: speed must not be achieved by weakening compliance.

A project may have several levels of objectives:

Success criteria should include both delivery success and project or investment success. Delivery success may concern time, cost, quality, and scope. Investment success concerns whether the resulting capability produces the intended benefits. A project can deliver on schedule and still fail if users do not adopt the solution or if benefits are not realized.

2.4 High-level scope and exclusions

Scope defines the boundaries of the project. At charter level, scope should identify major deliverables, affected processes, organizational units, locations, technologies, and interfaces. Equally important are explicit exclusions.

For example, the scope may include design, configuration, data migration, user training, and deployment for three regional offices. Exclusions may include replacement of the organization-wide finance system and support for offices outside the region.

Scope should be expressed in terms that stakeholders can understand. Vague phrases such as “all necessary improvements” create uncontrolled expectations. Scope also needs vertical coherence: the proposed deliverables must be sufficient to achieve the stated objectives, and the objectives must be relevant to the stated purpose.

2.5 Milestones and phase boundaries

A charter normally contains major milestones rather than a detailed schedule. Milestones may include approval, procurement, design completion, pilot launch, readiness review, deployment, transition to operations, and benefits review.

Milestones serve governance as well as scheduling. They create points at which the sponsor can confirm continued viability, authorize expenditure, review risks, or approve movement into the next phase. A milestone should represent a meaningful decision or achievement, not merely the passage of time.

2.6 Budget and resource commitment

The charter should state the approved or estimated funding envelope, the basis of estimate, major resource categories, and funding conditions. At initiation, precision may be limited. It is better to label a figure as an order-of-magnitude estimate than to present false accuracy.

Where a contingency is included, its purpose should be clear. A contingency reserve addresses identified uncertainty within the approved scope; it is not a general fund for unauthorized additions. Management reserve, where used under organizational policy, is controlled at a higher governance level and should not be confused with contingency.

For earned value environments, budget terminology must be used consistently. Three commonly used quantities are:

• Planned value (PV): authorized budget for work scheduled by a given date.
• Earned value (EV): budgeted value of work actually completed by that date.
• Actual cost (AC): actual cost incurred for completed work by that date.

A basic cost variance is:

Here, CV is cost variance and all three quantities are expressed in the same monetary unit and measured at the same time. A positive CV indicates that the value of completed work exceeds its actual cost; a negative CV indicates cost inefficiency. This relationship is applicable only when the project has a reliable performance measurement baseline and credible progress data. It should not be used to create a misleading appearance of control during initiation, when EV and AC may not yet be meaningful.

2.7 Assumptions, constraints, and dependencies

These terms should not be merged.

• An assumption is treated as true for planning purposes, although it may not yet be verified. Example: a key supplier will remain available throughout implementation.
• A constraint is a limitation that restricts choices. Example: the solution must comply with a statutory data-hosting requirement.
• A dependency is a relationship in which project progress or success relies on another activity, decision, system, supplier, or project.

Assumptions should be testable and assigned owners where possible. An assumption that proves false may become a risk, issue, or reason to revisit authorization. Constraints should be ranked because not all restrictions have equal importance. Dependencies should be visible at governance level when they could affect the project’s critical path or benefits.

2.8 Initial risks and opportunities

The charter does not need a complete risk register, but it should identify material uncertainties that could affect authorization. Each significant risk should communicate the event, cause, potential effect, and initial response direction.

For example:

If the legacy data contains inconsistent customer identifiers, migration may delay deployment and reduce reporting reliability; early profiling and a staged cleansing approach will be used.

This is more useful than “data risk.” Opportunities should also be considered. A project may have the possibility of early benefits, shared infrastructure, or process simplification that deserves active management.

Risk statements should not be used to transfer accountability unfairly. The sponsor remains accountable for strategic risk acceptance and major trade-offs, while the project manager coordinates day-to-day risk management within delegated authority.

2.9 Stakeholders and governance

A charter should identify the sponsor, project manager, customer or product owner, primary users, affected operational leaders, delivery partners, governance bodies, and regulators where relevant. It need not list every individual, but it should make authority and influence visible.

Stakeholder analysis should consider both formal power and practical influence. A group without formal approval rights may still determine adoption, operational continuity, or public legitimacy. The charter should identify how major stakeholder interests will be represented and how unresolved disagreements will be escalated.

2.10 Authority and decision rights

Authorization is incomplete unless decision rights are clear. The charter should specify, as appropriate:

• who approves the charter and major changes;
• who authorizes expenditure within defined limits;
• who accepts deliverables;
• who resolves scope and priority conflicts;
• who may approve schedule or budget changes;
• who accepts residual risk; and
• who decides whether the project should continue, pause, redirect, or terminate.

A project manager may be accountable for coordinating delivery without possessing unlimited authority over budget, personnel, procurement, or technical decisions. The charter should therefore define delegated authority rather than rely on assumptions about the project manager’s status.

3. Integrating the Charter: Coherence Rather Than Completion

A charter is not high quality merely because every heading has been filled. The central test is coherence. The elements should reinforce one another.

A useful logic chain is:

Need → purpose → objectives → deliverables → outcomes → benefits → measures

The chain should also be tested in reverse. If the stated benefits cannot plausibly result from the deliverables, the charter contains a theory-of-change weakness. If objectives cannot be measured, success criteria are inadequate. If deliverables exceed the stated purpose, scope may be inflated.

A charter can be evaluated using five quality tests:

1. Clarity: Can a knowledgeable reader understand what is being authorized?
2. Traceability: Can each major deliverable be linked to an objective and intended benefit?
3. Feasibility: Are time, funding, capabilities, dependencies, and constraints plausible?
4. Completeness: Are material assumptions, risks, stakeholders, exclusions, and decision rights visible?
5. Governance fitness: Does the document provide a legitimate basis for authorization, escalation, and continued oversight?

3.1 Internal consistency review

Before approval, reviewers should ask questions such as:

• Does the budget cover the scope, including transition and operational readiness?
• Do milestones reflect the actual dependencies?
• Are benefits owned by someone outside the project where appropriate?
• Is the project manager being held accountable for decisions outside delegated authority?
• Are quality and compliance requirements treated as success conditions rather than optional enhancements?
• Are exclusions explicit enough to prevent predictable disputes?
• Does the risk profile justify the proposed governance and reporting frequency?

Traceability matrices can support this review. A simple matrix may connect objectives to deliverables, measures, owners, and assumptions. Its purpose is not bureaucracy but detection of gaps and unjustified commitments.

4. Negotiating Conflicts During Charter Development

Chartering is frequently a conflict-resolution process. Stakeholders may agree that a problem exists but disagree about the desired solution, acceptable risk, delivery date, or definition of success.

4.1 Typical conflicts

Common conflicts include:

• the sponsor wants rapid delivery while users demand extensive functionality;
• finance seeks cost reduction while operations seeks resilience;
• compliance requires controls that appear to increase schedule and cost;
• the project manager identifies unrealistic commitments that senior leaders want retained;
• technical teams recommend a scalable architecture while business leaders prefer a cheaper short-term solution;
• one department expects benefits while another must absorb the disruption and cost.

These are not always interpersonal problems. They may represent genuine differences in value, risk tolerance, incentives, or time horizon.

4.2 A principled conflict-resolution method

A practical sequence is:

1. Separate positions from interests. “Launch in three months” is a position; the underlying interest may be meeting a regulatory deadline or protecting market reputation.
2. Make the trade-off explicit. State what is gained and what is sacrificed under each option.
3. Use evidence. Apply estimates, regulatory requirements, user research, dependency analysis, and risk assessment rather than status or optimism alone.
4. Generate options. Consider phased scope, pilots, alternative procurement, additional resources, changed quality thresholds, or revised sequencing.
5. Identify non-negotiables. Safety, legal compliance, ethical obligations, and essential controls cannot normally be traded away for convenience.
6. Assign the decision to the correct authority. The project manager should not unilaterally accept strategic or enterprise-level risk.
7. Record the decision and its rationale. The charter or decision log should preserve what was agreed, by whom, and under what conditions.

When no agreement is possible, escalation is not failure. It is a proper governance mechanism, provided the unresolved issue is clearly framed and alternatives are presented.

5. Sponsor–Project Manager Authorization

The sponsor and project manager have complementary roles. The sponsor owns the investment case and provides organizational legitimacy. The project manager leads the coordinated delivery effort within authorized boundaries.

The sponsor commonly:

• champions the project;
• secures or sponsors funding;
• confirms strategic alignment;
• removes organizational obstacles;
• makes decisions beyond delegated project authority;
• accepts major risks and trade-offs; and
• sponsors transition and benefits realization.

The project manager commonly:

• develops and maintains the integrated delivery approach;
• coordinates people, suppliers, and workstreams;
• manages risks, issues, dependencies, and changes;
• reports credible information to governance bodies;
• protects the integrity of the approved baseline; and
• escalates decisions that exceed authority.

The sponsor should not use the charter to impose impossible commitments without acknowledging the consequences. The project manager should not treat the charter as protection from accountability for foreseeable delivery problems. Authorization is best understood as a mutual commitment: the sponsor authorizes the project and provides support; the project manager accepts responsibility for managing delivery transparently within the agreed mandate.

A mature authorization conversation addresses four questions:

1. What exactly is being authorized?
2. What authority and resources are being delegated?
3. Which conditions, assumptions, or stage gates limit authorization?
4. How will changes, risks, and continued viability be governed?

6. Applied Case: The Regional Hospital Appointment Transformation

The following is a fictional illustrative case.

Background

A regional hospital operates appointment booking through telephone queues, email, and several departmental spreadsheets. Patients report long waiting times, clinicians experience unused appointment capacity, and administrators spend substantial time reconciling records. A new accessibility regulation also requires improved digital access for patients with disabilities.

The chief operating officer proposes a project to introduce an integrated appointment platform. The initial request states: “Implement the system within four months for a budget of $600,000.”

Problem

The request is too narrow and potentially misleading. It identifies a product but not the full organizational problem. It also omits data migration, accessibility testing, training, process redesign, privacy controls, and operational transition. The four-month target may be achievable for software configuration but not for safe organizational adoption.

Stakeholders hold conflicting views. The sponsor wants visible improvement before the annual performance review. Clinicians want flexible scheduling. The information security team requires additional testing. Patient representatives demand accessible non-digital options. Finance wants the budget capped at $600,000.

Analysis

The project team conducts an initiation workshop and identifies the following logic:

• Purpose: improve access and appointment coordination while meeting accessibility obligations.
• Outcome: patients obtain appointments more quickly and staff use capacity more effectively.
• Deliverables: configured platform, migrated validated data, redesigned booking processes, accessibility-compliant interfaces, training, and transition support.
• Benefits: reduced median waiting time, fewer booking errors, improved appointment utilization, and regulatory compliance.

The team also identifies a critical assumption: departmental data can be reconciled without extensive manual correction. A major risk is that poor data quality will delay migration. A key dependency is approval from the hospital privacy committee.

Approach and solution

Rather than accepting the original request unchanged, the sponsor and project manager negotiate a staged charter:

• Stage 1: six-week discovery, data profiling, accessibility assessment, and detailed design.
• Stage 2: pilot in two departments, including training and user acceptance testing.
• Stage 3: controlled rollout to the remaining departments following a readiness review.

The initial authorization covers discovery and pilot expenditure, with later rollout subject to evidence from the stage-gate review. The target of four months is retained for pilot operation rather than full organizational deployment. The budget is divided into a committed amount for discovery and pilot work and a separately approved estimate for rollout.

Success measures include:

• reduction in median patient booking time from five days to two days within three months of rollout;
• at least 95 percent successful completion of critical accessibility tests;
• fewer than 2 percent appointment records requiring post-migration correction;
• at least 85 percent of relevant staff completing training before deployment; and
• no unresolved high-severity privacy or safety defects at go-live.

The charter assigns the sponsor authority to approve stage progression, the project manager authority to coordinate delivery within the approved stage budget, the clinical operations lead authority to accept workflow design, and the privacy committee authority to approve data-handling controls.

Outcome

The staged charter does not eliminate uncertainty, but it makes uncertainty governable. It prevents the project from claiming full deployment certainty before data and compliance issues are understood. It also preserves urgency by delivering a pilot while protecting patients and staff from an uncontrolled rollout.

Learning points

1. A product request is not automatically a well-defined project purpose.
2. Scope must include adoption, transition, quality, and compliance work when those are necessary for benefits.
3. Stage-gate authorization can reconcile pressure for speed with uncertainty and risk.
4. Success measures should include benefit, quality, adoption, and safety indicators.
5. Authority should be distributed according to expertise and accountability rather than organizational title alone.

7. Ethical, Regulatory, and Contemporary Considerations

Charter development has ethical significance because it frames which interests are recognized and which risks are accepted. A charter that excludes affected communities, understates uncertainty, or presents optimistic benefits as facts can produce formally authorized but socially irresponsible projects.

Important governance questions include:

• Have vulnerable or less powerful stakeholders been represented?
• Are privacy, safety, accessibility, environmental, and labor implications visible?
• Are benefits being claimed for groups that may not receive them?
• Does the budget include responsible assurance and transition activities?
• Are risks being transferred to users, suppliers, or communities without informed consideration?
• Is the project manager being pressured to sign an authorization that contains knowingly unrealistic commitments?

Digital and AI-enabled projects require additional charter considerations. These may include data provenance, model validation, explainability, cybersecurity, human oversight, bias assessment, intellectual property, records retention, and accountability for automated decisions. The presence of an AI component does not remove the need for a clear purpose; indeed, it makes purpose and boundaries more important. A charter should state what the system may and may not decide, what human review is required, and how harmful or erroneous outputs will be detected and addressed.

Contemporary projects also face climate, supply-chain, geopolitical, and workforce uncertainties. A high-quality charter need not predict every disruption, but it should identify material exposure and establish whether resilience, sustainability, or responsible procurement is part of the project’s success definition.

8. Limitations and Common Failure Modes

Several recurring practices weaken charters:

• Template completion without critical thinking: every field is filled, but the logic between fields is absent.
• False precision: early estimates are stated as fixed commitments despite limited information.
• Solution-first framing: a preferred technology is selected before the problem and benefits are understood.
• Scope ambiguity: inclusions are listed but exclusions are omitted.
• Benefit inflation: optimistic benefits are recorded without owners, baselines, or measurement methods.
• Authority ambiguity: the project manager is named but decision rights are not defined.
• Risk concealment: material uncertainties are excluded to improve approval prospects.
• Governance overload: the charter contains excessive detail that obscures the few decisions requiring executive attention.
• Static authorization: the document is approved once and never revisited when assumptions or strategy change.

The appropriate response is not to make every charter longer. It is to make it more decision-useful. A concise charter with explicit uncertainty is stronger than a lengthy document that creates an illusion of certainty.

9. Best-Practice Review Checklist

Before seeking approval, reviewers should confirm that:

• the need and strategic rationale are explicit;
• objectives describe measurable intended results;
• deliverables are connected to outcomes and benefits;
• scope and exclusions are understandable;
• milestones identify meaningful decision points;
• budget figures state their status and uncertainty;
• assumptions, constraints, dependencies, and risks are distinguished;
• material stakeholders and affected groups are represented;
• sponsor and project manager responsibilities are clear;
• delegated authority and escalation routes are documented;
• quality, compliance, ethical, and accessibility conditions are explicit;
• success measures include adoption and benefits where relevant; and
• the sponsor has made an informed authorization decision.

Chapter Summary

The project charter is the principal authorization and governance instrument created at project initiation. It connects organizational need to purpose, objectives, deliverables, outcomes, benefits, and measures. A credible charter defines high-level scope and exclusions, milestones, budget status, assumptions, constraints, dependencies, risks, stakeholders, authority, and decision rights.

Charter quality depends on coherence rather than the mechanical completion of headings. Reviewers should test clarity, traceability, feasibility, completeness, and governance fitness. Conflicts should be addressed by exposing underlying interests, making trade-offs explicit, using evidence, generating options, and escalating decisions to the proper authority. The sponsor provides strategic legitimacy and organizational support; the project manager accepts responsibility for coordinated delivery within delegated authority.

A mature charter acknowledges uncertainty instead of concealing it. It may use staged authorization, conditional commitments, and explicit decision gates to balance urgency with responsible governance. Ethical, regulatory, accessibility, privacy, safety, sustainability, and AI-related considerations should be included whenever they affect project legitimacy or success. Ultimately, the charter is a negotiated promise: it authorizes action while defining the conditions under which that action remains justified.

Key Terms

Project charter: A document that formally authorizes a project and records its initial mandate, boundaries, objectives, and governance arrangements.

Sponsor: The person or body that champions the project, supports authorization, and makes decisions beyond delegated project authority.

Project manager: The person responsible for coordinating and managing project delivery within the authorized mandate.

Business case: The analysis that explains why an investment or project is justified.

Purpose: The fundamental reason the project is being undertaken.

Objective: A defined intended result that guides action and evaluation.

Deliverable: A verifiable product, service, capability, or result produced by project work.

Outcome: A change enabled by the use or adoption of a project deliverable.

Benefit: A measurable improvement in value, performance, position, or condition.

Scope: The boundaries of what the project includes and excludes.

Milestone: A significant event, decision point, or achievement in the project lifecycle.

Assumption: A proposition treated as true for planning purposes but subject to uncertainty.

Constraint: A limitation that restricts project choices or execution.

Dependency: A relationship in which one activity, decision, system, or project relies on another.

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

Success criterion: A condition or measure used to judge whether an objective or result has been achieved.

Stage gate: A formal review point at which continuation, modification, pause, or termination is decided.

Delegated authority: The decision-making power formally assigned to a role or governance body.

Benefits realization: The process of ensuring that intended benefits are achieved, measured, and sustained.

Traceability: The ability to connect needs, objectives, deliverables, measures, decisions, and benefits through a defensible logic chain.

Review Questions

Short Answer Questions

1. What are the four principal governance functions of a project charter?
2. Distinguish an output, an outcome, and a benefit using an example.
3. Why should a charter state exclusions as well as inclusions?
4. What is the difference between an assumption and a constraint?
5. Why is delegated authority important in sponsor–project manager relations?

Long Answer Questions

1. Explain how a project charter translates a business case into an authorized project mandate.
2. Discuss the criteria that can be used to evaluate charter quality and internal coherence.
3. Explain how milestones and stage gates support governance under conditions of uncertainty.
4. Compare the responsibilities of the sponsor and project manager, including the boundaries between them.
5. Discuss the ethical and regulatory considerations that should influence charter development for a digital or AI-enabled project.

Analytical / Application Questions

1. A sponsor demands a fixed launch date and budget, while the project manager reports that requirements and dependencies are unresolved. How should the parties redesign the charter and authorization decision?
2. Construct a need-to-benefit logic chain for a university student-services modernization project. Identify at least two assumptions, two risks, two exclusions, and three measurable success criteria.
3. Critique a charter that promises a 30 percent productivity improvement but contains no baseline, benefit owner, adoption plan, or operational transition activities. What revisions are necessary before authorization?

Multiple Choice Questions with Answers

Question 1

Which statement best describes the primary authorization role of a project charter?

A. It provides the detailed task schedule for every work package.

B. It formally recognizes the project and authorizes its initiation within defined boundaries.

C. It replaces the organization’s business case and benefits plan.

D. It guarantees that the project will meet its stated objectives.

Correct Answer: B. It formally recognizes the project and authorizes its initiation within defined boundaries.

Question 2

Which sequence most accurately represents the logic connecting project need to value?

A. Budget → risk → activity → contract → benefit

B. Need → purpose → objectives → deliverables → outcomes → benefits

C. Milestone → assumption → supplier → output → strategy

D. Scope → invoice → issue → resource → benefit

Correct Answer: B. Need → purpose → objectives → deliverables → outcomes → benefits

Question 3

A project produces a new digital claims platform, which enables faster processing and reduces claims cost. The reduced claims cost is the project’s:

A. Deliverable

B. Constraint

C. Benefit

D. Milestone

Correct Answer: C. Benefit

Question 4

Which item is an assumption rather than a constraint?

A. The solution must comply with data-hosting legislation.

B. The project cannot exceed the approved funding limit.

C. The supplier will remain available throughout implementation.

D. The system must pass mandatory security testing.

Correct Answer: C. The supplier will remain available throughout implementation.

Question 5

What is the main purpose of explicitly documenting project exclusions?

A. To eliminate the need for stakeholder engagement.

B. To prevent predictable disputes about what the project does not cover.

C. To ensure that all requested features are included later.

D. To transfer accountability from the sponsor to the project team.

Correct Answer: B. To prevent predictable disputes about what the project does not cover.

Question 6

Which responsibility most appropriately belongs to the sponsor?

A. Coordinating every daily project task.

B. Accepting strategic risks and resolving decisions beyond delegated authority.

C. Writing every technical requirement.

D. Performing all user acceptance testing.

Correct Answer: B. Accepting strategic risks and resolving decisions beyond delegated authority.

Question 7

If planned value is $100,000, earned value is $90,000, and actual cost is $80,000, the cost variance is:

A. $10,000 favourable

B. $10,000 unfavourable

C. $20,000 favourable

D. $20,000 unfavourable

Correct Answer: A. $10,000 favourable

Question 8

Which review question primarily tests charter traceability?

A. Is the document less than five pages long?

B. Can each major deliverable be linked to an objective and intended benefit?

C. Has the project manager selected a preferred software tool?

D. Does every stakeholder receive identical authority?

Correct Answer: B. Can each major deliverable be linked to an objective and intended benefit?

Question 9

A stage gate is best understood as:

A. A detailed technical specification for a deliverable.

B. A formal point for deciding whether and under what conditions the project should continue.

C. An informal meeting held only after project closure.

D. A reserve fund for unauthorized scope.

Correct Answer: B. A formal point for deciding whether and under what conditions the project should continue.

Question 10

Which practice most weakens a project charter?

A. Making exclusions explicit.

B. Using conditional authorization where uncertainty is high.

C. Presenting early estimates as fixed commitments despite limited information.

D. Defining escalation routes and decision rights.

Correct Answer: C. Presenting early estimates as fixed commitments despite limited information.