The Volunteer Project That Ran Out of Time
A team of four students is building a data analytics solution for a local council: a dashboard of park usage from foot-traffic sensors and bin-weight sensors. They have six weeks and meet two hours per week. The council contact changes after week two and the new contact has different priorities (waste collection efficiency rather than park usage). The sensor data arrives as a daily CSV with inconsistent column names and frequent missing days. By week four the team has a working prototype but no documentation, one member has done 70% of the work, and the council asks for a demo next week. The team also discovers the sensors do not cover two of the five parks the council cares about.
1. Assess the project management failures and propose a recovery plan for the remaining two weeks.
Read the worked answer
Failures:
- No agreed scope or change control. The council contact change altered priorities with no formal re-scoping. The team absorbed the change silently, so effort went in two directions.
- Unrealistic schedule. Four people × two hours × six weeks is about 48 person-hours total. That is not enough for ingestion, cleaning, dashboard, documentation and stakeholder management unless scope is tightly cut.
- Uneven workload. One member doing 70% is a single point of failure; if they are unavailable, the demo fails.
- No documentation. Undocumented work cannot be handed over or maintained, and the council cannot own it.
- Coverage gap discovered late. Two of five parks are not instrumented; this should have been established at requirements time.
Recovery plan (two weeks):
- Re-confirm scope in writing with the new contact: one park, waste-efficiency view, clearly labelled as a prototype.
- Cut features: drop anything not needed for the demo; freeze the feature list.
- Pair the dominant member with another to transfer knowledge and write a one-page README and data dictionary.
- Handle the coverage gap explicitly: show the three instrumented parks and state that two are not covered, rather than implying full coverage.
- Assign owners and dates for demo script, slides, and a limitations page.
- Demo what works, be explicit about what does not, and agree next steps with the council.
2. The council asks for a demo next week. What should the team show, and what should they explicitly not claim?
Read the worked answer
Show:
- A working end-to-end path on one park: raw CSV → cleaning steps → dashboard view, so the council can see the pipeline is real, not mocked up.
- The waste-efficiency view, since that is the new contact's priority.
- A visible data-quality panel: missing days, sensor outages, and how they were handled.
- A short limitations slide: three of five parks instrumented, prototype status, what would be needed for production.
Do not claim:
- That the dashboard represents all five parks. Two are uninstrumented; presenting a five-park total would be misleading.
- That missing days are zero-usage days. Absence of data is not zero.
- That the prototype is production-ready or maintainable by the council without documentation.
- Any causal statement (e.g., 'waste is reduced because of the new schedule') from observational sensor data.
Also do:
- Bring the data dictionary and README so the council can see what they would inherit.
- Ask the council to confirm priorities for the next phase in writing, so the scope-change problem does not repeat.
- Be honest about the workload concentration and what support the team needs to finish.
A demo that shows a narrow, honest, well-documented slice builds more trust than an over-claimed full-system view that collapses under questioning.