Following on from last weeks post on Project Scheduling, here is a look at ‘ Project Schedule Granularity’.
Project Schedules
Projects are unique by definition, and can take weeks, months, or years to deliver.
The project schedule should somehow match the time-frame for the overall project. If the project takes several weeks, then tasks might be scheduled for days or a week, but not for a month. If the project takes several years, tasks may be scheduled for weeks or months, but not for days (at the highest level).
Project Schedule Granularity
Too much detail, and the project may be consumed by paperwork and the administration in keeping track of the progress of every task. Too little detail, and the project will flounder with ill-defined tasks and assignments.
Project Schedule Granularity
The idea of choosing the correct project schedule granularity ensures that the plan is in the correct amount of detail.
Typically, a 3-month project may need tasks defined in 1, 2, or 3 day blocks. A 3-year project may require tasks to be defined in 1-month blocks.
That is not to say that more detail is not required for the larger project within those month blocks. These may exist as sub-projects, with the detail held by other departments/junior project managers, or by a further level of detail in the Work Breakdown Structure.
The overall project plan (for a 3-year project) will not include tasks of 1 day duration (or there would be thousands of tasks).
The plan for a 3-month project will not include tasks that take longer than 1 month (or there will be no progress to report).
Benefits of Project Schedule Granularity
One benefit of getting the project schedule granularity correct for the overall project duration is that monitoring progress will be easier, and more accurate. There will be adequate monitoring of shorter tasks, and no over control on the larger tasks.
The critical path is likely to more accurate if the project schedule is composed of tasks with suitable durations, and the critical path will change as the durations of those tasks varies through the project.
How Detailed Should a Project Plan Be?
So how detailed should a project plan be? Detailed enough to stay in control, but not too detailed to be always updating progress.
Granularity to suit the Stakeholder Needs
Another way of looking at the project schedule granularity is to identify what the stakeholders will need in the way of progress checks, and report frequency. In this way tasks can be planned to be timed to the stakeholder reporting requirements.
Rolling Wave Planning
Rolling Wave Planning is where the project exists in good detail for the following 3 months only, and in less detail for the activities that are further out. The tasks occurring in the next 3 months may have durations of 3-5 days, and tasks that happen in 6 months may have durations of weeks or months.
The plan is then refined as time passes.
Getting a schedule correct is a vital part of project planning and scheduling. Too much detail, and the project is over-controlled, and time is lost in administration and reporting. Not enough detail, and the project will be ill-defined and possibly fail.
