EXAMPLE: POOL PROJECT MECHANICS

To make the scope development process more visible, we will use a more familiar project example and illustrate how to organize the pieces into a formal schedule and budget. A pool construction project will be used to demonstrate this since everyone has a general familiarity of the component parts of a home swimming pool. Since this is a mature and relatively small project, it is possible to elaborate the whole activity set and not have to deal with the complex interplay of defining what these might be. We will also assume that the WBS structure only requires one layer to sufficiently describe the work. As in previous examples, the goal here is to simplify the explanation before opening Pandora’s box of complexity later. The sample pool project is envisioned in Table 8.1 to include 11 activities.

In this case, the 11 activities would be equivalent to WPs, since the project is relatively small and there is no need for an intermediate decomposition of activities. So, we can represent this project schematically in WBS format as shown in Figure 8.4.

With this example it is time to introduce the concept of WBS labeling in regard to the overall structure. In this case, the top label is “1” and the subordinate WPs or activities would be reflected by the decimal notation. So, excavation is 1.1, install electrical is 1.4, and so on. In this case, the work unit label numbers range from 1.1 to 1.11. Note also that the total pool duration and cost is a summation of the work units at the level below. This shows that the project would require 37 work days and a direct cost of $53,500. In other words, all direct costs for the project are contained in the subordinate WPs. In this fashion, the WBS defines the scope of the effort. All work would be shown here and if

Table 8.1 Pool Project Work Activities

WBS activity Duration (d) Cost ($)

1.1 Excavation 5 6000.00

1.2 Reinforcing structure 3 5900.00

1.3 Install piping 4 3800.00

1.4 Install electrical 3 3900.00

1.5 Blow pool concrete shell 5 13,500.00

1.6 Install decking 5 6000.00

1.7 Install pumps and blowers 4 4200.00

1.8 Install filtration system 2 3600.00

1.9 Install landscaping 5 6000.00

1.10 Checkout system 1 600.00

not, it is not in the project scope. There are some additional idiosyncrasies to this idea, but this is good enough for our introductory example. From this point, we can begin the translation of scope into a project schedule. In order to do this, we need to define the following five data elements for each of the 11 WPs:

1. Activity name

2. Activity ID (WBS code)

3. Duration estimate for the activity

4. Cost estimate for the activity (from resources allocated plus material costs) 5. Predecessor links to other activities

The only new idea on this list is the recognition that sequence relationships for work units need to be defined. This is called predecessor relationships. Basically, the values shown in this column simply relate to how the various activities link to each other. For example, a “3” indicates that the activity links to activity number 3. To illustrate this process, we restate the 11 pool project activities and complete the defini- tion for the five scheduling attributes. This yields a project activity definition listing as shown in Table 8.2.

An explanation of the role and meaning of each column is summarized as follows:

Number: A sequential line number for each activity. This is used to identify pre-

decessor links.

WBS: This is the code described above and is a WP reference used in various places

throughout the project.

1 Pool project 1.1 Excavation 37 d 5 d $6000.00 1.2 Reinforcing structure 3 d $5900.00 1.3 Install piping 4 d $3800.00 1.4 Install electrical 3 d $3900.00 1.9 Install landscaping 5 d $6000.00 1.10 Checkout system 1 d $600.00 1.11 Final approval 0 d $0.00 1.5 Blow pool concrete

shell 5 d $13,500.00

1.8 Install filtration system 2 d $3600.00 1.7 Install pumps and

blowers 4 d $4200.00 1.6 Install decking

5 d $6000.00 $53,500.00

Quick Start Example • 77

Activity/task name: This is the short name used to describe the activity. Longer

names will be defined elsewhere and linked here through the WBS ID code number.

Duration: As indicated earlier, this value is the estimated total activity working

time, given an assumed staffing level. A zero duration signifies a milestone or review point.

Cost: This value is derived from the sum of resource costs and other materials

required for the WP.

Predecessor: This code is used to link one activity to another. Note in Table 8.2

that activity number 5 cannot be started until activity number 3 is completed. Activity number 7 shows that it cannot be started until activity number 6 is completed plus 5 extra work days. This is called a lag relationship.

There are other predecessor relationship coding options that we will review later, but they are simply modifications of the ideas represented here. From a structural model view, all projects would use this same set of variables to produce a time schedule. The WBSs would be larger and have more layers and the predecessor relationships would be more complex, but the mechanics would stay the same.

Basically, the precedence linking relationships are used to establish the technical sequence for executing the project and this requires expertise in the technology of the project. In some cases, the technical sequence specifications are obvious in that holes must be dug before the reinforcing structure is done; however, in some situations the sequencing may be done to optimize utilization of the team, or because it is rainy out- side and the inside activities can be worked on. Regardless of the linking logic, the role of predecessor relationships is to drive the activities through the desired sequence, which in turn translates the work into a schedule.

To show that we are making some visible progress toward developing a schedule, let us translate this same data into Microsoft Project (see Figure 8.5). Note that Microsoft Project understands the terms outlined above and is able to manipulate them according to its internal rules. The display shown here translates the planning items into a Gantt

bar chart project schedule. This format is a common one used to show schedules. Some

data such as the attached calendar schedule have been hidden for this example, but they

Table 8.2 Pool Project with Precedence Relationships Defined

No. WBS activity/task Duration (d) Cost ($) Predecessor

1 1 Pool Project 37

2 1.1 Excavation 5 6000.00

3 1.2 Reinforcing structure 3 5900.00 2

4 1.3 Install piping 4 3800.00 3

5 1.4 Install electrical 3 3900.00 3

6 1.5 Blow pool concrete shell 5 13,500.00 5, 4

7 1.6 Install decking 5 6000.00 6FS + 5d

8 1.7 Install pumps and blower 4 4200.00 7

9 1.8 Install filtration system 2 3600.00 7

10 1.9 Install landscaping 5 6000.00 9, 8

11 1.10 Checkout system 1 600.00 10

are readily available within the software. This diagram describes the sequence of work from the starting point through completion.

It is important to recognize that once the five basic WP size and sequence parameters are defined, the process of generating a project plan is essentially mechanical and can be handled by software. If we can assume for the moment that the planning WP dura- tion and cost estimates are valid, this process would yield a predictive schedule for the effort. However, before starting to feel too good about this nice looking plan, remem- ber that Murphy’s law says that things will go wrong and at the most inopportune time. Nevertheless, this set of mechanics is an important project management step and these planning artifacts are useful tools to verify scope and plans among the various project stakeholders. Likewise, the artifacts created to this point are all useful in communicating project vision and intent.

Status tracking: After a project is approved by management as to scope, schedule, and

budget, the next and more complex problem is to keep it under control. Status tracking is a basic management activity that supports the monitoring and control process. There are three common project status questions that will need to be answered as a project unfolds. First, what was the initially approved project plan? Second, what is the current plan and how does it relate to that original plan? Finally, what are the forecast comple- tion parameters for the project—generally defined by time and cost, but should also include other technical specifications?

Too often, project plans are updated weekly or monthly to show the current status view without regard for the original plan. It is a common omission for project teams to want to disregard the original planned values because keeping them visible would reveal how poorly the project has progressed to date. Another common view of status tracking is that there is none. The original plan is posted on the wall and not changed or monitored. Worse yet, it might be changed regularly with no recognition that this was not the intended plan. Good project management will monitor the ongoing status of the project as compared to the approved plan. Moreover, it will make periodic assessments of forecast completion status. The operational philosophy is that status communica- tion must honestly reveal three status situations—original approved plan, current view, and future forecast. And it must do this in near-real time—that typically means weekly or monthly cycles as limited by the availability of actual tracking data from internal systems. There are many techniques to aid in this process but the most important step, regardless of the method, is to obtain initial scope approval from key stakeholders and then gain appropriate management approval for that plan. This process attempts to clearly define time, cost, and scope parameters for the project. Once that is done, the project is ready to move into the execution phase (Note: we are still ignoring some other

Quick Start Example • 79

planning activities such as risk assessment at this point). The final planning step then is to freeze the approved values for use in future status comparisons. This set of values represents the original baseline or baseline.