Case Study — The Campus Event Portal¶

Illustrative case

This is a synthetic teaching scenario, written for this course. It does not report on any specific real project, organisation, or person, and it contains no real statistics or quotations. Its purpose is to give you realistic decisions to reason about.

At a glance

Related modules: 01, 02, 05, 08
Type: Illustrative
Estimated time: 45 minutes

Situation¶

A mid-sized university wants a Campus Event Portal: a web application where student societies publish events, students browse and register interest, and staff moderate listings.

The idea originated with the student affairs director after a term in which societies coordinated events through a mix of social media posts, printed notices, and word of mouth. Attendance was unpredictable and staff spent several hours a week answering "what's on?" questions.

The director secures a small budget and asks the IT office to deliver the portal before orientation week, roughly twelve weeks away. A part-time student developer is assigned, and one IT staff member is to be shared across three other projects.

What is known at the start¶

Single sign-on already exists and, per IT, the portal must use it.
The IT security team requires a review before any public launch.
The societies are enthusiastic but organised informally; there is no agreed list of required features.
The student developer is available around fifteen hours a week during term.
The IT staff member's availability depends on the other three projects.
Nobody has written down what "done" means.

Sequence of events¶

Week 1. The project starts. The student developer begins building the event listing page, choosing a framework they already know. No charter is written; everyone considers the goal obvious.

Week 3. A society asks for recurring events and image galleries. The developer agrees, because they seem easy. The IT staff member, who has not been involved since week 1, is surprised to hear a framework was chosen without a security input.

Week 5. The director sees a demo and is pleased. The security review is scheduled for week 10.

Week 8. The security review is brought forward after an unrelated incident elsewhere on campus. The portal fails on two counts: sessions do not expire correctly, and uploaded images are stored without validation. Fixing both is significant work.

Week 9. The director asks whether the launch date can still be met. The team realises it has no baseline, no record of the changes made since week 1, and no agreed definition of the first release.

Week 11. The team cuts the image upload feature and the recurring-events feature, fixes the security issues, and launches a reduced portal in week 12 — late by a few days, with two features that societies had been told were coming.

Discussion questions¶

Work through these before revealing the model answers. The value is in your reasoning.

Which foundational practice was missing at the start, and how would it have changed weeks 3 and 5?
Identify at least three stakeholders who were not properly engaged, and what each needed.
At week 3, the developer accepted new feature requests. What was the problem with how that was handled, even though the features were easy in themselves?
Classify three risks that were apparent by week 1. Which would you have prioritised, and why?
Was the week-12 launch a failure? Argue both sides, then state your view.
If you could change exactly one decision made in the first two weeks, which would you choose, and what would it have prevented?

Model answers

These are reasoning guides, not the only correct answers. Credit is for sound reasoning grounded in the facts given.

Missing: initiation and a charter. A charter would have recorded purpose, scope boundaries, constraints (single sign-on, security review, fixed date), the part-time capacity, and success criteria. It would have made the week-3 feature additions a deliberate scope decision rather than an ad-hoc acceptance, and would have ensured IT security was engaged before a framework was chosen.
Mis-engaged stakeholders, among others: (a) IT security — needed to be involved from the start; the failure was predictable. (b) Societies — enthusiastic but with no agreed requirements, so their expectations went unrecorded and were then cut. (c) The shared IT staff member — whose other commitments were never built into the plan, and who was excluded from technical decisions.
Agreeing to add features without assessing their effect on the schedule or on the security review. Individually small features accumulate into scope creep, and here they introduced a security-relevant capability (image upload) that had not been reviewed.
Candidate risks: the fixed orientation-week date combined with part-time capacity; dependencies on single sign-on and a shared, over-committed staff member; the absence of agreed requirements; the mandatory security review. Most would prioritise the security review and the capacity/date combination, since either could stop the launch entirely and both were knowable in week 1.
Not a failure: the portal launched with the core capability, passed security, and delivered most of the intended value; a late, honest launch can be the right call. A failure: two features promised to societies were withdrawn late, capacity was over-committed, and the security issues were self-inflicted. A reasonable view: the launch was acceptable, but the management of the project was poor, and the cost fell on the societies.
A defensible answer: write a one-page charter in week 1. It would not have prevented every problem, but it would have surfaced the security constraint, the part-time capacity, and the absence of agreed requirements before they became crises.

Take-aways¶

Initiation is not paperwork; it is the cheapest place to find out what you do not know.
Constraints that are not written down cannot be planned around.
Small feature additions are not free when they interact with security, quality, or approval gates.
A reduced launch is a legitimate outcome; losing trust by over-promising is the real cost.