Skip to content

Lab 03 — Defining a Project Vision

At a glance

Learning objectives

By the end of this lab you should be able to:

  1. Turn a list of requested features into a statement of the problem being solved.
  2. Write success criteria that a third party could test.
  3. Distinguish a deliverable from an outcome.
  4. Write exclusions that make a project finishable.

Scenario

Your university's Department of Data Science has asked for a Learning Management System (LMS) to support its own teaching. A lecturer currently distributes notes by email, collects assignments by hand, and records marks in a spreadsheet. Four separate spreadsheets exist, one per lecturer, and marks have twice been lost when a laptop failed.

The request, as submitted, reads: "We need an LMS like the commercial ones, with a gradebook, video lectures, quizzes, discussion forums, attendance, and a mobile app."

The head of department has approved a small budget and part-time effort from two staff, and has stated a target: the system should be in use for the next semester's courses. The semester begins in five months. One lecturer is enthusiastic and willing to pilot the system; two others have said that they will keep using their spreadsheets until the system "does what they need".

Your role

You are the project manager. You have been asked to write the one-page project vision that will precede the charter. Your audience is the head of department — a busy academic who will read one page and decide whether to commit the semester's arrangements to this project.

Project information and assumptions

The scenario is part of the example-project library — read the full description there if you want the wider context.

  • Available effort: two staff at 40% each for five months.
  • Hosting must use the university's existing infrastructure; the IT office will provide a server but the approval process runs in parallel with your build.
  • No budget for video hosting or for a mobile application in this phase.
  • Student data is personal data; the applicable data-protection obligations must be confirmed with the university's records office rather than assumed.
  • Marks are the sensitive part: an incorrect or lost mark is far more serious to a lecturer than a clumsy interface.
  • Assume marks from the current spreadsheets must continue to be available during the transition.

Tasks

Task 1 — Restate the problem

Rewrite the request as a problem statement: what is going wrong today, for whom, and what it costs in time, risk, or quality? Do not mention any feature in this step. (If you find yourself writing "needs a gradebook", you are describing a solution.)

Task 2 — Write the vision statement

One paragraph, in plain language, describing what will be true for lecturers and students when this project succeeds. Avoid feature lists, methodology, and technology names.

Task 3 — Write measurable success criteria

Write four to six criteria. Each must be observable by someone who was not involved in the project. For each, state how it would be measured and by whom.

Reject any criterion that contains the words "user-friendly", "robust", "modern", or "high quality" unless you also state the observation that would falsify it.

Task 4 — Separate deliverables from outcomes

Produce two short lists:

  • Deliverables — what you will build and hand over.
  • Outcomes — what will be different for the users as a result.

Then state which of the two you are accountable for, and which depends on someone else's action.

Task 5 — Write the exclusion list

List at least five things that are out of scope for this phase, drawn from the original request and from your own judgement. For each, state one sentence of justification and what would have to be true for it to come back into scope.

Task 6 — Test the target date against the criteria

The head of department wants the system in use next semester. Write three or four sentences stating whether the success criteria you wrote can be met by then, what you would sacrifice first if they cannot, and what you need from the head of department before committing.

Deliverable

A single page containing the problem statement, vision statement, success criteria table (criterion · how measured · by whom), deliverables and outcomes lists, exclusions with justification, and your answer to Task 6.

Hints and guidance

  • A vision is about change, not construction. "Lecturers will recover the four hours a week they currently spend reconciling marks" is a vision. "We will build a gradebook module" is a task list.
  • Test criteria by trying to fail them. If no observation could show the criterion unmet, it is not a criterion.
  • Exclusions protect the date. A scope with no exclusions has no boundary, and the boundary is the only thing standing between a five-month plan and an open-ended one.
  • Watch for the difference between a deliverable and an outcome. You can deliver the system perfectly and still fail, if no lecturer adopts it.

Self-check criteria

Check How to verify it
Problem statement contains no features Read it aloud; if a feature name appears, rewrite
Vision states a change for named people It names lecturers and students and what becomes different for them
Every criterion is testable For each, you can name the observation that would show it failed
Measurement is assigned Each criterion names who measures and how
Exclusions are real At least three of them are things a reasonable person would have assumed were included
Date is tested, not accepted Task 6 states what would be sacrificed, not merely whether the date is "challenging"

Reflection

  1. Which of your success criteria would be hardest to measure, and why? Is it worth keeping?
  2. Did writing the problem statement change your view of the requested features?
  3. The enthusiastic lecturer is a stakeholder with low power but high interest. Should the success criteria be designed around them? Justify your answer.
  4. Two lecturers will keep using their spreadsheets. What does that do to the outcomes you listed, and who owns fixing it?
Model discussion points
  1. Adoption and satisfaction criteria are usually hardest, because they require measuring people rather than systems. They are also the ones that decide whether the project mattered — so the correct response is to define a concrete observation (for example, "three of four lecturers submit a full set of marks through the system for one assessment period") rather than delete the criterion.
  2. It usually reveals that the feature list is a wish list, while the problem is narrower and more urgent: marks are at risk of loss and reconciliation takes too long.
  3. No. Designing success around the most willing adopter produces a system that demonstrates well and does not spread. The pilot should include at least one sceptical lecturer, because their objection is the requirement the enthusiasts will not mention.
  4. It converts the outcome from "marks are recorded in the LMS" to "marks exist in one place and are recoverable" — a weaker but honest outcome. The action to fix it belongs to the head of department, not the project, and saying so explicitly is part of the deliverable.

Extension challenge

Rewrite your success criteria so that every one of them could be evaluated six months after launch rather than at handover. Then state which criteria you had to change, and what the change reveals about whether the project was measuring delivery or value.