D · Delivery and ongoing operations

Problem decomposition

Breaking a vague goal into estimable, verifiable work.

Classification boundary

Include: Include breaking vague goals into problems, hypotheses, tasks, and verifiable milestones.

Choose a neighboring leaf when: Use C to judge whether a goal is worthwhile and project/PMO for cross-team planning and status control.

This capability may appear in standards across different stages. Explore stage expectations

26 questions

Choose a group based on the evidence you need. Groups follow existing question formats, not difficulty or mandatory prerequisites. Each batch has up to eight questions.

Judgment and options26

Compare goals, constraints, options, and trade-offs.

Questions 1–8

For three consecutive quarters, several teams underestimated integration and acceptance time. How would you use forecasts and actuals to determine whether the error comes from estimation, scope change, or scheduling, and improve the next forecast?
The business asks to “improve customer experience” without a clear pain point or deadline. How would you decompose it into verifiable problems, workstreams, and milestones? Follow-up: If a critical dependency slips by one cycle, how would you re-sequence the critical path, reset commitments, and reduce waiting?
The requester has prescribed a service rewrite, but incident data points to several possible causes. How would you return to problem definition and decide the validation order?
A business partner brings you a problem that is not clearly defined. What sources would you check, whom would you consult, and how would you separate confirmed facts from assumptions? How would you turn the findings into an actionable plan?
Different teams provide conflicting data and explanations for the same business problem, while the project is already planned for this quarter. How would you decide what to investigate first and what to defer?
Tell me about the most complex feature you owned. How do you break a vague business request down, step by step, into a requirements document without logical gaps, and how do you design fault tolerance and interaction for edge cases such as a lost connection or an abnormal account?
Halfway through a project, available capacity suddenly drops by half while the deadline stays fixed. How would you resequence work and reset expectations?
A customer asks for “a real-time dashboard,” but their examples suggest they only discover inventory errors later in the day. How would you guide the discussion?

Questions 9–16

You receive a request in an area you have never worked in. How do you break it down and give an estimate that can be checked later?
An identity-field change affects clients, APIs, the warehouse, and external partners, but the initial plan lists only server development and a front-end update. How would you decompose the dependency graph and find missing migration, rollback, and acceptance work?
A request says only “reduce user form time,” without explaining optional fields, consequences of bad data, or workflow differences. How would you decompose research, interaction design, technical validation, and outcome acceptance?
The goal is to improve purchase conversion, but traffic quality, page comprehension, payment options, and inventory can all affect it. How would you split the goal into diagnostic work, leading signals, and staged decisions?
The team plans to move order data to new storage, switching reads first and writes later; the plan includes development and launch but lacks data-difference checks and rollback criteria. How would you complete the migration breakdown?
Product considers a feature complete when it launches, Operations requires training and monitoring, and the customer expects successful migration from the old flow. How would you clarify outcomes, deliverables, and acceptance ownership?
A new system depends on unverified third-party capabilities, so the full implementation cannot be estimated accurately; leadership still needs a credible time range. How would you sequence technical probes, risk validation, and delivery stages?
The business wants fewer complaints, but issues arrive through apps, phone support, and partner handoffs; existing data cannot identify the same problem across channels. How would you decompose instrumentation, identity linkage, workflow changes, and outcome measurement?

Questions 17–24

A regulatory requirement has a fixed effective date, while Product wants to improve the experience; both depend on a backend change, but experience research is unfinished. How would you separate mandatory compliance scope from iterative experience work?
A delivery goal spans client, server, data, and operations, and the outcome depends on all parties being ready. How would you split the workstreams, identify the critical path, and plan integration checks?
A cross-team project receives new business feedback every week, invalidating parts of its task breakdown. How would you distinguish stable goals from changing assumptions and design work slices that can absorb change?
A new system must gradually replace a legacy one while both serve real users, with data and functionality switching in batches. How would you decompose the migration, validation points, and rollback conditions?
The team believes rework is excessive, but some count bug fixes, others requirement changes, and others code rewrites. How would you define the problem and set an improvement target?
Leadership asks for higher engineering productivity next quarter without defining it. Some propose increasing commits; others want fewer meetings. How would you establish an improvement direction?
Several product teams aim to reduce complaints, but categories, channels, and ownership differ. How would you define a shared measure and team actions?
The team lists release quality as a quarterly priority, but some focus on rollbacks, others on defects, and others on speed. How would you define a shared outcome?

Questions 25–26

Identity, frontend login, and support tools all shipped on time, yet new customers still cannot open an account. How would you define integration ownership and end-to-end acceptance?
A shared component already has many variants, and a new use case requests another special state. How would you weigh reuse, complexity, accessibility, and maintenance?

Back to the whole domain