Project Planning Template

A director who manages cross-functional projects and consistently plans well at the objective and milestone level but leaves the owner field in the milestone table blank or filled with 'team.' When milestones slip, she's surprised by who didn't know they were responsible. The accountability gap was built into the plan from the start.

Name the owner field before she fills in the milestone table. 'The owner column is where this template does its work. A milestone without a named owner is a commitment made to no one. Before you fill in milestones, I want you to think about who specifically will be accountable for each one - not a team, not a function, one person.' The resistance is relational: naming owners can feel like assigning blame in advance. Name the alternative cost: 'When ownership is unclear in the plan, it becomes a conflict in execution.'

Watch the owner column specifically. 'Team,' 'marketing,' or blank entries are not owners - they're categories. Also watch the status column in the milestone table: if she fills in status as 'planned' for every milestone, she hasn't engaged with the accountability question yet. The milestone table should look different from a to-do list: each row should have a named person who will be asked about that milestone's status at the next check-in.

Start with the owner column. 'Read me the owners for each milestone. For each one: have you told that person they own this?' If any say no: 'What happens if you never have that conversation?' Then look at the first three actions: 'Do all three have named owners?' The question that creates movement: 'Which milestone on this plan is most likely to slip because the ownership question isn't clear - and what would you do today to clarify it?'

A project manager who has learned to include a risk section in project plans and diligently lists three to five risks per project. His mitigation column is consistently blank or contains 'monitor' for every risk. He believes he has done risk management by naming the risks. The distinction between risk identification and risk mitigation hasn't been made explicit in his experience.

Name the distinction before he fills in the risk section. 'There are two different activities here: identifying what could go wrong, and deciding what you'll do before and when it does. The risk section of this template needs both. Naming a risk without a mitigation plan is documentation, not preparation.' The resistance is time: mitigation plans feel like extra work, especially for risks that might not materialize. Name the asymmetry: 'Mitigation is cheap before the risk happens. After it happens, you're doing recovery instead of execution.'

Watch the mitigation column specifically. 'Monitor,' 'escalate if needed,' and 'address as it arises' are not mitigation plans - they're deferred responses. A mitigation plan names what happens before the risk materializes (prevention) or the specific action when it does (response). Also watch whether his identified risks are real risks for this project or generic project risks he copies across plans - generic risks have generic mitigations that are rarely useful.

Start with one risk from the table. 'This risk - walk me through what a mitigation actually looks like. What specifically happens before this risk materializes, and what happens on day one when it does?' Then look at the others: 'Which of these risks would be most damaging if it materialized with no mitigation in place? What's the plan for that one specifically?' The question that creates movement: 'If this risk materialized tomorrow and you opened this plan, would the mitigation column tell you what to do - or would you be figuring it out in the moment?'

A startup founder who is a strong strategic planner. His objective, success criteria, milestone table, and risk sections are thorough and specific. The first-three-actions section at the bottom of the template is often left brief or filled in as a formality: 'review with team,' 'finalize timeline,' 'share with stakeholders.' These are not actions that move the project forward - they're project management overhead. The actual first move is missing.

Name the purpose of the first-three-actions section before he fills it in. 'These aren't any three actions - they're the three that transform this plan from a document into a project in motion. They should answer: what happens in the next 72 hours that makes this real? If the actions are about managing the plan rather than executing the work, we haven't found the real first moves yet.' The resistance is thoroughness: he's satisfied with a complete plan and the first actions feel like a postscript. Name the section as the plan's ignition switch.

Watch whether the first three actions are executable in the next 72 hours without any further planning. 'Finalize timeline' requires planning before it can happen - it's not a first action, it's another planning step. 'Reach out to the client to schedule the kick-off call' is an action. Also watch whether any of the three actions connect directly to the first milestone: the actions that move the first milestone are the ones that matter most.

Start with the first action. 'Can you do this today? If not, what needs to happen first?' Then: 'Of the three actions, which one makes the first milestone possible - and is that action on this list?' The question that creates movement: 'If you left this session right now and came back in 72 hours, what is the one thing I should see done that would tell me this project is actually in motion?'