HKSM

A structured technique to examine and break down a proposed product or deliverable to clarify what it must do, how it will be used, and the characteristics that satisfy stakeholder needs. It informs scope, acceptance criteria, and design decisions across predictive and adaptive approaches.

Definition

Refer to the definition above for a concise summary of this technique.

Key Points

• Decomposes the product into features, functions, interfaces, and quality attributes to remove ambiguity.
• Used iteratively to refine scope, whether you are managing a predictive plan or an agile backlog.
• Common tools include feature breakdowns, functional analysis, system modeling, prototyping, and value engineering.
• Produces testable acceptance criteria and clear product boundaries that guide design and verification.
• Engages diverse stakeholders to surface needs, constraints, and trade-offs early.
• Feeds the scope baseline, WBS, and/or product backlog with well-formed items.

Purpose of Analysis

• Clarify what the product must deliver and why it matters to stakeholders.
• Translate needs into measurable characteristics and acceptance criteria.
• Explore design options to optimize value, cost, risk, and feasibility.
• Establish a shared understanding that supports planning, estimation, and validation.

Method Steps

• Define objectives: who the users are, key outcomes, and constraints.
• Gather inputs: vision, needs, existing requirements, policies, and assumptions.
• Break down the product into features, functions, components, and interfaces.
• Model behavior and structure using simple diagrams, story maps, or prototypes.
• Assess options and value; consider cost, risk, compliance, and technical feasibility.
• Specify acceptance criteria and quality attributes for each feature or component.
• Review with stakeholders and update the scope baseline or backlog items.

Inputs Needed

• Business goals, product vision, and strategy.
• Stakeholder needs, user research, and customer feedback.
• Documented requirements or backlog items, assumptions, and constraints.
• Standards, policies, and regulatory or compliance requirements.
• Technical architecture concepts, prototypes, and system context.
• Historical data, benchmarks, and lessons learned.

Outputs Produced

• Clear product description with features, boundaries, and interfaces.
• Feature list, user stories, use cases, or functional specifications.
• Measurable acceptance criteria and defined quality attributes.
• Simple models or diagrams (e.g., context, process flow, wireframes).
• Updates to the scope baseline, WBS/WBS dictionary, or product backlog.
• Documented decisions, trade-offs, risks, and open questions.

Interpretation Tips

• Differentiate product scope (what is delivered) from project scope (the work to deliver it).
• Link each characteristic to a stakeholder value or need to avoid gold plating.
• Keep artifacts lightweight; detail only what is necessary for decisions and testing.
• Maintain traceability from needs to features to acceptance tests.
• Revisit and refine analysis as new information emerges.

Example

A team is delivering a new customer onboarding service. They decompose the service into identity capture, verification, approval, and activation features; map user journeys; and sketch a simple process flow.

• They define acceptance criteria such as verification turnaround time and data accuracy thresholds.
• They assess options (manual vs. automated checks) and document trade-offs in cost and risk.
• They update the backlog with refined user stories and link each to test cases.

Pitfalls

• Jumping to a single solution too early and missing better options.
• Over-analysis that delays delivery without adding proportional value.
• Ignoring nonfunctional requirements such as performance, security, and usability.
• Excluding key stakeholders, leading to rework and scope disputes.
• Writing vague, untestable acceptance criteria.
• Failing to update analysis when assumptions or constraints change.

PMP Example Question

During scope definition, the team wants to clarify features, functions, quality attributes, and acceptance criteria of the deliverable. Which technique should the project manager recommend?

1. Product analysis
2. Root cause analysis
3. Monte Carlo simulation
4. Control charts

Correct Answer: A — Product analysis

Explanation: Product analysis decomposes and clarifies the product’s characteristics and acceptance criteria. The other options are used for problem analysis, risk simulation, or process control, not scope clarification.