4.3: Best Practices Guide

Purpose:

To decompose the project scope into structured, manageable, and traceable units of work that can be estimated, sequenced, and tracked.

Best Practices:

• Use at least three levels: Phases → Work Packages → Tasks
• Number tasks using WBS hierarchy (e.g., 2.1.3 = Task 3 of Package 1 in Phase 2)
• Use verb + object phrasing for all tasks: “Draft Requirements Document,” “Conduct Interviews”
• Ensure all work packages map directly to Milestone 2 deliverables
• Follow the 100% Rule: All work is accounted for, and nothing extra is added

Common Mistakes:

• Using vague task names like “Handle stuff” or “Manage process”
• Duplicating deliverables already broken down in prior phases
• Mixing in activities not in the approved scope
• Only creating 1–2 levels (not truly breaking down work)

Pro Tips:

• Print your WBS and ask a peer: “Can someone build a schedule from this?”
• Break down any task over 20 hours into smaller actions
• Include project management as a legitimate work package

Purpose:

To define the flow of the work: which tasks rely on others, what can run in parallel, and how bottlenecks can be avoided.

Best Practices:

• Use Finish-to-Start (FS) as your default logic
• Identify parallel tasks using Start-to-Start (SS) logic
• Include at least one dependency per task (unless it’s the first)
• Highlight external dependencies (e.g., stakeholder input, vendor access)
• Use a dependency matrix or annotated list—whatever is clearest for your workflow

Common Mistakes:

• Creating “flat” task lists with no sequencing logic
• Assuming all tasks are sequential and cannot overlap
• Leaving out risky or external delays that could impact flow
• Skipping documentation of why the sequence matters

Pro Tips:

• Build backwards from your milestones
• Start each task with the question: “Can this start now?” If not, identify the blocker
• Use sequencing to optimize resource usage (e.g., don’t stack everything on one role)

Best Practices:

• Use a mix of expert judgment, historical data, and three-point estimation
• Differentiate effort (hours) from duration (days) based on availability
• Document assumptions for all tasks, especially those over 16 hours
• Use round numbers and standard ranges (2–4–8–16–20 hours)
• Flag high-risk or uncertain estimates and explain them clearly

Common Mistakes:

• Using the same estimate (e.g., “8 hours”) for every task
• Assuming team members are 100% available (they rarely are)
• Skipping stakeholder time or review cycles
• Forgetting weekends, holidays, or context-specific delays

Pro Tips:

• Break large tasks into estimable chunks
• Double-check the total hours per role—does it align with reality?
• Highlight which estimates are flexible and which are fixed

Purpose:

To define key progress points where work is validated, approved, or transitioned—creating clarity and pacing for the project.

Best Practices:

• List 3–5 clear, meaningful milestones
• Tie each milestone to a deliverable or review event
• Assign an owner and target date for each
• Show how milestones align with your WBS and task sequencing
• Ensure milestone names are event-driven, not task-driven (e.g., “Requirements Approved,” not “Finish Writing Requirements”)

Common Mistakes:

• Listing too many milestones (one per task)
• Using vague milestone names like “Stuff Done” or “Halfway Mark”
• Missing dependencies or decision logic
• Forgetting to align milestones with stakeholder engagement windows

Pro Tips:

• Build your project schedule around your milestones, not the other way around
• Use milestones to pace client communication and accountability
• Ask: “Would hitting this milestone give us momentum—or permission to proceed?”

Purpose:

To confirm that your planning package is complete, coherent, and ready to support real-world execution—with all issues and risks surfaced transparently.

Best Practices:

• Review for internal alignment between scope, tasks, effort, and milestones
• Create a summary statement of confidence and assumptions
• Flag open questions, risky dependencies, or incomplete information
• Identify areas that need stakeholder or sponsor support
• Document all external blockers, not just internal planning gaps

Common Mistakes:

• Skipping this section entirely (“We already planned everything”)
• Avoiding documentation of risks (“We don’t want to look bad”)
• Not tying back to the Charter and Milestone 2 commitments
• Presenting a plan with misaligned sequencing, scope, or effort

Pro Tips:

• Think like a sponsor: “What would I need to see to greenlight this plan?”
• If a new team member joined—could they execute from this document?
• Use your readiness review as a handoff checklist for execution