Limit Project Plans to Less Than 300 Tasks
As a rule of thumb, project plan should not have more than 300 tasks. Rather than giving more control, project plans with more than 300 tasks actually cause loss of control. From our implementations and field experience, we have observed the following ways in which complex plans cause loss of control:
- Human errors such as incorrect activity dependencies or resource assignment creep into project plans.
- Project Managers cannot interpret and use complex plans for project-level decisions and tradeoff's.
- Task Managers cannot control multitasking when tasks are defined too finely.
- Too much detail in a project plan causes frequent re-planning.
- Finely defined tasks in a project plan make Task Managers less accountable. They move the responsibility of execution away from the frontline towards the top.
Following guidelines might be helpful to tame the tendency to create overly detailed plans:
- A project plan is not a task manual.
- A project plan is not a reminder list.
- A task that takes less than 2% of the project's lead-time must have a very good reason to appear in the plan.
- A task represents a group of work. It should not be broken down to several tasks just because it requires different resources for different durations of time. But it should be broken for chosen key-resource-types; a task should be defined so that those key resources are required for most of the task time.
Having said the above, there are genuine cases when projects are so large that the work cannot be meaningfully captured in less than 300 tasks. In those cases, a zooming mechanism is recommended whereby the tasks in the higher level project are managed as sub-projects.
And that's the Execution Management Minute for this week. |
