Business Analytics Quiz: Project Scope And Success Criteria
10 questions · exam conditions
0:00
Project Scope And Success CriteriaQuestion 1 of 10

A service organization is developing a predictive model that prioritizes support tickets. Management wants the project to reduce customer waiting time, but agents are concerned that prioritization could cause more tickets to be reopened. Historical median resolution time is 20 hours, and the ticket-reopen rate is 8 percent.

Which set of success criteria is most appropriate for the project charter?

Achieve high feature importance stability and obtain favorable comments from most agents during the final model demonstration.
Reduce median resolution time by at least 15 percent while limiting the reopen-rate increase to no more than 2 percentage points during a defined pilot.
Achieve an area under the ROC curve of at least 0.80 and deploy the model to every support team by the target date.
Reduce mean resolution time to 17 hours while requiring the ticket-reopen rate to remain exactly at its historical value.
← Back to quizzes

Business Analytics Quiz

Business Analytics Quiz: Project Scope And Success Criteria

Practice Project Scope And Success Criteria in Business Analytics with focused quiz questions that help you check what you know, review explanations, and build confidence with test-style prompts.

What this quiz covers

This quiz focuses on Project Scope And Success Criteria, giving you a quick way to practice the rules, question types, and explanations that matter most for Business Analytics.

How to use this quiz

Try each quiz question before looking at the correct answer. Use the explanations to review missed ideas, then come back to similar questions until the pattern feels familiar.

All questions

Question 1

A service organization is developing a predictive model that prioritizes support tickets. Management wants the project to reduce customer waiting time, but agents are concerned that prioritization could cause more tickets to be reopened. Historical median resolution time is 20 hours, and the ticket-reopen rate is 8 percent.

Which set of success criteria is most appropriate for the project charter?

  1. Achieve high feature importance stability and obtain favorable comments from most agents during the final model demonstration.
  2. Reduce median resolution time by at least 15 percent while limiting the reopen-rate increase to no more than 2 percentage points during a defined pilot. (correct answer)
  3. Achieve an area under the ROC curve of at least 0.80 and deploy the model to every support team by the target date.
  4. Reduce mean resolution time to 17 hours while requiring the ticket-reopen rate to remain exactly at its historical value.
Explanation: When evaluating success criteria for a project charter, you need to ask three questions: Are the metrics tied directly to stated business goals? Are they measurable and specific? And do they account for all key stakeholder concerns — not just management's? In this scenario, management wants to reduce waiting time, and agents worry about ticket reopens. Strong success criteria must address both dimensions simultaneously, be grounded in baseline data, and be testable within a controlled scope. Option B does exactly this. It targets a 15% reduction in median resolution time — a concrete, calculable threshold relative to the 20-hour baseline (i.e., dropping to ≤17 hours), and it caps any reopen-rate increase at 2 percentage points above the current 8%, directly acknowledging the agents' concern. Anchoring this to a defined pilot makes it time-bound and realistic. This is your answer. Option A fails because "feature importance stability" is a technical modeling metric, not a business outcome, and "favorable comments" is subjective and unmeasurable — neither belongs in a charter's success criteria. Option C introduces AUC (a model performance metric) and a deployment deadline. These are development milestones, not business impact measures. A model can score AUC ≥ 0.80 and still worsen customer experience. Option D sets the reopen rate to exactly the historical value — this is an unrealistically rigid constraint. Real-world systems have natural variance, and "exactly" makes the criterion practically impossible to satisfy without gaming the measurement. Study tip: On business analytics exams, always distinguish between model performance metrics (AUC, feature importance) and business outcome metrics (resolution time, reopen rate) — project charters should emphasize the latter.

Question 2

A subscription company will use a churn model to select the highest-risk 10 percent of customers for a retention offer. The offer has a meaningful cost, and some customers would renew without receiving it. The sponsor states that the purpose of the project is to increase profitable renewals rather than merely produce accurate churn probabilities.

Which acceptance plan best aligns model delivery with the stated business objective?

  1. Require a minimum classification accuracy on historical data and approve deployment whenever accuracy exceeds the current rule-based model.
  2. Require calibrated probabilities across all customers and treat calibration alone as evidence that the retention campaign will be profitable.
  3. Require strong recall among predicted churners and send the offer to every customer classified as likely to cancel.
  4. Set an offline model-performance threshold, then run a randomized targeted pilot and require positive incremental profit within a defined evaluation period. (correct answer)
Explanation: When a business problem involves both model outputs and downstream economic consequences, your acceptance criteria must close the loop between prediction quality and actual business value — not just reward statistical accuracy in isolation. Option D is the right approach because it bridges the gap between model performance and real-world profitability. An offline threshold screens out clearly poor models, but the randomized pilot is what actually tests whether targeting the top-10% churners with a costly offer generates incremental profit — accounting for customers who would have renewed anyway and the cost of the offer itself. Requiring positive incremental profit within a defined window directly matches the sponsor's stated goal of increasing profitable renewals. Option A is tempting but flawed: overall classification accuracy on historical data says nothing about whether intervening on predicted churners is economically worthwhile. A model can be highly accurate yet still waste money on customers who would self-renew. Option B mistakes calibration for business impact. Well-calibrated probabilities are valuable, but they only mean the model's predicted probabilities are reliable — they don't guarantee that acting on those probabilities generates profit. Option C optimizes for recall (catching as many churners as possible), which sounds intuitive but ignores precision. Sending offers to every likely canceler inflates costs and reaches many customers who weren't actually at risk, eroding profitability. Study tip: On questions about model deployment criteria, always ask: does this acceptance plan measure what the business actually cares about? When the sponsor mentions profit or cost, pure statistical metrics (accuracy, calibration, recall) are almost never the complete answer — a pilot measuring incremental business outcomes usually is.

Question 3

A distributor requests a prescriptive analytics tool to recommend weekly shipments from warehouses to stores. The initial statement says only that the tool should provide the 'best allocation.' Operations prioritizes on-time delivery, finance prioritizes shipping cost, and warehouse managers emphasize capacity limits.

Which revision most effectively makes the project's scope and success criteria testable?

  1. Minimize total shipping cost while meeting a defined on-time-delivery threshold and all warehouse, store, and transportation capacity constraints. (correct answer)
  2. Maximize on-time delivery and minimize shipping cost simultaneously, allowing the optimization software to determine the appropriate trade-off.
  3. Generate allocations that stakeholders consider reasonable after reviewing several representative weeks of historical shipment data.
  4. Match historical allocations as closely as possible while permitting managers to override any recommendation they find impractical.
Explanation: When evaluating project scope statements in business analytics, ask yourself: Can I measure whether this goal was achieved? A testable success criterion must be specific, quantifiable, and unambiguous — leaving no room for subjective interpretation after the fact. Answer A does exactly this. It names a clear objective (minimize total shipping cost), sets a defined threshold for a competing priority (on-time delivery rate), and explicitly acknowledges constraints (warehouse capacity, store demand, transportation limits). Every element can be measured: cost is a number, on-time delivery is a percentage, and capacity limits are hard bounds. A decision-maker could objectively verify whether the tool succeeded or failed. Answer B sounds rigorous but contains a critical flaw: it delegates the trade-off decision to "the optimization software." This means no human stakeholder has agreed on how much cost is acceptable to gain how much delivery performance. Without a defined trade-off, you cannot evaluate whether the output is actually optimal for the business — it's still subjective. Answer C relies entirely on stakeholder opinion ("consider reasonable"), which varies by person, mood, and context. It provides no standard that could be consistently applied across weeks or analysts, making it essentially untestable. Answer D anchors success to historical behavior, which defeats the purpose of a prescriptive tool. If your benchmark is "match what we already did," you're measuring conformity to past decisions, not optimizing outcomes — and manager overrides make success even harder to define consistently. Your study tip: whenever a scope statement uses words like "reasonable," "appropriate," or "best," flag it immediately. Testable criteria require numbers, thresholds, or explicit constraints — not adjectives.

Question 4

A grocery chain's project charter states that a replenishment dashboard will be successful if it 'reduces stockouts by 20 percent.' One manager interprets a stockout as any store with an unavailable item, while another counts each store-item-day without inventory. The chain also opens new stores during the planned evaluation period.

Which clarification is most important before the team finalizes the project timeline and acceptance test?

  1. Specify the stockout unit, denominator, baseline period, evaluation period, eligible stores and items, and treatment of newly opened stores. (correct answer)
  2. Select the dashboard colors, refresh frequency, and default filters so all managers view stockout information consistently.
  3. Require every region to reduce stockouts by exactly 20 percent, regardless of baseline volume or local assortment differences.
  4. Use the interpretation preferred by the executive sponsor and allow analysts to select the baseline after observing post-launch results.
Explanation: When a project charter includes a quantitative success metric like "reduce stockouts by 20 percent," that number is meaningless until every term in it is precisely defined. This question tests your understanding of metric operationalization — the process of turning a vague goal into an unambiguous, measurable target before work begins. Answer A is correct because it addresses every component needed to make the 20 percent target testable: what counts as one stockout (unit), what you divide by (denominator), where you start measuring (baseline), when you evaluate (evaluation period), and which stores and items are in scope — including the complication of newly opened stores, which have no baseline and could distort the measurement. Without these definitions locked in advance, two analysts could each claim success or failure using the same raw data. Answer B focuses on UI decisions — dashboard colors, refresh rate, and filters. These affect usability but have nothing to do with whether the success criterion is measurable or fair. It's a real project task, just not the most important clarification before finalizing the timeline and acceptance test. Answer C imposes a rigid, uniform 20 percent target on every region regardless of context. This ignores that regions with near-zero baseline stockouts face a statistically impossible target, while high-volume regions face a much easier one — it's operationally unfair and analytically unsound. Answer D is the most dangerous distractor: allowing analysts to choose the baseline after seeing post-launch results is a form of p-hacking that guarantees the metric can be manipulated to show whatever outcome is desired. Study tip: On business analytics questions, whenever a success metric appears, immediately ask yourself: unit, denominator, baseline, scope. If any of those are undefined, that's the problem to solve first.

Question 5

An analytics team estimates the following task durations. Data-access approval takes two weeks. Data preparation then takes three weeks. Requirements confirmation takes one week and may occur while approval and preparation are underway. Modeling requires both prepared data and confirmed requirements and takes four weeks. After modeling, dashboard construction takes two weeks. In parallel with modeling, a two-week data-interface task may begin once data preparation is complete. User acceptance testing takes one week and cannot begin until both the dashboard and interface are complete.

Assuming work starts at the beginning of week 1 and no task is shortened, what is the earliest end-of-week delivery date?

  1. End of week 10, because requirements confirmation and interface development are both parallel tasks that eliminate the need for dashboard construction and testing.
  2. End of week 11, because dashboard construction finishes at week 11 and user acceptance testing can run concurrently with the final dashboard work.
  3. End of week 12, because the critical path runs through approval, preparation, modeling, dashboard construction, and user acceptance testing. (correct answer)
  4. End of week 13, because user acceptance testing must separately follow the interface and the dashboard as two sequential one-week stages.
Explanation: When a project has parallel and sequential tasks, your first move is to identify the critical path — the longest chain of dependent tasks from start to finish. Every other path is constrained by it, and no amount of parallelism elsewhere can shorten it. Map out each path here. Data-access approval (2 weeks) → Data preparation (3 weeks) → Modeling (4 weeks) → Dashboard construction (2 weeks) → User acceptance testing (1 week) totals 12 weeks. Requirements confirmation (1 week) runs concurrently during approval/preparation, so it finishes well before Modeling begins — it's not on the critical path. The interface task (2 weeks) begins after preparation (end of week 5) and finishes by end of week 7, also before UAT's bottleneck. The critical path is approval → preparation → modeling → dashboard → UAT, landing at the end of week 12, making C correct. Choice A is wrong on two counts: it claims parallel tasks eliminate dashboard construction and testing entirely, which misreads the passage — both are explicitly required, sequential steps. Choice B incorrectly suggests UAT can overlap with dashboard construction; the passage states UAT cannot begin until both the dashboard and interface are complete, so they must be fully sequential. Choice D invents a two-stage sequential UAT process (one week following the interface, then one week following the dashboard) that doesn't exist in the passage — UAT is a single one-week task that begins only after both are done. Study tip: On critical-path questions, always draw a dependency diagram and calculate the finish time of every path — the longest one wins, regardless of how many shortcuts appear elsewhere.

Question 6

A marketing team requests a model that estimates three-year year-over-year campaign lift by customer segment. During discovery, analysts learn that campaign identifiers are reliable only from January 2024 onward, exposure records are missing for several channels, and no defensible method exists to reconstruct earlier assignments. The sponsor still wants a result in four weeks.

Which project-planning response is most appropriate?

  1. Retain the original success criterion and estimate missing campaign assignments from purchase behavior so the three-year analysis can proceed.
  2. Begin model development immediately and evaluate data limitations only if the resulting year-over-year estimates appear inconsistent.
  3. Add a data-feasibility gate, document the unsupported analyses, and seek approval for a narrower period or a descriptive alternative. (correct answer)
  4. Use all available sales records without campaign identifiers because a larger dataset will compensate for incomplete exposure information.
Explanation: When a business analytics project runs into fundamental data-quality problems before a single model is built, the right move is governance before execution — you protect the project's credibility by surfacing limitations early and aligning stakeholders on what the data can actually support. Here, campaign IDs are only reliable from January 2024, exposure records have gaps across channels, and no reconstruction method is defensible. That's not a nuisance gap — it invalidates the core three-year, year-over-year measurement. Answer C is correct because a data-feasibility gate forces the team to formally document what cannot be supported, then seek sponsor approval to either narrow the scope (e.g., analyze only the post-January 2024 period) or pivot to a descriptive alternative. This protects the team from delivering a result that looks precise but is analytically indefensible. A is dangerous because imputing missing campaign assignments from purchase behavior introduces circular reasoning — you'd be using the outcome variable to infer the treatment variable, then measuring that treatment's effect on the same outcome. The analysis would confirm itself by construction. B is a textbook example of "build first, ask questions later," which is exactly how flawed models ship to production; data limitations should gate the project, not serve as a post-hoc check. D mistakes volume for validity — a larger dataset with structurally missing exposure information doesn't reduce bias, it just scales it. A good study tip: whenever a question describes irreparable data gaps before modeling begins, the correct answer almost always involves a formal scoping or governance step, not a workaround that assumes the problem away.

Question 7

A bank approves a six-week project to analyze loan-application abandonment for one digital channel and two customer segments. After data preparation is complete, the sponsor asks the team to include branch applications, four additional segments, and a prescriptive recommendation engine. The sponsor says the delivery date cannot change.

What should the project manager do first?

  1. Assign the new work immediately and reduce validation activities so the expanded deliverable can remain within the six-week schedule.
  2. Estimate the request's effects on data access, effort, risk, quality, and schedule, then present scope-and-timeline options for approval. (correct answer)
  3. Add branch applications and the additional segments, but defer documenting the recommendation engine until the final project report.
  4. Continue the original work without discussing the request because the approved charter cannot be modified after data preparation begins.
Explanation: When a project scope expands mid-execution, your instinct should be to analyze before acting. This question tests whether you understand the formal scope-change process — a core principle in business analytics project management. Whenever a sponsor requests additions beyond the approved charter, the professional response is structured impact assessment, not unilateral action. Option B is correct because it follows exactly this discipline. Before agreeing to anything, you must quantify how the expanded request affects data access requirements, team effort, risk exposure, deliverable quality, and the schedule. Only then can you present the sponsor with realistic options — perhaps a phased delivery, an extended timeline, or a reduced scope — and get formal approval. This protects both the team and the sponsor from unrealistic commitments. Option A is dangerous because cutting validation activities to absorb extra scope trades delivery speed for quality. In loan-application analysis, flawed data validation can produce misleading insights with significant financial consequences — this is never an acceptable shortcut. Option C represents partial scope creep: adding branch applications and segments without documenting the recommendation engine doesn't resolve the scope problem — it just obscures part of it. Undocumented work is uncontrolled work. Option D goes too far in the opposite direction. Refusing to even discuss a sponsor's request because the charter was previously approved is rigid and counterproductive. Charters can be amended; what matters is that changes go through a proper approval process. The key pattern to remember: scope change requests always require impact assessment first, then escalation for approval — never silent rejection or immediate execution.

Question 8

Before an online pricing experiment, stakeholders agree that the new page will be adopted only if conversion improves by at least 10 percent relative to an 8 percent baseline. The two-week result must also be statistically significant, and the refund rate may not increase by more than 0.5 percentage points. At the end of the test, control conversion is 8 percent and treatment conversion is 9 percent. The confidence interval for the treatment-minus-control conversion difference is 0.4 to 1.6 percentage points. The treatment refund rate is 0.7 percentage points higher than control.

Under the predefined success criteria, what is the correct decision?

  1. Adopt the treatment because its conversion increase is statistically significant and exceeds the required relative improvement.
  2. Adopt the treatment because the refund-rate change is small compared with the one-percentage-point conversion increase.
  3. Extend the test because the conversion result meets the threshold, but statistical significance has not yet been established.
  4. Do not adopt the treatment because it passes the conversion criteria but violates the predefined refund-rate guardrail. (correct answer)
Explanation: When running A/B tests in business settings, it's critical to evaluate all predefined success criteria — not just the headline metric. Experiments typically include both a primary success metric and guardrail metrics designed to prevent harm. Failing any guardrail is grounds for rejection, regardless of how well the primary metric performs. Here, the three criteria established before the test were: (1) conversion must improve by at least 10% relative to the 8% baseline — meaning the treatment must reach at least 8.8%; (2) the result must be statistically significant; and (3) the refund rate may not rise by more than 0.5 percentage points. Now check each against the results. Treatment conversion is 9%, which clears the 8.8% relative threshold. The confidence interval (0.4 to 1.6 pp) excludes zero, confirming statistical significance. So far, so good — but the refund rate increased by 0.7 percentage points, which exceeds the 0.5 pp guardrail. That single violation disqualifies the treatment. D is correct. Answer A is tempting but wrong — it ignores the refund-rate guardrail entirely, cherry-picking only the metrics that look favorable. Answer B commits the same error and adds a flawed rationalization: you cannot trade off a guardrail violation against a conversion gain when guardrails are predefined as hard limits. Answer C is factually incorrect; statistical significance is established because the confidence interval doesn't include zero. Study tip: On exam questions involving A/B test decisions, always check every criterion, not just the primary metric. Guardrail violations are automatic disqualifiers — treat them like knockout rules, not factors to weigh against benefits.

Question 9

A manufacturer is building a pricing-recommendation tool. The sponsor wants delivery before the annual contracting cycle, but realized margin effects will not be observable until contracts are signed several months later. Sales leaders also need time to learn the tool and may choose not to use its recommendations.

Which project charter structure best addresses this timing mismatch?

  1. Define success only as on-time software deployment because business effects occurring after delivery are outside the analytics project's responsibility.
  2. Delay all acceptance decisions until annual margin is available, even if data quality, usability, and adoption problems are evident earlier.
  3. Use staged criteria covering technical acceptance and user readiness at delivery, adoption during rollout, and margin impact in a later evaluation window. (correct answer)
  4. Treat recommendation acceptance by sales representatives as final proof that the tool increased realized margin for the contracting cycle.
Explanation: When a project delivers a tool whose business impact unfolds long after go-live, a single success criterion measured at one point in time will miss critical failure modes. The right framework is staged acceptance criteria — checkpoints aligned to what can actually be measured at each phase of the project lifecycle. That's exactly what C captures. At delivery, you can evaluate whether the software meets technical specs and whether users are prepared to adopt it. Weeks or months into rollout, you can measure whether sales representatives are actually using the recommendations. Finally, once contracts are signed, you can assess realized margin impact. Each stage is observable, actionable, and tied to a realistic timeline — making C the only option that honestly addresses the mismatch between delivery date and business outcome. A is tempting but dangerously narrow. Declaring success at deployment ignores everything the organization actually cares about — margin improvement. Limiting accountability to on-time delivery lets adoption and outcome failures go unexamined and unaddressed. B overcorrects in the opposite direction. Waiting until annual margin data arrives before making any acceptance decision means ignoring early, fixable problems like data quality issues or poor UI design. You'd miss the window to course-correct before the contracting cycle even begins. D conflates two different things: recommendation acceptance (a sales rep clicking "approve") and realized margin impact (actual profitability). A rep can accept a recommendation and still negotiate it away, or the recommendation could be wrong. Acceptance is an input metric, not an outcome. Study tip: On charter and governance questions, watch for options that either shrink accountability too early or delay it too long — staged criteria are almost always the more sophisticated, correct answer.

Question 10

A retailer commissions an eight-week descriptive analytics project to help regional managers identify stores with declining weekly sales. The approved deliverable is a dashboard using existing point-of-sale data for domestic stores. During week three, the marketing director requests customer-level demand forecasts for domestic and international stores. Customer identifiers and international data have not been approved for use.

Which response best preserves a well-defined project scope while addressing the marketing director's request?

  1. Add the forecasts to the current project because they support the general goal of improving sales decisions, but retain the original deadline.
  2. Reject the request permanently because additions proposed after project kickoff should never be considered within an analytics program.
  3. Complete the approved domestic dashboard and evaluate the forecasting request through a separate change assessment covering data, effort, risk, and timing. (correct answer)
  4. Replace the domestic dashboard with international forecasts because predictive analytics will generally provide more value than descriptive analytics.
Explanation: When you see a question about mid-project requests in analytics, think about scope management: the discipline of protecting a project's defined boundaries while still handling new needs responsibly. A well-scoped project has agreed-upon deliverables, data sources, timelines, and stakeholders — and changes to any of those deserve structured evaluation, not reflexive acceptance or rejection. The marketing director's request introduces two unapproved elements: customer-level identifiers and international data. Simply absorbing that request would expand data access, effort, and risk without any formal review. Option C is correct because it threads the needle perfectly — the team fulfills the original commitment (the domestic dashboard) while routing the new request through a proper change assessment covering data governance, effort estimation, risk, and scheduling. This preserves trust with both the original sponsor and the new requester. Option A is tempting because "improving sales decisions" sounds aligned with the project's spirit, but vague goal alignment is not a substitute for formal scope control. Piling new work onto the same deadline while ignoring unapproved data is how projects fail. Option B goes too far in the opposite direction — a blanket policy of never considering post-kickoff requests is inflexible and ignores that business needs legitimately evolve; the issue is how you handle them, not whether you ever do. Option D is a red flag: it abandons a nearly-complete approved deliverable and assumes predictive analytics is categorically superior to descriptive analytics, which is a false hierarchy — the right tool depends on the business question. Your takeaway: on scope questions, the correct answer almost always honors the current commitment AND creates a structured path for the new request — never one without the other.