Like the construction of an airport that takes place in various phases, breaking a project into manageable parts is one of the most foundational parts of project management. Most other aspects of project management are built upon this foundation, so it should not be taken lightly.
Although it can sometimes seem trivial, it is one of the most important parts of a project manager’s job. So how can a project manager create a bulletproof task list?
Example Task List
In the Project Management Body of Knowledge (PMBOK), the output of the Define Activities process is a Task List, also called Activity List. The following might be a typical Task List for a sidewalk construction sub-project at the mega-airport:
|210||Pour Concrete||120, 130|
|310||Setting & Curing||210|
The task list also contains task attributes, which identify meta-level information about the task. For example, there could be a column called “Subcontractor”:
|120||Build Forms||110||Jon’s Concrete|
|130||Place Rebar||110||Jon’s Concrete|
|210||Pour Concrete||120, 130||Jon’s Concrete|
|310||Setting & Curing||210|
How to Develop the Task List
The task list developed using a process called Decomposition whereby the top level task is chosen first and then subdivided into smaller pieces:
- The top level is the name of the project, for example “Build Sidewalk”
- The second level are often (but not necessarily) phases, for example, “100 – Preparation” or “200 – Concrete Work”
- The third and subsequent levels are tasks and should therefore preceded with a verb. For example, “110 – Excavation” and “210 – Pour Concrete”
In an ideal world, you would completely define all of the project work during the planning phase. But since this is not realistic, you must get as close as possible as time and money allows.
The checklist for a good task list is:
- The tasks should be of a size and complexity that allow them to be reliably estimated. For example, it is difficult to estimate the cost for the task preparation. That’s why it’s divided into the sub-tasks excavation, build forms, and place rebar, which can be reliably estimated.
- The responsibility for the tasks should be clear.
- The task should be measurable. Effective project control requires that reliable percent complete estimates are given at any time. If this is difficult to achieve, break the task down further.
- The task should have clearly defined start and end dates.
Rules of Thumb
Here are some experience-proven rules of thumb which will help you to know when you are finished decomposing:
- Tasks should be between 8 and 80 man-hours of labor. This is a manageable amount. Any more, and you will lose control of the task because you are trying to manage a major sub-project. Any less, and you will lose control of the project by micromanaging tiny tasks. If you are learning project management it is best to err on the small side.
- Any level should contain no more than 10 tasks per phase. This makes the phase manageable and provides valuable reference points.
- Tasks should not be much longer in duration than the distance between two status points, about a week to a month in duration. Smaller is generally better. When performing earned value analysis during those status points, the percent complete for big tasks inevitably gets assigned as something like 35%, 65% or 95%. This is difficult to control and project team members are likely to exaggerate it. If you create the task to be small enough so that only 0%, 50% or 100% can be used, there can be no guessing as to whether a task is complete and project control will be very effective.
Here’s another rule of thumb. If you’re wondering whether to break down a task further, ask yourself these three questions:
- Is it easier to estimate?
- Is it easier to assign to someone?
- Is it easier to track?
Another way to break down tasks is the following. Ask yourself if a task is:
- Well understood?
- Not well understood?
This is generally an easy distinction to make. Then, if the task well understood, it is broken down enough. But if it’s not well understood:
- Separate out the parts that are not understood.
- Determine why it’s not well understood and perform some more due diligence until it is.
Often there will be a well defined point during the project execution where a task will become well understood. For example, after you’ve built the concrete forms for the driveway, the amount of reinforcing steel becomes much better known than it was before. Maybe some contingencies are needed to get to that point.
If you, or a member of your team can reliably estimate the work on your own, you are lucky. But most of the time some level of extrapolation is needed from other information sources. Three sources that should be considered for every project are:
- Previous Projects. Very few projects are absolutely unique. There are always other projects from which data can be gleaned and task lists appropriated. It’s even better when the project’s issues have been documented, because special attention can be given to tasks by breaking them down.
- Templates. Every project should consider task list templates. If none exist, let it be the first one, and adjust the activity list into a template for use on future projects. Many companies have standard task lists for projects they perform often. They can be adjusted to fit the project but the general list is there and ensures nothing gets missed.
- Expert Judgment. If you have access to an expert, this is the time to use them. How should the project be divided up? What is the estimated duration? Estimated cost? Required resources? Some of those questions refer to future parts of the schedule development processes, but the task list is the foundation.
Each task should have written completion criteria which defines the completion of the task. It is a common occurrence that a project manager feels a task is finished but subsequently sees time and materials charged to the task related to closing it. Often final details need to be compiled and submitted, or the task paperwork needs to be assembled and filed. Sometimes a walkthrough is necessary with a client, or a training session to teach clients to use the product.
We will add another activity attribute called “completion criteria” to our activity list:
|Task No.||Name||Dependencies||Subcontractor||Completion Criteria|
|120||Build Forms||110||Jon’s Concrete||All forms ready for concrete pouring|
|130||Place Rebar||110||Jon’s Concrete||All rebar ready for concrete pouring|
|210||Pour Concrete||120, 130||Jon’s Concrete||Concrete finishing complete|
|310||Setting & Curing||210||Ready for traffic|
|320||Strip Forms||310||Tools and Equipment put away|
Work Breakdown Structure
In project management lingo, a task list is also called a Work Breakdown Structure, or WBS. Although the PMBOK differentiates between the two, in practice they are generally used interchangeably.
In the PMBOK, the task list is used for scheduling and estimating, while the work breakdown structure is used for scope definition. If you are managing a large project greater than, say, $10 million or 10,000 man-hours, you might need both of these separately. However, small and medium sized projects can make do with one single task list, and these terms will be interchangeable.
Whether your project is a mega-airport or a small sidewalk, breaking it down into tasks is essential. Starting well equals finishing well. Good luck completing your task list and let us know if you have any other tips and tricks to help along the way.