4.7 Chapter Review
4.7.1 Chapter summary
A team charter is a negotiated operating agreement for how a team will complete and integrate its work. It should define more than roles: it should establish responsibilities, decision rights, communication norms, review expectations, file practices, escalation procedures, and the conditions under which the agreement will be revised.
4.7.2 Common mistakes
- assigning roles without defining decisions, outputs, or review responsibilities;
- allowing roles to become isolated silos with incompatible methods or formats;
- recording meeting times without specifying agendas, decisions, or follow-up;
- waiting until conflict becomes personal before using an escalation process; and
- treating the charter as a form completed once rather than an operating agreement that can be revised.
4.7.4 Exercises
Exercise 1. Rewrite each vague expectation as observable team behaviour, then identify how the team would know whether it had been met: (a) everyone will communicate well; (b) everyone will contribute equally; (c) the team will make decisions together; and (d) work will be completed on time.
One Possible Answer
- Members acknowledge project messages within one working day and record decisions in the shared log. (b) Each work package has an owner and reviewer, and workload is reviewed weekly rather than assumed equal. (c) High-impact decisions require consultation and a recorded decision rule; routine decisions belong to the assigned owner. (d) Drafts are submitted by internal deadlines with the stated definition of done. Message timestamps, the responsibility map, decision log, and milestone record provide observable evidence.
Exercise 2. Draft a team charter for the NVRW project using the template appendix. Define decision rights, file ownership, review expectations, meeting records, missed commitments, and escalation.
Check Your Work
A complete charter should identify the team’s purpose, roles, behavioural expectations, meeting and communication practices, authoritative file location, naming and version rules, decision authority, peer-review process, response to missed commitments, escalation route, and amendment procedure. It should explain what the team will do, not merely state values such as respect or professionalism.
Exercise 3. Create a responsibility and review map for the data dictionary, EDA, modelling, projections, report, and presentation.
One Possible Answer
Assign one owner and at least one independent reviewer to every deliverable. For example, the data lead may own the dictionary while the modelling lead reviews derived variables; the modelling lead may own validation while the project lead checks decision fit; and the communication lead may own the report and slides while every analytical owner verifies the claims that use their work. No person should be the sole creator and sole reviewer of a major deliverable.
Exercise 4. Write a handoff checklist for transferring a cleaned dataset and analysis script from the data lead to the modelling lead.
One Possible Answer
The handoff should include the authoritative file paths, extraction date, row counts, grain, primary and foreign keys, dictionary version, cleaning log, missing-value and outlier decisions, derived-variable rules, software requirements, script run order, expected validation totals, known limitations, and the name of the person who can answer questions.