Develop Project Task Lists

Although this planning step is often considered a no-brainer, ^[2] 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.

^[2] Remember our concerns with the concept of "no brains ."

Figure 13.1. Developing a task list

The process of developing a task list for your project is fairly straightforward:

• If your organization has a standard work breakdown structure, project development cycle, or methodology, you use that as a starting point.

• If not, you brainstorm the tasks required for your project using your technical team members , business and support experts, and stakeholders.

• If you have a methodology, you still need to fine-tune your methodology by brainstorming any new tasks (i.e., any that are not in your standard methodology) and any standard tasks that you can delete for your project's task lists.

• Review your task list with as many experts as possible.

• Repeat the process, breaking up the tasks into smaller subtasks (work breakdown).

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 . ^[3] 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.

^[3] Kroberg and Bagnall's book was originally written for architectural students.

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. ^[4] In fact, any book on a new technique such as object orientation or visual development tools will give you the basis for a methodology.

^[4] Christopher Myers (1993) is a good source for basic task lists for business projects.

Don't Get Too Linear

A good tip here is to avoid the sequencing or scheduling of tasks while you are brainstorming task lists. You can schedule or sequence the tasks later in scheduling the planning process. Too much focus on sequence of tasks can get you into linear thinking that often limits the flow of the brainstorm. Let the creative juices flow when you are listing tasks and don't eliminate tasks too quickly.

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

Take a Breather

Once you have developed your task list, take a break. Have a coffee or, better still, do something completely different, such as walking outside and listening to some Megadeth or Mahler (both are good for getting in the project mood). After the break, go back to your task list and you'll find some new tasks. Remember, you can't be too careful here ”double-check and re- double-check .

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.

Don't Switch off Your Brain

Every time someone chants a mantra such as "All tasks must be 5 days. No more. No less," ask them, "Why?" You'll often be amazed by the answer. Typically it will be a variation on "I don't know. I think someone told me years ago."

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.

Don't Become a Nag

If you agree with a team member that the task will take 10 elapsed days, don't check everyday how he or she is going. Just think how you would feel if your manager was "nagging" you every day. Trust the person. You can't do much else when you really think about it.

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:

Reporting time: 9:00 “9:30 am	Deliverable : Half a thought
Reporting time: 9:30 “10:00 am	Deliverable: Rest of the thought

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.

If you can't trust your team, get one you can.

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.