Project Initiation & Chartering

Chapter 3
Problem Framing and Opportunity Definition

Post Graduate Program in Project Management
Project Initiation & Chartering   •   Post Graduate

Problem Framing and Opportunity Definition

Introduction

Project initiation begins before a charter is written. It begins with deciding what deserves organized intervention and how that situation should be described. A poorly framed problem produces a poorly governed project: objectives become ambiguous, scope expands, stakeholders disagree about success, and teams commit prematurely to attractive solutions. Conversely, a well-framed problem connects evidence, stakeholder experience, organizational strategy, systems behaviour and the intended value of action.

Problem framing is the disciplined process of defining an undesirable current condition, its consequences, affected stakeholders and plausible causes without confusing symptoms with causes or solutions with needs. Opportunity definition complements this process by identifying a desirable, evidence-supported improvement that is strategically and ethically worth pursuing. Neither process is simply a writing exercise. It is an inquiry that establishes the basis for project authorization while preserving learning and choice.

In project management, framing is especially important because a project is a temporary intervention in a larger system. The project team may deliver a product, service, process change or capability, but the intended benefits depend on organizational adoption, external conditions and interactions among system components. Thus, the project charter should authorize investigation and value creation—not merely the implementation of an early idea.

Learning Objectives

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

  1. Distinguish symptoms, problems, causes, opportunities, needs, requirements and solutions.
  2. Frame problems using systems thinking and stakeholder evidence.
  3. Apply root-cause analysis, design thinking, value-stream analysis and theory of change appropriately.
  4. Construct evidence-based problem and opportunity statements.
  5. Detect solution bias, causal overclaiming and premature commitment.
  6. Evaluate assumptions, boundaries, equity implications, risks and governance requirements.
  7. Translate a validated frame into useful charter content without prescribing an unjustified solution.

1. The Logic of Problem Framing

A problem is not merely a negative statement such as “the system is inefficient.” A useful problem definition identifies a gap between a current condition and a legitimate desired condition. It explains who experiences the gap, how it is evidenced, why it matters, and what constraints shape possible action.

A practical structure is:

In [context], [affected stakeholder or system] experiences [observable condition], evidenced by [data or credible observations]. This matters because [consequences]. The project should investigate how to improve [outcome] within [important constraints], without presuming a particular solution.

An opportunity statement uses a constructive but equally disciplined form:

There is an opportunity to improve [outcome] for [stakeholders] by understanding and addressing [validated need or performance gap], creating value through [intended benefit], while protecting [constraints, rights or safeguards].

The difference between a problem and an opportunity is often rhetorical rather than substantive. A problem emphasizes the gap and harm; an opportunity emphasizes desirable value and possibility. Both require evidence. Optimistic language must not conceal unequal impacts, feasibility limits or unresolved causal uncertainty.

1.1 Important distinctions

TermMeaningCommon error
SymptomAn observable sign of a conditionTreating the sign as the root problem
ProblemA consequential gap between current and desired conditionsDefining it too broadly to guide inquiry
CauseA factor that contributes to the conditionAssuming one cause from correlation
NeedA stakeholder-relevant requirement or desired outcomeTranslating a stated preference directly into a solution
RequirementA verifiable condition that a future intervention must satisfyWriting premature design specifications
OpportunityA credible possibility for beneficial changeEquating novelty with value
SolutionA proposed intervention or responseStarting with it before understanding the problem
BenefitA measurable or observable improvement valued by stakeholdersConfusing deliverables with benefits
AssumptionA proposition treated as true for planning purposesLeaving it untested or invisible

For example, “customers abandon the online application form” is an observation. “The organization loses eligible applicants because the application journey imposes avoidable effort” is a problem hypothesis. “Build a mobile application” is a solution proposal. “Increase completed applications without increasing fraud or excluding users with limited connectivity” is an outcome-oriented opportunity.

2. Systems Thinking: Seeing the Problem in Context

Systems thinking treats a problem as behaviour arising from relationships, feedback, flows and boundaries rather than as an isolated defect. A service delay, for example, may result from staffing policy, demand variability, approval rules, information quality and customer rework. Correcting one visible bottleneck can move the bottleneck elsewhere or create an unintended consequence.

A system description should identify:

  • Purpose: What function does the system serve, and for whom?
  • Elements: People, processes, technologies, resources, rules and institutions.
  • Relationships: Dependencies, hand-offs, incentives, communication paths and authority.
  • Boundary: What is included in the analysis and what is treated as external?
  • Inputs and outputs: Information, materials, decisions, money, time and outcomes.
  • Feedback: How results influence future behaviour.
  • Delays and constraints: Time lags, capacity limits, regulations and scarce resources.
  • Unintended effects: Workarounds, exclusion, risk displacement and local optimization.

A boundary is an analytical choice, not an objective fact. A team that defines a problem only inside its department may miss a cause located in procurement, policy or customer behaviour. A boundary that includes everything becomes unmanageable. The appropriate boundary is therefore provisional and should be tested with stakeholders and evidence.

2.1 Causal reasoning and feedback

Causal claims should be proportionate to evidence. A sequence in time does not prove causation. A useful causal hypothesis identifies a mechanism: “When approval requires three sequential reviews, waiting time increases because work cannot proceed until each review is complete.” This hypothesis can be tested by examining workflow records and speaking with participants.

Feedback can be reinforcing or balancing. A reinforcing loop amplifies change: repeated service failures may reduce trust, which lowers early reporting of issues, allowing failures to persist. A balancing loop counteracts change: increased demand may trigger additional staffing, reducing waiting time. Delays can make a balancing response appear ineffective in the short term. These ideas matter because projects often target a variable without understanding the feedback that governs it.

A systems map, causal-loop diagram or rich picture can support inquiry, but it is not proof. The map records current understanding, exposes assumptions and helps identify where additional evidence is needed.

3. Evidence Before Advocacy

A defensible frame uses multiple forms of evidence. Quantitative data can reveal frequency, duration, variation and distribution. Qualitative evidence explains experience, workarounds, meanings and contextual mechanisms. Documentary evidence includes policies, audit reports, service standards, contracts and prior evaluations. Comparative evidence may show how similar systems perform, although differences in context must be considered.

Useful questions include:

  • What is happening, how often and to whom?
  • Compared with what baseline, target, peer or historical period?
  • How is the condition distributed across locations, roles and demographic groups?
  • What evidence supports the alleged cause rather than only the symptom?
  • What evidence would disconfirm the current interpretation?
  • Which data are missing, biased, outdated or defined inconsistently?

A simple performance measure can be expressed as:

Gap = Desired\0condition − Current\u00a0condition

Here, “gap” is a conceptual difference, not necessarily a directly subtractable numerical quantity. If the conditions are measured numerically, the measures must use the same definition, scale, population and time period. For example, a target of 90% on-time delivery and a current result of 74% give a 16-percentage-point gap, not necessarily a 16% reduction.

Evidence should be disaggregated where appropriate. An average waiting time may improve while waiting time for rural users or people requiring accessibility support worsens. Ethical framing therefore asks not only “Does the average improve?” but also “Who benefits, who bears costs and who may be rendered invisible?”

4. Root-Cause Analysis

Root-cause analysis seeks contributing mechanisms rather than a convenient explanation. It is best understood as an iterative process of hypothesis generation and testing, not a ritual that always produces one root cause.

4.1 The five-whys method

The five-whys method repeatedly asks why an observed condition occurred. Its value lies in revealing assumptions and moving from event to process or system conditions. The number five is not mandatory. Stopping after five questions can be as misleading as asking too few.

Example:

  • Event: Regulatory reports are submitted late.
  • Why? Final data are not available by the reporting deadline.
  • Why? Several departments reconcile records manually.
  • Why? Their systems use different identifiers and definitions.
  • Why? Data governance does not specify a shared master record.
  • Why? Ownership of cross-department information quality is undefined.

This chain is only a hypothesis. Interviews, document review and data analysis may reveal other branches, such as excessive late changes or unrealistic deadlines.

4.2 Fishbone and fault-tree approaches

A fishbone, or cause-and-effect diagram, organizes possible contributors under categories such as people, process, technology, policy, environment and measurement. It is useful for collaborative exploration but does not rank or prove causes.

Fault-tree analysis begins with an undesired top event and decomposes it through logical relationships. An AND relationship means all contributing events are required for the stated event; an OR relationship means any one may contribute. Formal fault trees are most useful where failures and conditions can be defined consistently, such as safety, reliability or cybersecurity analysis. Informal use should not imply numerical probabilities that have not been justified.

4.3 Avoiding causal overreach

Root-cause work fails when teams:

  • confuse correlation with causation;
  • search for individual blame instead of system conditions;
  • stop at a politically convenient explanation;
  • ignore multiple interacting causes;
  • treat a cause as permanently fixed when it may vary over time; or
  • select causes because they fit an available solution.

A cause should be retained as a working hypothesis only when it has a plausible mechanism and supporting evidence. Where evidence is weak, the charter should authorize discovery rather than promise a remedy.

5. Design Thinking and the Discipline of Empathy

Design thinking contributes methods for understanding lived experience and testing interpretations. Its commonly described movement—empathize, define, ideate, prototype and test—is not necessarily linear. Teams may return to earlier stages as new evidence changes the frame.

Empathy research can include contextual observation, interviews, journey mapping, diary studies, service safaris and analysis of support contacts. The purpose is not to collect anecdotes as if they were prevalence estimates. It is to understand tasks, emotions, workarounds, constraints and meanings that operational data may hide.

A journey map identifies stages, user goals, touchpoints, front-stage interactions and backstage processes. It can reveal that a visible service failure originates in an earlier information request or a later hand-off. Personas may help communicate patterns, but they should be based on evidence and must not stereotype or erase minority experiences.

The “define” stage should produce a focused, human-centred problem frame. A strong design-thinking question often takes the form:

How might we enable [stakeholder] to achieve [desired outcome] when [relevant constraint], while protecting [important value]?

“How might we” questions are prompts for inquiry, not proof that a particular intervention is required. Ideation should be deliberately separated from framing sessions when solution fixation is likely. Otherwise, the first plausible idea can shape which evidence is collected.

6. Value-Stream Analysis

Value-stream analysis examines the end-to-end flow required to deliver value, including activities that do not directly transform the product or service. It is particularly useful for operational problems involving delay, rework, queues, hand-offs and information defects.

The analysis should map:

  1. The customer or beneficiary and the value they recognize.
  2. The complete flow from request to outcome.
  3. Processing time, waiting time, rework and hand-offs.
  4. Information, decision and material flows.
  5. Constraints, queues and failure demand.
  6. Measures of quality, speed, cost, safety and experience.

Two measures require careful distinction:

Lead\u00a0time = Completion\u00a0time − Request\u00a0time
Process\u00a0cycle\u00a0efficiency = Processing\u00a0time ÷ Lead\u00a0time × 100%

Lead time includes waiting and other elapsed time. Processing time is the time during which work is actively performed. Process-cycle efficiency is meaningful only when both quantities refer to the same unit of work, period and process boundary; it does not by itself measure quality or customer value.

A value-stream map can expose local optimization. For example, a team may reduce its own processing time by passing incomplete work downstream, increasing total lead time. It can also expose “failure demand”: additional work created because the original service did not work correctly, such as repeat calls caused by unclear instructions.

7. Theory of Change: Connecting Action to Benefit

A theory of change explains how activities are expected to produce outputs, outcomes and longer-term impact. It makes assumptions visible and supports benefits realization planning.

A typical chain is:

Inputs → Activities → Outputs → Short-term outcomes → Intermediate outcomes → Impact

For example:

  • Inputs: trained facilitators and reliable service data.
  • Activities: redesign intake and coach staff.
  • Outputs: revised workflow, training completion and usable guidance.
  • Short-term outcome: fewer incomplete submissions.
  • Intermediate outcome: faster and more equitable access to service.
  • Impact: improved public health outcomes.

The arrows are conditional, not automatic. They depend on assumptions such as staff adoption, stable policy, user access and sufficient demand. External factors—economic conditions, legislation, competing programs or technology outages—may affect results.

A theory of change helps distinguish deliverables from benefits. “A new portal is launched” is an output. “Eligible users complete applications with less avoidable effort” is an outcome. “Population health improves” may be a longer-term impact influenced by many factors beyond the project. The charter should assign ownership and measurement at the level the project can reasonably influence.

8. Constructing High-Quality Problem and Opportunity Statements

A high-quality statement is:

  • Specific: It identifies a meaningful context and affected population.
  • Evidence-based: It includes credible observations or data.
  • Outcome-oriented: It describes consequences rather than prescribing features.
  • Bounded: It defines a manageable analytical domain.
  • Neutral: It avoids embedding an untested solution.
  • Inclusive: It recognizes different experiences and impacts.
  • Testable: It can be refined or challenged through inquiry.
  • Strategically relevant: It connects to organizational purpose or external value.

Weak and improved statements

Weak statementWhy weakImproved statement
“We need an AI chatbot.”Solution-led; need and evidence are absent“Customers make repeated contacts for status information, creating avoidable effort and queue pressure; the project should investigate accessible ways to provide timely, trusted status information.”
“The process is inefficient.”Undefined population, measure and consequence“For small-business permits, applicants wait a median of 28 days, with 35% of cases returned for missing information; this delays business opening and increases staff rework.”
“Staff resist change.”Blames people and hides mechanisms“Adoption of the revised procedure varies across teams because training, role authority and performance measures are inconsistent.”

A statement should be accompanied by an evidence register containing source, date, definition, limitation and implication. This makes the frame auditable and prevents unsupported claims from becoming accepted facts.

9. From Frame to Charter Without Premature Commitment

The problem frame informs the charter but does not replace initiation decisions. A charter can authorize a project to investigate, design, pilot or implement, depending on uncertainty and organizational governance.

When uncertainty about the problem is high, a discovery or diagnostic project may be appropriate. When the problem and preferred approach are well established, an implementation project may be justified. The decision should consider at least:

  • importance and urgency of the outcome;
  • strength of evidence;
  • stakeholder legitimacy and sponsorship;
  • feasibility and organizational capacity;
  • legal, ethical and safety constraints;
  • reversibility of the proposed commitment; and
  • consequences of delay or inaction.

A useful initiation sequence is:

  1. Observe the situation and collect diverse evidence.
  2. Identify stakeholders, affected groups and system boundaries.
  3. Generate multiple explanations and map dependencies.
  4. Test causes and assumptions against data.
  5. Define desired outcomes and safeguards.
  6. Explore options only after the need is sufficiently understood.
  7. Select the appropriate level of commitment and uncertainty management.
  8. Record the frame, evidence, assumptions, exclusions and decision rights in the charter.

The charter should state what is known, what is hypothesized and what remains to be learned. It should also identify decision gates. A gate may authorize further discovery, a pilot, a scaled implementation or termination. This protects the organization from escalating commitment merely because resources have already been spent.

10. Applied Case: Reducing Missed Outpatient Appointments

The following is an illustrative case based on common service-design conditions; it is not a report of a particular organization.

Background

A regional hospital reports that 18% of outpatient appointments are missed. Leaders initially propose a reminder application. Clinicians are concerned about unused capacity, while patients report difficulty accessing appointments and changing times.

Initial problem

“Patients need a mobile reminder app because they forget appointments.” This statement is solution-biased and assumes forgetfulness is the principal cause.

Analysis

The project team examines twelve months of scheduling records, interviews patients and staff, observes the booking journey and maps the value stream. It finds that the overall missed-appointment rate conceals variation: rates are higher for appointments requiring long travel and for patients whose appointment letters arrive late. Some appointments are difficult to reschedule, and the telephone line is busiest during working hours. Interviews reveal that patients sometimes miss appointments because transport arrangements fail, instructions are unclear or the appointment conflicts with a changed treatment plan. Reminder messages are inconsistently sent and do not always include a simple cancellation path.

The team identifies several hypotheses: communication failure, access barriers, scheduling inflexibility and transport constraints. It does not conclude that one factor is the root cause. It also discovers an ethical concern: relying only on smartphone notifications could disadvantage patients with limited connectivity or digital confidence.

Reframed problem statement

“Across outpatient services, 18% of scheduled appointments were not attended in the last twelve months. Missed appointments are associated with avoidable capacity loss, delayed care and additional administrative work, with disproportionate effects in some patient groups. The causes appear to include inconsistent information, limited rescheduling access and practical travel constraints. The project should identify and test ways to improve attendance and timely rescheduling without reducing access, penalizing patients unfairly or shifting burden to clinical staff.”

Opportunity statement

“There is an opportunity to make outpatient scheduling more reliable and accessible by improving information, rescheduling pathways and coordination with patient constraints, using communication channels appropriate to different users.”

Theory of change

If appointment information is timely and understandable, rescheduling is easy, and service channels reflect patient circumstances, then patients can make informed changes earlier. This should reduce avoidable missed appointments and release capacity. The assumptions are that patients receive the information, available appointments remain suitable, and staff can manage changed bookings. Measures should include attendance, timely cancellation, time to reschedule, patient effort, staff workload and equity by relevant patient characteristics.

Outcome

The immediate result of the framing work is not a selected application. It is a governed discovery-and-pilot charter with multiple options: improved letters and messages, a simpler telephone pathway, assisted digital access and changes to scheduling policy. The project can test combinations and abandon ineffective options.

Learning points

  1. The initial solution was attractive but causally narrow.
  2. Administrative data revealed scale, while interviews explained mechanisms.
  3. Averages concealed unequal effects.
  4. The opportunity was defined around reliable access, not technology ownership.
  5. Safeguards and measures were included before intervention selection.

11. Challenges, Ethics and Governance

Problem framing involves power. The sponsor who defines the problem may determine which groups receive attention and which outcomes count. Governance should therefore clarify who can approve the frame, whose evidence is considered legitimate and how disagreements are resolved.

Important ethical issues include informed participation, privacy, confidentiality, accessibility, non-discrimination and avoidance of harm. Data collected for diagnosis should have a lawful and transparent purpose. Sensitive attributes should not be used merely because they are available; their use should have a justified purpose, appropriate safeguards and careful interpretation. Automation or AI may assist with coding interview themes, identifying patterns or exploring scenarios, but generated interpretations require human validation. Training-data bias, proxy discrimination, opaque recommendations and inappropriate disclosure can distort both the problem definition and the eventual intervention.

Stakeholders should not be treated solely as data sources. They should understand how input will be used and, where feasible, be able to challenge interpretations. Vulnerable groups may require adapted methods, compensation for participation and independent advocacy.

Common limitations include incomplete data, survivorship bias, recall error, changing definitions, political pressure, limited time and the tendency of workshops to privilege confident participants. Triangulation reduces but does not eliminate these problems. A mature charter records uncertainty rather than disguising it with precise language.

12. Contemporary Practice and Professional Implications

Contemporary projects increasingly address complex, adaptive problems involving digital platforms, climate risk, public services, organizational transformation and interconnected supply chains. In such contexts, requirements evolve as the system responds to intervention. Discovery, experimentation, staged funding and benefits review are often more appropriate than a single irreversible commitment.

Project professionals need capabilities beyond scheduling and cost control. They must facilitate inquiry, interpret evidence, recognize bias, negotiate boundaries, communicate uncertainty and protect affected people. The project manager is not necessarily the subject-matter expert, but is responsible for ensuring that the framing process is credible, inclusive and connected to decision governance.

A practical quality review before charter approval should ask:

  • Is the problem expressed without a hidden solution?
  • Is there enough evidence to justify action or further discovery?
  • Are symptoms, causes and consequences distinguished?
  • Have alternative explanations been considered?
  • Are stakeholders and distributional effects visible?
  • Is the system boundary explicit?
  • Are desired outcomes and safeguards clear?
  • Are assumptions, dependencies and external factors recorded?
  • Can success be evaluated without claiming that every benefit is project-controlled?
  • Does the proposed commitment match the level of uncertainty?

Chapter Summary

Problem framing and opportunity definition establish the intellectual and ethical foundation of project initiation. A problem is a consequential gap between current and desired conditions, while an opportunity expresses a credible possibility for beneficial change. Both should be evidence-based, bounded, stakeholder-informed and free from premature solution commitment.

Systems thinking reveals relationships, feedback, boundaries and unintended consequences. Root-cause analysis develops and tests causal hypotheses rather than assigning simplistic blame. Design thinking contributes methods for understanding lived experience and generating human-centred questions. Value-stream analysis examines end-to-end flow, delay, rework and failure demand. Theory of change connects activities to outputs, outcomes and longer-term impact while exposing assumptions.

A strong charter distinguishes what is known from what is hypothesized, identifies affected groups and safeguards, defines desired outcomes and selects a level of commitment appropriate to uncertainty. Ethical governance requires attention to privacy, accessibility, equity, participation and the responsible use of data and AI. The central professional discipline is to preserve learning and choice long enough to understand the real situation before committing resources to a solution.

Key Terms

Problem framing: The disciplined definition of a current gap, its consequences, context and uncertainties.

Opportunity definition: The articulation of a credible possibility for valuable improvement.

Symptom: An observable sign or manifestation of a condition.

Root cause: A contributing condition or mechanism whose removal or modification could reduce recurrence.

Systems thinking: Analysis of relationships, feedback, boundaries and behaviour within an interconnected system.

Stakeholder: A person, group or institution affected by, able to influence or accountable for an intervention.

Solution bias: The tendency to define a problem around a preferred intervention.

Causal hypothesis: A provisional explanation linking a condition to a mechanism or contributing factor.

Five whys: An iterative questioning technique used to explore underlying contributors.

Fishbone diagram: A structured visual method for organizing possible causes.

Value stream: The end-to-end sequence of activities and flows that produces value for a recipient.

Lead time: Elapsed time from request or initiation to completion.

Processing time: Time during which work is actively performed.

Process-cycle efficiency: Processing time divided by lead time, expressed as a percentage.

Design thinking: An iterative approach emphasizing empathy, definition, ideation, prototyping and testing.

Theory of change: An explicit explanation of how activities are expected to produce outcomes and impact.

Assumption: A proposition treated as true for planning but requiring validation.

Benefit: A valued improvement resulting from change.

Boundary: The selected limit of a system or analytical inquiry.

Premature commitment: Irreversible or costly action taken before important uncertainty is resolved.

Review Questions

Short Answer Questions

  1. Distinguish a symptom from a problem and provide an example.
  2. Why should a system boundary be made explicit during problem framing?
  3. What is the purpose of a theory of change?
  4. Define lead time and processing time.
  5. Identify two ways in which a problem statement can embed solution bias.

Long Answer Questions

  1. Explain how systems thinking can alter the framing of an operational problem.
  2. Compare the contributions and limitations of root-cause analysis and design thinking.
  3. Describe how value-stream analysis can reveal local optimization and failure demand.
  4. Explain how evidence, assumptions and safeguards should be represented in a project charter.
  5. Discuss the ethical and governance issues involved in using stakeholder and operational data to define a project.

Analytical / Application Questions

  1. An organization proposes “implement an AI chatbot to reduce customer-service costs.” Construct an evidence-based problem statement and identify the discovery activities required before selecting a solution.
  2. A process has a lead time of 20 working days, of which 3 days are active processing. Calculate its process-cycle efficiency and interpret what the result does and does not imply.
  3. Using the outpatient appointment case, design a concise theory of change and identify three assumptions and three equity-related safeguards that should appear in the charter.

Multiple Choice Questions with Answers

Question 1

Which statement best distinguishes a problem from a solution?

A. A problem describes an outcome gap; a solution describes an intervention intended to address it.

B. A problem is always quantitative; a solution is always qualitative.

C. A problem is caused by people; a solution is caused by technology.

D. A problem belongs to the sponsor; a solution belongs to the project manager.

Correct Answer: A. A problem describes an outcome gap; a solution describes an intervention intended to address it.

Question 2

What is the principal value of making a system boundary explicit?

A. It proves that all causes have been identified.

B. It clarifies what is included in the inquiry and what is treated as external.

C. It eliminates the need for stakeholder consultation.

D. It guarantees that the project will remain within budget.

Correct Answer: B. It clarifies what is included in the inquiry and what is treated as external.

Question 3

Which activity is most consistent with avoiding solution bias?

A. Selecting a preferred technology before interviewing users.

B. Defining the problem in terms of a desired outcome and relevant constraints.

C. Writing requirements for a product before identifying the need.

D. Using the sponsor’s preferred intervention as the project baseline.

Correct Answer: B. Defining the problem in terms of a desired outcome and relevant constraints.

Question 4

In a theory of change, which item is most appropriately classified as an outcome rather than an output?

A. A completed training session

B. A published procedure

C. Reduced customer effort when completing a service request

D. A deployed software module

Correct Answer: C. Reduced customer effort when completing a service request

Question 5

Which statement about the five-whys method is correct?

A. Exactly five questions must always be asked.

B. It proves the first plausible cause is the root cause.

C. It is used to explore contributing mechanisms and should be supported by evidence.

D. It is suitable only for technical equipment failures.

Correct Answer: C. It is used to explore contributing mechanisms and should be supported by evidence.

Question 6

A process has 4 days of active processing and a lead time of 16 days. What is its process-cycle efficiency?

A. 4%

B. 20%

C. 25%

D. 80%

Correct Answer: C. 25%

Question 7

Which finding best illustrates the importance of disaggregating data?

A. The overall average is reported monthly.

B. The average improves while outcomes worsen for a particular user group.

C. The project has more than one stakeholder.

D. The process contains both manual and digital activities.

Correct Answer: B. The average improves while outcomes worsen for a particular user group.

Question 8

What is the main purpose of a value-stream analysis?

A. To select a project sponsor

B. To examine end-to-end flow, delay, rework and hand-offs involved in delivering value

C. To replace all qualitative research with numerical data

D. To guarantee that every activity adds customer value

Correct Answer: B. To examine end-to-end flow, delay, rework and hand-offs involved in delivering value

Question 9

Which is the strongest opportunity statement?

A. There is an opportunity to buy a mobile application immediately.

B. There is an opportunity to improve reliable and accessible appointment rescheduling while protecting equitable access.

C. There is an opportunity to automate every administrative task.

D. There is an opportunity to use the newest available technology.

Correct Answer: B. There is an opportunity to improve reliable and accessible appointment rescheduling while protecting equitable access.

Question 10

Why should a charter distinguish outputs from benefits?

A. Outputs are always more important than benefits.

B. Benefits cannot be measured.

C. A delivered product or service does not automatically prove that the intended improvement occurred.

D. Benefits are controlled entirely by the project team.

Correct Answer: C. A delivered product or service does not automatically prove that the intended improvement occurred.

Project Initiation & Chartering
Chapter 3 of 15