Beginner Labs Answer Key — Labs 01–06¶
Instructor material — and not secret
Published in a public repository. Treat it as a self-study reference, not a secured key.
Labs 01–06 ask for judgement-based artefacts, so most of what follows is a model answer with the reasoning that must be present, not a single correct answer. Where a lab has a definite right answer, it is stated as such.
Lab 01 — Writing a Project Charter¶
No single correct charter exists. Mark against the self-check criteria, and specifically look for:
| Element | What must be present |
|---|---|
| Purpose | Tied to a stakeholder need, not to the product |
| Success criteria | Observable by a third party — for example "a society can publish an event without staff help" |
| In scope | Specific and prioritised, not a wish list |
| Out of scope | At least three plausible exclusions (mobile app, payments, event analytics, calendar integration) with a reason each |
| Constraints vs assumptions | Clearly separated; the IT security review queue is an assumption, the orientation-week date is a constraint |
| Governance | Sponsor, charter approver, and what the project manager may decide alone |
| Risks and stakeholders | Three to five risks and the main groups, at high level only |
Model success criteria (any three of these ideas):
- A student society publishes an event listing without staff assistance.
- An event listing appears to students within one working day of publication.
- A staff moderator can remove a listing and the removal is logged.
- The security review passes with no unresolved findings.
Model exclusions: mobile application; ticket payments; event analytics or attendance tracking; integration with the central university calendar; multi-department moderation; email marketing to students.
Typical errors to mark down:
- "Users are happy" or "the portal is user-friendly" as success criteria — unobservable.
- A constraint list that mixes assumptions into it.
- No exclusions at all, or exclusions nobody would have assumed (for example "we will not build a spaceship").
- A charter that plans for full-time effort when the developer is available one day per week.
Marking note on Task 5 (the date). Accept either a reasoned acceptance of the date as a constraint with a stated test, or a reasoned challenge to it. Do not accept an uncritical acceptance with no statement of the risk.
Lab 02 — Identifying and Classifying Stakeholders¶
Model classification (power / interest, with the stance in brackets). Reasonable variation is acceptable where the reasoning is sound:
| Stakeholder | Power | Interest | Stance |
|---|---|---|---|
| Provincial minister (sponsor) | High | High | Manage closely |
| Provincial IT department | High | Medium | Manage closely — owns approval and hosting |
| Municipal department heads | High | Medium–High | Manage closely; one is resistant |
| Department complaints clerks | Low–Medium | High | Keep informed — their work changes most |
| Call-centre operators | Low | Medium–High | Keep informed; training is the issue |
| Citizens and residents' association | Low | High | Keep informed; the association is an advocate |
| Provincial auditor general | High | Low now | Monitor, then inform before audit |
| Disability advocacy group | Low–Medium | High once engaged | Keep informed — engage early |
| Contracted developers | Low | High | Manage closely (delivery) |
Likely additions (Task 1). The strongest answers add some of: the privacy or data-protection regulator (the system holds personal data); municipal frontline supervisors; the hosting and operations team; the procurement/legal office; the press; telephone-line staff at the provincial call centre; and internal audit.
Movement analysis (Task 3). Expected candidates:
- Department heads: move when their staff begin using the system, or when the first response-time figures are published.
- Auditor general: interest rises sharply at audit time; power was always high.
- Disability advocacy group: moves on publication of the citizen-facing interface.
- Residents' association: may become less supportive if response times do not improve, because their campaign becomes tied to the outcome.
Pre-emptive action (Task 4). The strongest answers target the auditor general or the privacy regulator — high power, low current interest — with a concrete action such as: "Book a 45-minute briefing in week 3 with the auditor general's office to agree how service-level compliance will be reported, before the first data is published. Owner: project manager. Date: week 3."
Task 5 (resistance as information). The objection to "being monitored" most plausibly encodes: (i) concern about how complaint volumes will be used in performance evaluation; (ii) concern that response-time data will be published without context; (iii) a genuine worry about staff time to use the new system. The answer must extract at least one of these and propose a design response — for example reporting response times by department with volume context, or agreeing in advance what will not be published. A answer that only proposes "communication to address concerns" without identifying the concern is weak.
Lab 03 — Defining a Project Vision¶
Model problem statement. Marks are lost or at risk of loss because four lecturers keep separate spreadsheets; reconciling marks consumes lecturer time at the end of each assessment period; and there is no single record of what a student has been awarded. Features must not appear in this statement.
Model vision. "Lecturers will record, and students will see, marks from a single system they can trust, so that no mark is lost and no assessment period ends with a reconciliation exercise."
Model success criteria — for example:
| Criterion | How measured | By whom |
|---|---|---|
| Four lecturers submit a full assessment period's marks through the system | System records | Head of department |
| A mark can be corrected and the correction is visible in an audit log | Inspection of the log | Records office |
| Lecturers' reconciliation time falls from about four hours to under one hour per assessment | Lecturer self-report, one period | Head of department |
| Every mark is recoverable after a device failure | Restore test | IT office |
Model exclusions: video hosting; mobile application; quizzes and automated assessment; discussion forums; attendance recording; integration with the timetabling system; migration of historical spreadsheet marks (or explicitly in scope with a stated approach — either is acceptable if stated).
Task 6 (the date). Strong answers state what would be sacrificed first (typically video, forums, and the mobile application are already excluded; the realistic sacrifice is the integration or the historical migration), and name what is needed from the head of department: a decision on exclusions, and confirmation that the sceptical lecturers will be brought into the pilot.
Common errors: success criteria that are unmeasurable ("lecturers are satisfied"); a vision that lists features; deliverables and outcomes conflated; exclusions that are trivially obvious.
Lab 04 — Identifying Project Constraints and Assumptions¶
Model categorisation. Examples of a correct split:
| Statement | Constraint | Assumption | Open question |
|---|---|---|---|
| Launch before end of financial year | ✔ (date) | Who can change it? | |
| Budget fixed; no supplementary request | ✔ (cost) | Whether the funding owner would approve a change | |
| Team of 2 devs, 1 backend dev, 0.5 tester, shared security specialist | ✔ (resource) | How the specialist's other 2 days a week are actually spent | |
| Meets information-security policy and regulator's authentication requirements | ✔ (regulatory) | The current version of the requirements has not been read | |
| Core banking system provides a transaction API; will not be changed | ✔ (technical) | Whether the API documentation is accurate | |
| No release without security specialist's approval | ✔ (quality/gate) | The specialist's availability at the release window | |
| 60% of portal users install within six months | Outcome, not a constraint | Who owns adoption | |
| Call centre handles enquiries using existing staff | ✔ | Whether the call centre manager agrees |
Binding constraint. The strongest answers name the security specialist's approval gate combined with their 30% availability. Reasoning: no release can occur without their approval, and their availability is small and shared with another programme, so it gates the single most important event in the project. A close second is the fixed financial-year date, which removes the option of extending. If the security approval were resolved — approval delegated, or a second specialist engaged — the regulator's authentication requirements would become binding, because they determine the design of the entire authentication flow and, at present, nobody has read them.
Unpriced risks presented as facts. Expected answers include: the call-centre support statement (made without the call centre manager); the API stability claim (four-year-old documentation, two endpoints "subject to change"); and the regulatory compliance claim (current requirements unread).
Typical errors: treating the brief as accurate about what is fixed; listing constraints and assumptions as one list; no open questions at all despite obvious unknowns.
Lab 05 — Creating a Stakeholder Register¶
Model engagement levels (current → required):
| Stakeholder | Current | Required | Gap and action |
|---|---|---|---|
| Medical director | Supportive | Leading | Keep informed; use her to advocate |
| Head of outpatient services | Neutral–Resistant | Supportive | Co-design the clinic scheduling rules with her staff |
| Patients' association | Supportive | Leading | Involve in usability testing with older patients |
| Clinic receptionists | Resistant | Neutral | Written role clarity before go-live; escalate staffing question to the sponsor |
| Records administrator | Neutral | Supportive | Deliver the interface specification and security review evidence |
| Messaging vendor | Supportive | Supportive | No gap; hold to interface requirements |
| Data-protection officer | Unaware | Supportive | Engage now with a data description and retention proposal |
| Facilities and telephony | Unaware | Neutral | Notice before any call-routing change |
| Developers | Supportive | Supportive | No gap; protect their access to a test clinic |
RACI answers. The Accountable role should be, for example:
| Decision | Accountable | Why not the project manager |
|---|---|---|
| Accepting the portal for go-live | Medical director (sponsor) | Acceptance is a judgement about whether the hospital can operate the system and whether its risks are acceptable |
| Changing the appointment rules | Head of outpatient services | She owns the clinical process the rules encode |
| Approving interface access | Records administrator | They own the patient-record system and its risk |
| Approving patient-facing interface design | Head of outpatient services (with the patients' association consulted) | The design affects her patients' experience and her staff's workload |
Deliberate non-closure. The strongest registers nominate the facilities and telephony manager (monitor; accept that a late request may arrive) or the messaging vendor (keep informed only, since their interest is commercial and their power is limited). Either is acceptable with a stated consequence.
Common errors: combining power, interest, and attitude into one score; engagement gaps with no action or owner; no deliberate non-closure; a RACI with two Accountable roles; a "so what" section that says all stakeholders matter.
Lab 06 — Developing a Scope Statement¶
Model ambiguity register (five required; the following are expected):
| Requirement | Interpretation A | Interpretation B | Decision owner |
|---|---|---|---|
| "see what's in stock" | Live availability from the accounting package | A nightly snapshot showing "usually available" | Business owner |
| "work on phones" | Responsive website | Installable mobile application | Business owner |
| "run discounts" | Simple percentage codes on the whole basket | Product- and category-level promotions with conditions | Business owner |
| "track their delivery" | Display the courier's tracking number as a link | Live delivery status pulled from the courier | Business owner (and courier) |
| "look professional" | Match competitors' visual standard | A specific brand direction defined by the owner | Business owner |
| "customers should be able to buy things" | Guest checkout | Registered accounts only | Business owner |
For each, the cost of being wrong must be stated — for example, choosing "live availability" and discovering the accounting package cannot provide it means redesigning the browse and checkout experience mid-build.
Phase split (Task 5). A defensible launch set: browse, stock visibility (as a nightly snapshot), cart, card payment through the existing gateway, order confirmation and email, a "where is my order" page showing the courier tracking number, and an administrative product/order screen. Deferred: real-time stock, complex promotions, installable mobile application, courier integration, automatic low-stock alerts.
The strongest answers state plainly what they would say to the owner: with four months, two part-time staff, and no technical staff in-house, the choice is between a complete launch of a smaller scope and a partial launch of a larger one, and suggest agreeing the split now rather than discovering it in month three.
Common errors: resolving ambiguity silently; acceptance criteria that cannot be tested ("supports discounts"); exclusions that duplicate the in-scope list; a phase split with no reasoning.