4.5.1: Scenario 1 – Reporting Module Ambiguity
- Page ID
- 54806
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\( \newcommand{\dsum}{\displaystyle\sum\limits} \)
\( \newcommand{\dint}{\displaystyle\int\limits} \)
\( \newcommand{\dlim}{\displaystyle\lim\limits} \)
\( \newcommand{\id}{\mathrm{id}}\) \( \newcommand{\Span}{\mathrm{span}}\)
( \newcommand{\kernel}{\mathrm{null}\,}\) \( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\) \( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\) \( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\id}{\mathrm{id}}\)
\( \newcommand{\Span}{\mathrm{span}}\)
\( \newcommand{\kernel}{\mathrm{null}\,}\)
\( \newcommand{\range}{\mathrm{range}\,}\)
\( \newcommand{\RealPart}{\mathrm{Re}}\)
\( \newcommand{\ImaginaryPart}{\mathrm{Im}}\)
\( \newcommand{\Argument}{\mathrm{Arg}}\)
\( \newcommand{\norm}[1]{\| #1 \|}\)
\( \newcommand{\inner}[2]{\langle #1, #2 \rangle}\)
\( \newcommand{\Span}{\mathrm{span}}\) \( \newcommand{\AA}{\unicode[.8,0]{x212B}}\)
\( \newcommand{\vectorA}[1]{\vec{#1}} % arrow\)
\( \newcommand{\vectorAt}[1]{\vec{\text{#1}}} % arrow\)
\( \newcommand{\vectorB}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\( \newcommand{\vectorC}[1]{\textbf{#1}} \)
\( \newcommand{\vectorD}[1]{\overrightarrow{#1}} \)
\( \newcommand{\vectorDt}[1]{\overrightarrow{\text{#1}}} \)
\( \newcommand{\vectE}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash{\mathbf {#1}}}} \)
\( \newcommand{\vecs}[1]{\overset { \scriptstyle \rightharpoonup} {\mathbf{#1}} } \)
\(\newcommand{\longvect}{\overrightarrow}\)
\( \newcommand{\vecd}[1]{\overset{-\!-\!\rightharpoonup}{\vphantom{a}\smash {#1}}} \)
\(\newcommand{\avec}{\mathbf a}\) \(\newcommand{\bvec}{\mathbf b}\) \(\newcommand{\cvec}{\mathbf c}\) \(\newcommand{\dvec}{\mathbf d}\) \(\newcommand{\dtil}{\widetilde{\mathbf d}}\) \(\newcommand{\evec}{\mathbf e}\) \(\newcommand{\fvec}{\mathbf f}\) \(\newcommand{\nvec}{\mathbf n}\) \(\newcommand{\pvec}{\mathbf p}\) \(\newcommand{\qvec}{\mathbf q}\) \(\newcommand{\svec}{\mathbf s}\) \(\newcommand{\tvec}{\mathbf t}\) \(\newcommand{\uvec}{\mathbf u}\) \(\newcommand{\vvec}{\mathbf v}\) \(\newcommand{\wvec}{\mathbf w}\) \(\newcommand{\xvec}{\mathbf x}\) \(\newcommand{\yvec}{\mathbf y}\) \(\newcommand{\zvec}{\mathbf z}\) \(\newcommand{\rvec}{\mathbf r}\) \(\newcommand{\mvec}{\mathbf m}\) \(\newcommand{\zerovec}{\mathbf 0}\) \(\newcommand{\onevec}{\mathbf 1}\) \(\newcommand{\real}{\mathbb R}\) \(\newcommand{\twovec}[2]{\left[\begin{array}{r}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\ctwovec}[2]{\left[\begin{array}{c}#1 \\ #2 \end{array}\right]}\) \(\newcommand{\threevec}[3]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\cthreevec}[3]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \end{array}\right]}\) \(\newcommand{\fourvec}[4]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\cfourvec}[4]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \end{array}\right]}\) \(\newcommand{\fivevec}[5]{\left[\begin{array}{r}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\cfivevec}[5]{\left[\begin{array}{c}#1 \\ #2 \\ #3 \\ #4 \\ #5 \\ \end{array}\right]}\) \(\newcommand{\mattwo}[4]{\left[\begin{array}{rr}#1 \amp #2 \\ #3 \amp #4 \\ \end{array}\right]}\) \(\newcommand{\laspan}[1]{\text{Span}\{#1\}}\) \(\newcommand{\bcal}{\cal B}\) \(\newcommand{\ccal}{\cal C}\) \(\newcommand{\scal}{\cal S}\) \(\newcommand{\wcal}{\cal W}\) \(\newcommand{\ecal}{\cal E}\) \(\newcommand{\coords}[2]{\left\{#1\right\}_{#2}}\) \(\newcommand{\gray}[1]{\color{gray}{#1}}\) \(\newcommand{\lgray}[1]{\color{lightgray}{#1}}\) \(\newcommand{\rank}{\operatorname{rank}}\) \(\newcommand{\row}{\text{Row}}\) \(\newcommand{\col}{\text{Col}}\) \(\renewcommand{\row}{\text{Row}}\) \(\newcommand{\nul}{\text{Nul}}\) \(\newcommand{\var}{\text{Var}}\) \(\newcommand{\corr}{\text{corr}}\) \(\newcommand{\len}[1]{\left|#1\right|}\) \(\newcommand{\bbar}{\overline{\bvec}}\) \(\newcommand{\bhat}{\widehat{\bvec}}\) \(\newcommand{\bperp}{\bvec^\perp}\) \(\newcommand{\xhat}{\widehat{\xvec}}\) \(\newcommand{\vhat}{\widehat{\vvec}}\) \(\newcommand{\uhat}{\widehat{\uvec}}\) \(\newcommand{\what}{\widehat{\wvec}}\) \(\newcommand{\Sighat}{\widehat{\Sigma}}\) \(\newcommand{\lt}{<}\) \(\newcommand{\gt}{>}\) \(\newcommand{\amp}{&}\) \(\definecolor{fillinmathshade}{gray}{0.9}\)Project Reckon Practicum
Scenario 1 – Reporting Module Ambiguity
PART I — SCENARIO CONTEXT
Current Phase
Project Reckon is in Iteration 2 of development.
Architecture design has been delivered and approved at a high level. Development and QA are underway.
This is the first structured review cycle since construction began.
Velocity and burn rate appear mostly stable.
However, a potential scope and requirement issue has emerged.
PART II — EMAIL FROM JULIE RAMA (ZynoxDev PM)
Subject: Iteration 2 Update – Reporting Manager Clarification Required
Hi,
We are nearing completion of Iteration 2 and preparing internal QA validation for the Reporting Manager module.
I wanted to flag a potential clarification issue before we proceed further.
In reviewing the URD, our architecture team interpreted the reporting requirement as providing project-level summary reports, including export capability at the project aggregation level.
However, during last week’s demo, one of your internal stakeholders asked whether users would be able to export user-level granular action item data.
The URD does not explicitly specify export granularity.
At present:
-
Iteration velocity is at 93% of baseline.
-
Defect count: 11 open (1 high severity, 3 medium, 7 low).
-
Burn rate: +2.8% over planned staffing curve.
-
Schedule remains within tolerance.
If granular reporting is required, this will require additional development effort and may affect RC1 timeline.
Please advise whether this constitutes a scope modification or whether the original interpretation should stand.
Best,
Julie
PART III — ATTACHMENTS PROVIDED TO STUDENTS
Attachment A – Velocity Snapshot
| Metric | Baseline | Actual | Variance |
|---|---|---|---|
| Story Points Planned | 45 | 42 | -3 |
| Completion Rate | 100% | 93% | -7% |
| Carryover Stories | 0 | 2 | — |
Interpretation: Slight underperformance but within tolerance.
Attachment B – Defect Summary
| Severity | Count | Status |
|---|---|---|
| High | 1 | Open |
| Medium | 3 | In Progress |
| Low | 7 | Deferred |
Trend: Stable compared to Iteration 1.
Attachment C – Budget Snapshot
| Category | Planned | Actual | Variance |
|---|---|---|---|
| Dev Hours | 320 | 328 | +2.5% |
| QA Hours | 110 | 118 | +7.2% |
| Total Burn | Within ±5% tolerance |
PART IV — STUDENT WORKBOOK VERSION
Students receive the following prompt:
Scenario 1 – Scope Clarification and Change Control
You are the Project Manager at C-Bay overseeing outsourced development of Project Reckon.
ZynoxDev has requested clarification regarding the granularity of export functionality within the Reporting Manager module.
Your responsibilities:
-
Determine whether this is:
-
Requirement ambiguity
-
Vendor misinterpretation
-
Scope expansion
-
Minor clarification within scope
-
-
Evaluate:
-
Schedule impact
-
Budget impact
-
Change control necessity
-
Risk exposure
-
-
Provide a formal response to Julie Rama.
Required Submission
Submit a structured memorandum including:
1️⃣ Executive Position
-
Is current performance acceptable?
-
Is this a scope change?
-
Is corrective action required?
2️⃣ Scope Determination
-
Is granular reporting within approved scope?
-
If unclear, how should ambiguity be resolved?
-
Is formal change control required?
3️⃣ Schedule Assessment
-
Is 93% velocity acceptable?
-
Does adding granular reporting jeopardize RC1?
4️⃣ Budget Position
-
Does +2.8% burn indicate structural drift?
-
Should additional development for granularity be approved without cost review?
5️⃣ Risk Assessment
Classify risk under:
-
Scope risk
-
Schedule risk
-
Financial risk
-
Quality risk
Include likelihood and impact.
6️⃣ Formal Directive to ZynoxDev
State explicitly:
-
Approve current interpretation
-
Require granular export in RC1
-
Defer granular export to later release
-
Initiate formal change control
-
Request impact analysis before decision
Your directive must be precise.
PART V — TEACHING OBJECTIVES FOR SCENARIO 1
This scenario teaches:
-
Early scope discipline
-
Requirement ambiguity management
-
Change control trigger evaluation
-
Avoiding informal feature expansion
-
Maintaining partnership tone while asserting control
It is not a crisis scenario.
It is a calibration scenario.
PART VI — INSTRUCTOR NOTES
Correct instincts to look for:
-
Students should not casually approve expanded granularity.
-
They should request formal impact analysis.
-
They should clarify URD language.
-
They should avoid reacting emotionally.
-
They should maintain RC1 stability.
-
They should protect baseline.
Common mistakes:
-
Approving additional work informally.
-
Ignoring scope issue.
-
Overreacting to minor velocity variance.
-
Failing to assess budget implication.
PART VII — GRADING WEIGHT FOR SCENARIO 1
| Section | Points |
|---|---|
| Executive Clarity | 15 |
| Scope Discipline | 20 |
| Budget Awareness | 15 |
| Risk Assessment | 15 |
| Directive Precision | 20 |
| Professional Tone | 15 |
| Total | 100 |
Optional Instructor Escalation
If students:
Approve granular reporting without change control →
Next scenario includes burn spike and scope creep cascade.
Ignore ambiguity →
Next scenario includes rework dispute.
Overreact aggressively →
Next scenario includes vendor defensiveness.