Although this planning step is often considered a no-brainer,  it is a very critical step, as forgetting a task in a project can be a catastrophe in the estimation and risk process (see Figure 13.1). In fact, forgetting project tasks is one of the more common reasons for poor estimation and project slippage.
Figure 13.1. Developing a task list
The process of developing a task list for your project is fairly straightforward:
Clearly, if you are using the RAP process that we have been discussing throughout this book, you'll have your team and your critical stakeholders planning the project with you. You'll have all the people you'll need to do the task listing without a problem.
Methodologies: A Brief Introduction
The computing profession has had access to very comprehensive packaged sets of work breakdown structure or task lists or, as they are more commonly termed, methodologies since the early 1970s.
However, all project or system development approaches are based on a long understood and commonsense approach to solving problems that we first saw in Kroberg and Bagnall's (1974) wonderful book, The Universal Traveller .  This step-by-step approach is also well suited to the monolithic or waterfall project development strategy that we explored in Chapter 10. Kroberg and Bagnall's model is overviewed in Figure 13.2.
Figure 13.2. The universal traveler approach
All packaged methodologies provide a framework of development phases that are broken into subphases that, in turn , are further broken down into tasks, and so on. This partitioning or leveling of tasks into smaller subtasks is the essence of work breakdown. The breaking down of tasks into smaller units is essential for estimation and scheduling, as we discuss in later chapters.
1. Tailor Methodology
The easiest way to do this activity is for one of the participants in the planning session to read aloud the major phases and subphases contained in your organization's standard methodology. If your project needs the task, list it on a whiteboard or a public document. If anyone in the planning session doesn't understand what is involved in the listed task, have the reader get more information from the supporting documents associated with the methodology.
2. Brainstorm Project Tasks
If you do not have access to some predeveloped task list, you'll need to develop one for your project using the experience of your team and as many other project experts as possible. It is also useful to see if you can access other project plans or task lists from other project managers. In addition, there are fairly good task lists available in some of the books we have already referenced in this book.  In fact, any book on a new technique such as object orientation or visual development tools will give you the basis for a methodology.
3. Fine-Tune Your Methodology
Even with a "packaged" methodology, you'll generally need to add new tasks that reflect the uniqueness of your project. Be careful here, as many methodologies are focused on system development and often miss tasks associated with the clerical, policy, and business process redesign associated with many projects. By having your business stakeholders at your RAP session, you should have this issue well covered.
4. Review with Other Experts
Even in a RAP session you probably won't have all the experts you need in your project. It thus makes sense to check your "first cut" task list with as broad a group of experts as you can. In many projects, you should also check with your external suppliers and vendors . In one project, our client was having trouble developing a task list for a highly innovative project. They engaged a consultant recommended by a vendor. Within two days, a complete and, as it turns out, very accurate task list was created. In our opinion, this was a very wise investment.
5. Repeat the Process
This step breaks or partitions the "first cut" task list into smaller subtasks as shown in Figure 13.3. As we discuss later in this chapter, there are a number of considerations when creating a more detailed work breakdown structure. However, the overriding consideration here is that by breaking up higher level tasks (e.g., requirements analysis) into smaller subtasks (e.g., interview business experts, review current business processes, etc.), you get a better understanding of what is required to complete the task and this improves the accuracy of your estimates.
Figure 13.3. Work breakdown structures
Simply put, the better you understand what you have to do, the better your estimates will be.
The Amazing 5/10 Day Rule
One of the long-held beliefs in traditional business project management is the concept of partitioning or breaking down into subtasks of 5 to 10 days in duration. On reflection, this rule reflects the process culture view of the world (remember Chapter 4?) and has little or no relevance to the project world. The concept of 5- to 10-day tasks with associated deliverables has a lot of appeal in a world driven by hourly, daily, weekly, and monthly processes.
In reality, the degree to which you can partition a task depends on the nature of the task, not the calendar, as we discuss later in this chapter.
The real issue here is how often you need to track tasks for completion. As shown in Figure 13.4, Task A is 10 days in duration, Task B is 6 days, and Task C is 4 days. As we cover in more detail in Chapter 17, the process of task tracking should be driven by the "0/100%" approach (either the task has not started or it is finished). In this case, the tracking cycle is 10 days for Task A, 6 days for Task B, and 4 days for Task C.
Figure 13.4. Task size and tracking granularity
The smaller you partition the tasks, the finer the granularity of the tracking process. You really need to consider this, as it determines the cycle of your project tracking.
However, as you break down tasks into smaller tasks you need to consider the guidelines presented in the following sections.
The Risk of the Project or Task
Clearly, the higher the risk of the project, the smaller you should partition the tasks. The justification for this guideline is fairly obvious. The higher the risk of the project, the more likely it will be subject to variances in requirements, scope creep, unexpected problems, and estimation errors. By partitioning into smaller tasks, you increase the tracking granularity and this should give you greater control. You can apply the same guideline to tasks, as some tasks are higher risks than others.
The Nature of the Task
There are some tasks for which breaking into smaller units simply doesn't make any sense. For example, at one of our clients , some un-informed managers attempted to break project tasks into deliverables of half an hour . This resulted in some bizarre situations. In undertaking the systems analysis of some complex business processes, the natural cycle was to examine each business process in turn. On average, the modeling of the process and the related business rules involved a minimum of 5 days' work and more than 10 days in some cases. The systems analysts were forced to create "abstract" deliverables of half an hour in duration. We finally suggested that they report in the form:
It made the point and the system was abandoned with significant embarrassment to the managers.
The Experience of the Team Members
The more experienced the team members, the higher you should make the level of partitioning. For example, for a new and inexperienced team you might want to partition the tasks into the smallest units you can. The more experienced the team, the larger and longer you can leave the tasks. For an experienced team, you could leave the tasks at up to three months in duration and expect that the team would partition the three-month task at their own discretion.
The Degree of Trust
The more you trust your team, the higher you can leave the partitioning. By breaking tasks into about five days in duration, you are giving a hidden message to the team that you will be "checking up" on them regularly. You need to examine the different messages, relating to trust, between leaving a team with 15-day tasks rather than 5-day tasks.
To summarize, it is difficult to give simple rules when partitioning tasks into smaller tasks. You'll have to use your judgment here and hopefully the preceding guidelines will help you here.