Chapter 34: Defining Activities

In the previous chapter, we saw that the activity list is an important part of defining the project schedule. But first, we have to prepare one so that we can use it to prepare the schedule, isnt it? In this chapter, we are going to learn just that.

So, lets get started!!!

Defining Activities:

Activities that need to be performed to produce the project deliverables are identified using the activity definition process. To understand it better, look at the picture below:

Let us look at the 3 parts of it in detail.

Input to Defining Activities

Identifying project activities starts with the work packages in the WBS, which in turn are derived from the project scope statement. The input items are:

Elements of the scope baseline, such as deliverables, assumptions, and constraints, will be useful in defining activities.

All the following three components of the project scope statement are needed to define activities:

• WBS and WBS dictionary - The work packages in the WBS are decomposed into project activities. To define activities in detail so that you can assign appropriate resources to them, you need the details about work packages, which are provided in the WBS dictionary.
• Project scope statement - The WBS is built from the project scope statement. While dealing with the WBS, you might need to go back to the project scope statement. The following elements of the project scope statement are especially important to consider while identifying activities:
     o Assumptions related to the activities or schedule planning, such as work hours per week
     o Constraints that will limit the schedule options, such as predetermined deadlines on project milestones
     o Project deliverables, to ensure that everything is covered in WBS work packages
• Enterprise environmental factors - The enterprise environmental factors relevant to identifying schedule activities include project management information systems and project scheduling software tools.
• Organizational process assets - Following are examples of organizational process assets that can be useful in the process of identifying activities:
     o Organizational policies related to activity planning
     o Organizational procedures and guidelines used in defining activities
     o Knowledge base of lessons learned from previous projects regarding activity lists
So, the major input to the activity definition process is the WBS, whose work packages are decomposed into activities using some tools and techniques.

Tools and Techniques for Defining Activities

The major task in the Define Activities process is to decompose the work packages in the WBS into activities.

Decomposition

Do you remember that we used the decomposition technique to create the WBS by subdividing the project deliverables into smaller manageable tasks called work packages. Decomposition is also used in the activity definition process for subdividing the work packages into smaller, more manageable components called schedule activities.

Component planning

If there are areas of the project scope for which sufficient information is not available yet, there will definitely be corresponding components in the WBS that are not decomposed to the level of work packages. You can only develop a high-level schedule for these planning components. You accommodate this kind of high-level scheduling by using a technique called rolling wave planning to plan the project work at various levels of detail depending upon the availability of information. Work to be performed in the near future is planned to the low level of the WBS, whereas work to be performed far into the future can be planned at the relatively high level of the WBS. So, a WBS component at the bottom level of a branch of WBS hierarchy for which some planning can be performed is called a planning component.

Templates

As a timesaver and a guide, you can use a standard activity list or an activity list from a previous project similar to the project at hand as a template. The template can also contain information about the activities in it, such as required hours of effort.

Expert judgment

Activities make the core of a project. So, it’s very important to identify and define them correctly to make the project schedule efficient and effective. Therefore, expert judgment is a very important tool that can be used in this process.

Output of Defining Activities

The key output item of the activity definition process is a comprehensive list of all the schedule activities that need to be performed to produce the project deliverables. The list of output items of this stage are:

Activity list

This is a list of all the activities that are necessary and sufficient to produce the project deliverables. In other words, these activities are derived from the WBS and hence are within the scope of the project. Also, the scope of each schedule activity should be described to sufficient detail in concrete terms, so that the team member responsible for it will understand what needs to be done.

Activity attributes

These attributes are in addition to the scope description of the activity in the activity list.
The list of attributes of an activity are:

• Activity identifier and code
• Activity description
• Assumptions and constraints related to this activity, such as target date
• Predecessor and successor activities
• Resource requirements
• Team member responsible for performing the work and information about the work; for example, where it will be performed

Some attributes evolve over time. The attributes are used to arrange the activities in the correct order (sequencing) and to schedule them.

Milestone list

A schedule milestone is a significant event in the project schedule, such as the completion of a major deliverable. A milestone can be mandatory, such as one required by a contract, or optional, such as one determined by the team to run the project more smoothly. The milestone list includes all the milestones and specifies whether a milestone is mandatory or optional. Milestones are used in building the schedule.

Trivia:
The Define Activities process generates the final output as activities and not deliverables. Therefore, ideally speaking, the WBS and the WBS dictionary should be generated before defining activities. However, practically speaking, the activity list, the WBS, and the WBS dictionary can be developed concurrently.

To wrap up this chapter, the output items of the activity definition process are a schedule activity list, a list of attributes for each activity, and a list of milestones. Before you can schedule them, the identified activities need to be arranged in the correct order, which is called sequencing – this is what we will be learning in the next chapter.

Previous: Introduction to Project Schedule

Next: Sequencing Activities

Chapter 31: Creating a Work Breakdown Structure (WBS)

In the previous chapter, we saw how to create the Project Scope Document. The next step in planning for a projects scope is to create the Work Breakdown Structure or WBS. This is what we are going to look in this chapter.

So, lets get started!!!

What is WBS?

WBS stands for Work Breakdown Structure. It is something that helps breakdown the whole projects scope into smaller and more manageable pieces. This is also a very important process in project management. To be able to actually execute the project, the project scope is broken down into manageable tasks by creating a work breakdown structure (WBS). In other words, a WBS is a deliverable-oriented hierarchy of the work that must be performed to accomplish the objectives of and create the deliverables for the project.

How to create the WBS?

Just like other documents related to project planning & management, the WBS is created using a set of inputs, by applying a set of tools & techniques to create the WBS. The picture below is a high level summary of how the WBS is created.

The project scope statement contains the list of deliverables and the product description. The requirements documentation describes the product and project requirements. Information in these two items provides the basis for creating the WBS. You should always consider organizational process assets while going through this and several other processes. In this case, the organizational policies and procedure related to creating the WBS, as well as relevant project files and lessons learned from previous projects, are some examples of organizational process assets that can be helpful.

Furthermore, even though each project is unique, there are similarities among sets of projects in an organization. These similarities can be used to prepare templates that will be used as a starting point for the WBS, to avoid the duplication of work. With or without templates, you will need to go through breaking down the deliverables, a very important step in creating the WBS.

Decomposition

Decomposition is a technique used for subdividing the project deliverables into smaller, manageable tasks called work packages. The WBS is a hierarchical structure with work packages at the lowest level of each branch. Based on their complexity, different deliverables can have different levels of decomposition.

To understand Decomposition better, let us take a look at an example WBS of a Website Development Project

In any WBS – the lines are called “Branches” and the boxes are called “Nodes”. For practical understanding purposes, each of these nodes can be considered as one manageable piece of work.

As you can see, we have decomposed the whole project work into 3 parts:
1. User Interfaces
2. Server &
3. Database

Each of these parts is further divided into more nodes which carry out a specific function that is part of the higher level activity.

How do you decompose a Project Work?

You can decompose the project work by executing the following steps:

1. Identify the deliverables and the work involved by analyzing the project scope statement and the requirements documentation.
2. Understand the relationships among the deliverables.
3. Structure and organize the first level (Server, UI and Db in our example) of the WBS hierarchy. Based on the project at hand, you can use one of the following approaches:
     o Use the deliverables as the components in the first level.
     o Use the phases of the project as the components in the first level.
     o Use the subprojects as components in the first level. A subproject is a part of the project that is independent enough of the rest of the project that it can be performed by another project team. This approach is useful when you want to outsource parts of the project.
     o Use different approaches within each branch of the WBS, for example, a subproject and deliverables in the first level.
4. Decompose the upper level into more detailed components for the lower level.
5. Keep decomposing to lower levels until necessary and sufficient decomposition has been achieved.
6. Assign identification codes to the WBS components.

Trivia:
As the work is decomposed to lower levels of detail, work components become more concrete and manageable. However, you should avoid excessive decomposition, because it will lead to a large number of work packages, and it will not be possible to manage all of them effectively. In other words, excessive decomposition leads to inefficient use of management and other resources. Necessary and sufficient decomposition is the key.

During decomposition, the components are defined in terms of how the project work will actually be executed and controlled. You must verify the correctness of the decomposition at each level by verifying that the lower-level components are necessary and sufficient for the completion of the corresponding higher-level deliverables.

Trivia:
While using the technique of decomposition, remember a useful concept or trick: rolling wave planning. It’s a fancy term that refers to handling a deliverable or subproject that currently cannot be decomposed fully because you don’t know the details about it yet. For example, it is to be executed far into the future. You leave the decomposition of such a deliverable at a level allowed by the available information and wait for further decomposition until more information becomes available. Yes, you got it right. This is an example of progressive elaboration.
The WBS document is the key item of the Create WBS process, but there are some other output items as well.

Output of Creating WBS

The output of the Create WBS process consists of the following items:

Work breakdown structure

As explained earlier, the WBS is a deliverable-oriented hierarchical structure that decomposes the deliverables into the work that will be executed by the project team to create the planned deliverables and to accomplish the planned project objectives. The project manager creates this document with the help of the project team. Following are some important characteristics of the WBS:
• Control account - Remember that each node represents a deliverable or a component of it at certain level, and each deliverable will have scope, schedule, and cost attached to it. Some suitable nodes in the WBS are selected as management control points. At each of these control points, scope, schedule, and cost are integrated for the purposes of monitoring and controlling the performance. For example, the integrated scope, schedule, and actual cost at these points can be compared to the earned value to measure the project performance. Such management points are called control accounts. Each control account may have one or more work packages under it. Obviously, each work package must belong to only one account; otherwise, some factors, such as cost, will be double counted or counted multiple times. A WBS component that is below the control account, that has a well-defined work content but does not yet have a detailed schedule, is called a planning package.
• Code of account - Each component in the WBS hierarchy, including work packages, is assigned a unique identifier called a code of account identifier. These identifiers can then be used in estimating costs, scheduling, and assigning resources.
• Scope - The WBS embraces the full scope of the project. If a task is not included in the WBS, it will not be done as a part of the project.
• Step toward team building - Because the project manager creates the WBS with the help of the project team, it is also the beginning of the team-building process on the part of the project manager.
• Step toward scheduling - The WBS decomposes the project work into manageable pieces that can be assigned to individuals. This helps define the responsibilities for the team members and is the starting point for building the schedule.
• Reference for communication - Throughout the project, the WBS works as a reference for communication regarding what is included in the project and what is not.

WBS dictionary

This is a supporting document for the main WBS document to provide details about the components of the WBS. The details about a component might include elements such as a code of account identifier, description of work involved, quality requirements, acceptance criteria, a list of milestones schedule, cost estimates, required resources, contract information, and the organization or group responsible for this component.

Updates

During the create WBS process, the project team might realize that something out of the existing scope must be included in order to accomplish something in the scope. This will give rise to a change request, which might also come from other stakeholders during or after the first creation of the WBS. After the change request has been approved, not only the WBS will be changed—the scope statement must also be updated accordingly. The impact of the approved change request on the project scope management plan must be evaluated, and the plan must be updated accordingly.

Scope baseline

This is not a different item in and of itself. The scope statement, the WBS document, and the WBS dictionary combined constitute the scope baseline against which all the change requests will be evaluated.

Trivia:
Do not confuse the WBS with other information breakdown structures, such as the organizational breakdown structure (OBS), which provides a hierarchy of the performing organization and can be used to identify organizational units for assigning the WBS work packages. Remember, the end goal of the WBS is to specify the project scope in terms of work packages; this is what distinguishes the WBS from other information breakdown structures.

A Last Word:

You might be wondering who creates the WBS. Well, as expected, it is your responsibility, and you, the project manager have to create it with the help of your team.


Previous: Defining Project Scope

Next: Before & After the WBS