Running a group project
| English | Chinese | Pinyin |
|---|---|---|
| scope | 范围 | fàn wéi |
| milestones | 里程碑 | lǐ chéng bēi |
| dependencies | 依赖关系 | yī lài guān xì |
Group projects fail on organisation, not ability
- Four capable students, one deadline, and nothing submitted. It is the most common way a group project ends badly.
- What failed was not the work. It was who was doing which part, and by when.
- GAC005 marks the process, so the plan is part of the deliverable.
Scope, then milestones
- A scope 范围 statement says what the project will and will not do.
- Most overrun starts as an unwritten extra that somebody assumed was included.
- Milestones 里程碑 are checkpoints with dates. They turn "we have three weeks" into something you can be behind on early enough to fix.
What does a scope statement do?
The "will not" half is the useful half. Most overrun starts as an unwritten extra.
Roles to people, not tasks to the group
- Assign each part to a named person. A task owned by everyone is owned by nobody.
- Track dependencies 依赖关系: the slides cannot be finished before the data is collected, so the data has the earlier deadline.
- The riskiest item gets the most attention first, not the most familiar one.
A task assigned to "the group" is safer than one assigned to a named person.
A task owned by everyone is owned by nobody. Name the person, every time.
Four people, a transport survey, due week 6.
Working backwards: rehearse in week 6, build slides in week 5, analyse in week 4, collect responses in weeks 2–3, write the questions in week 1.
The questions are the riskiest item, because everything downstream depends on them. So they get reviewed by the whole group, and nothing else happens in week 1.
A survey project is due in week 6. Put the work in the order it must happen.
Everything downstream depends on the questions, which is why they are reviewed by the whole group first.
Write one milestone for a group project, with a date and a named deliverable.
A milestone you can be behind on is the only kind worth writing, because it warns you early enough to fix it.
Write the team contract while everyone is still friendly. How you meet, how you decide, and what happens when someone does not deliver. It takes ten minutes in week one and cannot be agreed at all after the first problem.
When should a team contract be written?
After the first problem it cannot be agreed at all — the rules would now be about a specific person.
Do not plan the presentation first because it is the visible part. The presentation depends on the analysis, which depends on the data, which depends on the questions. Planning forwards from the fun end is how groups discover in week 5 that they have nothing to present.