Building the plan from consensus

You have ideas. Now you build the plan. The plan is the consensus, written down.

A project plan is different from a project scope. The scope is the 30,000-foot view: what we are doing, why, and how we will know it worked. The plan is the on-the-ground execution: who does what task, by when, in what order, with what dependencies. Both are needed. The scope tells the funder what you are doing. The plan tells the team how to do it.

A good plan is built from consensus, not handed down. After your team has worked through the impact/effort matrix, the affinity clustering, and the dot voting from Module 5, the plan emerges naturally from the highest-priority cluster. The PM's job is writing it down in a form the team will use.

Three tests for whether your plan is real: (1) every task has one Owner by name, (2) every task has a due date, and (3) the plan fits in the resource plan (you have not over-committed people). If any of the three fail, fix it before you start work.

The plan is a living document. Update it weekly. Mark completed tasks. Add new tasks as they emerge. Move tasks that are slipping. The PM's discipline is keeping the plan honest, not pristine.