Day 329
Week 47 Day 7: Assignment: Use Both Templates on a Live Project This Week
This week's assignment: take a real project that your team is about to start (or one that recently started without clear alignment) and apply both templates. Fill in the Commander's Intent and the Definition of Done. Share them with the team and use them as the reference for the project.
Lesson Locked
Pick a project that starts this week or next. Fill in the Commander's Intent (purpose, key tasks, end state) and the Definition of Done (deliverables, quality, scope, out of scope, verification, approver). Share both documents with the team at the project kickoff. At the end of the project, evaluate: did the templates reduce ambiguity? Did they prevent rework? What would you change for next time?
Here is the step-by-step process. Step one -- select the project. Choose a project that is significant enough to benefit from the templates but not so large that the templates feel like a small contribution to a massive planning effort. A project that will take 1-3 weeks is ideal for a first application. Step two -- fill in the Commander's Intent first. Start with why. Write the purpose statement (2-3 sentences explaining why this work matters to the business). Then list the 3-5 key tasks (the critical path items without which the project cannot succeed). Then describe the end state (the measurable outcome that defines success). Step three -- fill in the Definition of Done. Write the specific deliverables (what the team will produce). Define the quality standard (how good it needs to be). List what is in scope and what is explicitly out of scope. Describe how completion will be verified and who the final approver is. Step four -- share and discuss. In the project kickoff meeting, present both documents. Ask the team: 'Does this match your understanding? What am I missing? Is anything unclear?' This discussion is as valuable as the documents themselves because it surfaces misalignment before work begins rather than after. Listen for: 'I thought we were also doing X' (scope misalignment), 'What do you mean by Y quality standard?' (quality ambiguity), and 'How does this connect to Z?' (purpose gap). Each of these questions, surfaced at kickoff, prevents a week of misaligned work. Step five -- use the documents as a reference during the project. When questions arise about scope, priority, or standard, refer back to the documents: 'Let us check the Definition of Done -- is this in scope or out of scope?' This creates the habit of using the documents as living references rather than one-time artifacts. Step six -- retrospective: at the end of the project, ask three questions. Did the Definition of Done accurately describe what done looked like? Did the Commander's Intent help the team make decisions when ambiguity arose? What would you change about the templates for the next project? Use the answers to refine your team's version of the templates.
The single-project pilot approach implements what Kolb (1984) calls 'experiential learning' -- the principle that adults learn most effectively through concrete experience followed by reflective observation, rather than through abstract instruction alone. The pilot project provides the concrete experience; the retrospective provides the reflective observation. This sequence produces more durable learning and higher adoption than distributing the templates without a guided first-use experience. Research by Edmondson, Bohmer, and Pisano (2001) on 'disrupted routines: team learning and new technology implementation in hospitals' found that teams that implemented new tools through structured pilot experiences (guided first use with reflection) adopted the tools 3 times more successfully than teams that received training without a guided implementation, because the pilot experience generated team-specific knowledge about how to adapt the tool to their context. The kickoff discussion (Step four) implements what organizational learning researchers call 'shared mental model development' (Cannon-Bowers, Salas, and Converse, 1993) -- the process of creating a common understanding among team members about the task, the team's capabilities, and the expected workflow. Their research found that teams with shared mental models (developed through explicit discussion at the start of a project) showed 25% fewer coordination failures and 20% faster decision-making than teams without shared mental models.
Continue Reading
Subscribe to access the full lesson with expert analysis and actionable steps
Start Learning - $14.99/month View Full Syllabus