Defining Project Activities

Defining Project Activities

Planning is the act of determining what needs to be done when. The simplest plan is, ''We will have the project finished by August 31." Unfortunately, unless the total effort is no more than a few days' work, such a "plan" is doomed because until the completion date, there is no way to tell whether or not the project is on track.

The purpose of planning is to permit you to run the projectto take whatever actions are needed to ensure that it will complete on time and within budget. Planning has no other purpose or intrinsic value. Once the project is complete, the plan's job is done. Other than for project review or to guide future planning, it may be discarded.

To track progress, the project must be broken down into small, manageable activities. The piecemeal approach is simply to begin listing activities and hope that the ones you miss don't sink you. There is an alternative, a systematic approach known as hierarchical decomposition.

Decomposition is the process of breaking down an activity into smaller chunks. Hierarchical means that the decomposition proceeds top-down by defining the major components of the project, then breaking each component into smaller pieces. The process continues through successively lower levels until the activities are "small enough." With some practice, this top-down approach ensures that all activities will be identified. The result is the work breakdown structure (WBS).

The Work Breakdown Structure (WBS)

A WBS is a list of all project activities, arranged hierarchically in levels. It also includes costs, such as equipment purchases, travel,

Numbering a Work Breakdown Structure

Since a WBS is hierarchical, its elements can be numbered in levels, as illustrated in Exhibit 4.12. For example, number 10.20.15 is an element at the third level.

One of the major uses for WBS numbers is time reporting. Team members will complete time sheets charging their time to specific activities identified by WBS number. The number will also be used to identify activities in the schedule as well as costs in the budget. Once the project has started to gather statistics by activity, the activities cannot easily be renumbered, so it is wise to use a number scheme that allows new activities or costs to be inserted.

Do not number the WBS until it is relatively stable and will not need to be renumbered. That is, number it when corporate management and senior technical staff have reviewed it and you are satisfied that there will be few changes. Otherwise, you will have to undergo the frustration of manually renumbering the activities and ensuring that they are consistent wherever they have been used.

Components of a Work Breakdown Structure

At the lowest level, a WBS consists of three types of components: work activities, distributed activities, and costs.

Work activities are those that contribute to a clearly defined deliverable, such as a report, a specification, or program code. An activity that does not actually produce a deliverable is still a work activity if its output will be used by other activities that do produce deliverables.

Distributed activities are those that do not directly produce deliverables, but are required of project team members throughout the project. Examples are project team meetings and internal walkthroughs and reviews. They are called "distributed" because effort spent on them is distributed over the entire project.

A special type of distributed activity is overhead, such as project management, quality control, or support services. This is normally associated with a small group of people, such as the project manager or quality control manager.

Cost components are costs that are not directly incurred by work activities. Examples are materials, hardware or software purchasing costs, and travel and living expenses. Staff costs for doing the work are associated directly with the activities that incur them. Hence, the purchase of a testing tool for $10,000 is a cost component, whereas the effort to evaluate testing tools is a work activity. If that work activity requires 40 hours by one $50 per hour analyst, it will cost the project $2,000.

Some work may be treated as either a work activity or a distributed activity. For example, since a code walkthrough contributes to the code deliverable, it may be treated as a work activity. On the other hand, it is easier to treat walkthroughs as a distributed activity than to plan individual walkthroughs for each deliverable. Whether walkthroughs are treated as work activities or as a single distributed activity will depend upon your preferences, the methodology, and the client. However, where you have a choice, keep things simple. Use a distributed activity for walkthroughs and reviews.

Preparing a Work Breakdown Structure

The first step in preparing a project WBS is to identify the major sets of activities. Consider a typical systems development project that also requires selection of hardware or software. Exhibit 4.13 gives one possible list of major activities.

These major activities correspond to the highest-level activities on the WBS given in Exhibit 4.12.

Once the major activities have been defined, break each one down further. For example, activities to select and acquire hardware or software can be broken down into selection activities and acquisition activities, and each of these can be further broken down into lower-level activities or costs.

Activity Independence

To the extent possible, activities should be independent of one another. That is, each activity should be done with as little knowledge of the other activities as possible. For example, common areas between programs should be designed separately from the program rather than as part of them. Designing them separately means that programmers can work independently without the need to constantly consult others. If any programmer needs changes to the common area, the requirement will be given to the person responsible for maintaining that area. That person will make the changes and inform any other programmers who are affected.

Designing activities to be independent has three main advantages:

1. Staff can be more readily transferred among activities. If some people finish their activities in advance while others fall behind, those who finish first can be reassigned to more critical activities.

2. It is more feasible to add staff if the schedule slips. If activities are independent and can be done with a minimum of knowledge about other activities, it is easier to add new staff than if activities are tightly interwoven.

3. The need for communication across activities is reduced. That results in less confusion, fewer opportunities for misunderstandings, and a smoother project.

When Activities Are Small Enough

One problem with any decomposition is knowing when to stop. Obviously, activities can be broken into levels of detail so fine that each hour of each team member's day for the duration of the project is planned. Just as obviously, such a plan will be obsolete by the end of the first day.

However, if knowing when to stop is difficult, setting criteria for stopping is even trickier. For example:

Some authorities have suggested that activities should not exceed some given duration, such as two weeks, and that all longer activities should be further decomposed. But if a single activity, such as coding a complex program, will take one person five weeks, there is no merit in arbitrarily cutting it into smaller chunks.

Some have suggested that an activity should produce a deliverable and that once all deliverables are covered, the decomposition is complete. But this criterion raises the question of what a deliverable is. Those that are contractual requirements may be too extensivefor example, "program code to execute the inventory system"to be easily managed. Good project managers will break such deliverables into smaller internal products, thus shifting the question of when to stop decomposing activities to one of when to stop decomposing deliverables.

Some have proposed that an activity should be conducted by one person only and that activities requiring more than one person should be further decomposed. But activities such as integration or systems testing typically require the participation of several team members, and the plan must reflect those requirements.

These difficulties illustrate the fact that planning is a process that requires judgment; there are no fixed rules. In deciding whether or not to further decompose an activity, your sole consideration must be whether or not the activity is large, complex, or unwieldy enough to require further breakdown. In other words, an activity is "small enough" when you are satisfied that it is manageable.

However, some may argue, there are activities that consist of a series of smaller steps. For example, installing a new computer requires loading the operating system, communication software, performance monitors, security software, compilers, database engines, and other components. Should you not list each one to be sure that nothing gets missed? Yes, you should, but not as separate activities;

if you list them separately, your WBS will become unmanageable and it will be impossible to record time accurately against such minuscule pieces of work. The best way to handle these tasks is to use the notes facility of your project management software. This allows you to attach free-form notes to any activity on the plan. To handle tasks associated with installing a new computer, create an activity called "Install software components." Then, in the notes section for the activity, list each of the components. In this way, when you are tracking progress, you can review the list to make sure everything was done, but the actual number of activities against which your people will record their time will be vastly reduced.

Decomposition is subjective. Not only will it depend on the project manager, but the same project manager will decompose differently depending on the experience of members of the project team and their track record of timely delivery.

Occasionally, your judgment may be overridden by methodology or standards. In such cases, the methodology imposes additional work on the project. You must factor it into the schedule and budget.

Project Phases

Frequently, you cannot complete a WBS because you do not know how the bulk of the project will be carried out. For example, if the project includes a build versus buy analysis, you cannot describe the implementation activities because you do not know whether you will be developing a new system or implementing a package. Or, you cannot plan construction activities because you do not yet understand the complexities of the project. In such cases, you do not know how you will handle the project, and all you can say is, "We need to do some analysis before we will know how to proceed. That analysis will be complete by . ." In other words, you separate the project into phases.

The first phase is usually an analysis in which you assess build versus buy, develop requirements, define scope, or conduct any activities that will allow you to identify clearly your approach and activities for the main project. In such cases, you can build a detailed WBS for the analysis phase and a skeleton for the rest of the project.

One of the deliverables from the analysis will be a detailed project plan.

Documenting the Activities

Once the WBS is complete, describe the activities. Exhibit 4.14 gives a sample description.

The written description serves two purposes: It gives an overview of the activity for those who will be carrying it out, and it ensures that no activities have been missed. Your key tool for the latter is activity inputs and outputs.

All activities have inputs, which are usually documents or code. All inputs must be either external to the project or provided by some other activity within it. Similarly, all activities have outputs, also usually documents or code. All outputs must be project deliverables or inputs to other activities.

One of the deliverables from the analysis will be a detailed project plan.

Documenting the Activities

Once the WBS is complete, describe the activities. Exhibit 4.14 gives a sample description.

The written description serves two purposes: It gives an overview of the activity for those who will be carrying it out, and it ensures that no activities have been missed. Your key tool for the latter is activity inputs and outputs.

All activities have inputs, which are usually documents or code. All inputs must be either external to the project or provided by some other activity within it. Similarly, all activities have outputs, also usually documents or code. All outputs must be project deliverables or inputs to other activities.

technical staff give you conflicting advice, you will not be able to develop a WBS that is accurate. As a result, you may build a plan that will not reflect how the project will actually be carried out.

Actions

Bring the technical people together and ask them to develop a plan for completing the major activity. Outline your understanding of their different approaches and tell them that you need an agreement.

If they fail to reach agreement, seek the advice of a third party to help you decide which approach to use.

Assess the arguments of your technical staff, pick the approach that makes the most sense and that best fits your experience, and impose that approach on the project.