Chapter 2— Project Planning

The author has described project management in a number of papers, talks, and classes during the past twenty years.

Two of these papers summarized the methods of project management. The first, titled Project

Management Systems, appeared in the Journal of Information and Management. The next, titled Managing Software Development Projects for Maximum Productivity, appeared in Transactions on Software Engineering. The later paper was republished in 1988 in the book Software Engineering Project Management, edited by Richard Thayer. The first paper deals with project management methods in general, while the second, which is somewhat more detailed, deals with project management for software development projects.

Those papers introduced a decomposition of project management into two separate but related parts: project planning and project execution. Each of these parts consists of five activities. Project planning consists of:

1. Subdivision of work

2. Quantification

3. Sequencing of work

4. Budgeting

5. Scheduling

Project execution consists of:

1. Cost accounting

2. Progress measurement

3. Variance tracking and change control

4. Performance evaluation

5. Productivity measurement

In this chapter we devote considerable space to explaining the activities of project planning and how to use the desktop computer tools provided with this book to do project planning. In later chapters we discuss project execution, which in a way is the easier part, and how to use these desktop tools for project control.

In this chapter, a concise definition or description of each of the five activities of project planning is given. Also included is a discussion of the rationale for these activities, presented within the framework of business practices. These practices have proven essential in the consistent application of the methods of modern project management and in the establishing of credibility between a project manager and the project manager's client(s). They exist to ensure that the project management team understands the client's objectives, their responsibilities, and the need for consistent and continuing planning and control. Furthermore, their consistent application ensures that the results of the methods embodied in the practices are repeatable.

2.1— Subdivision of the Work

The essential idea behind project planning is the subdivision of the work into manageable pieces. These pieces are called work packages. For this reason, subdivision of the work is often referred to as "packaging the work." Work packages are elements of work that are small enough that the

responsibility for performing them can be assigned to a single individual. This does not mean that individual actually performs all the work of the work package. Indeed, the person responsible for a work package may be a manager who assigns the work to others. But the fact that each work package has a single individual who hasperformance responsibility is a fundamental concept in project management.

Each work package is individually estimated and scheduled. Specifically how this is done is

explained later in this chapter. In this section it suffices to assume that since the work packages are conceptually "small," it is always possible to easily estimate accurately how much time and money it will take to complete each work package. Another useful assumption, which needs to be enforced as a policy, is that each work package is of short duration. Projects always have reporting periods. The

reporting period may be a week or a month or any other convenient time period that is useful for a specific project. At the end of each reporting period, the status of each active work package is reported, together with the actual cost and labor-hours expended to date on the package. The assumption that a work package is of short duration means that it spans at most a few reporting periods.

The total cost of the project at any point in time and the status of the project are derived from the expenditure and status information for each work package. Specifically how this is done is explained in Chapter 3. The subdivision of the work is important in project management because it facilitates the management of the work, it facilitates the estimation of the amount and cost of the work, and it provides a means for calculating the cost and status of the project at any point in time. There is a specific method for arriving at what the work packages should be. Rather than dividing the work into the individual tasks that will appear in the project schedule and later gathering the tasks together into packages as advocated by some, we prefer to proceed in a "top-down" fashion. This top-down approach reflects the way the overall work will proceed. Usually, there is a specific way the work is conducted on a project. For example, if the project consists of building a ten-story building, one would not expect to begin building the tenth story first, before the foundation was laid and the lower nine stories were constructed.

In order to facilitate our thinking about project management, we now introduce an example project that has been devised to be extremely simple. We will use this example project in what follows to explain project management concepts and how to use the project management tools furnished with this book. This example project is not intended to be entirely realistic; rather, it was designed to be simple, yet realistic enough to be useful. The example project is to build a small, 5,000 square-foot building.

In order to build this building, it will be necessary first to construct a foundation, then to build the structure, and finally to install the plumbing system, the electrical system, and the heating and airconditioning system. Consequently, we first subdivide the project into three subcomponents that we will call the foundation component, the structure component, and the systems component. In fact, we introduce some new terminology here for distinguishing the components of our subdivision. We call these components control packages, as opposed to work packages. The reason for this is that they are too large to be work packages; yet they are meaningful components both conceptually and, later, for project control. So we will have control packages that we will refer to as "Foundation," "Structure," and "Systems." We can represent this hierarchically as shown in Figure 2-1.

Figure 2-1.

Subdivision of example project into control packages.

Notice that the hierarchy positions of these control packages are labeled 1, 2, and 3. Notice also that we are treating the whole project as a control package, which is at hierarchy position " 0." We have given a name to the "top-level" or total project control package, namely "Example Project." It is customary to label control packages this way.

Next we subdivide these control packages further. For example, we subdivide the Foundation

control package into four new packages that we label 1.1, 1.2, 1.3, and 1.4. This is the same way that sections in a document are often labeled. These labels are called the package identifiers or package IDs. They are used to show how the work content unfolds in much the same way that sections in a book show how the content of the book unfolds. Continuing our subdivision of these control packages, we subdivide control package 1 (Foundation) into these packages:

1.1 Site Preparation

1.2 Forms Installation & Removal

1.3 Rebar, Mesh, & Anchors

1.4 Concrete Pour, Cure, & Finish

Similarly, we subdivide control package 2 into these packages:

2.1 Framing & Misc. Carpentry

2.2 Sheetrock Tape, Bed, & Float

2.3 Roofing

2.4 Painting

And we subdivide control package 3 into these packages:

3.1 Plumbing

3.2 Electrical

3.3 HVAC (Heating, Ventilation, and Air-conditioning)

This finer decomposition of the work content is shown in Figure 2-2. For the purpose of keeping the example small, weassume that we have now decomposed the work far enough for the needs of project planning and control. In other words, we believe that these latest packages are small enough to be work packages. We could have had additional levels of control packages between the top-level control package and the work packages, but, for the sake of simplicity, the example project stops here. In what follows we will refer to any of these packages as control packages but to only the lowest-level packages (e.g., 1.1, 1.2, 1.3) as work packages. This structure of control packages we have just described for the example project is referred to as the Work Breakdown Structure or simply the WBS, for the project. The hierarchical diagram in Figure 2-2 represents the example WBS.

There are other meaningful subdivisions of the work besides the work breakdown structure.

Subdividing the work by discipline (craft) may be useful for supporting monthly labor reporting; for example, electrical or carpentry or masonry activities could be grouped together. It is often necessary to have the work subdivided by organizational structure (e.g., by division, department, or section). These organizational subdivisions are so common that they are often giventhe name Organizational Breakdown Structure or OBS.

It is also standard practice to subdivide the work by cost codes to support cost accounting and by general ledger codes to support general accounting or tax form preparation. Such subdivisions are often referred to as cost breakdown structures. Finally, in many industries, especially those that do business with the federal government, the work may need to be broken down along product lines, such as the various subsystems of an overall system (e.g., the avionics subsystem and the flight control system of an aircraft). Such subdivisions are referred to as product breakdown structures. The military, as we see in Chapter 8, refers to these product breakdown structures as work breakdown structures.

Whatever the need for these additional subdivisions of work, it is important that they be related in a meaningful way to the WBS. In the example project we will consider three different subdivisions. In addition to the WBS, there will be a cost breakdown based on General Ledger (GL) codes and an organizational breakdown structure. The discussion in the following sections and chapters shows how these additional subdivisions are supported in the Modern Project toolset provided with this book.

The way we relate the cost breakdown structure to the WBS is explained in Section 2.5. The way we relate the OBS to the WBS is via a second (or alternate) hierarchy. This is explained in Chapter 6. The OBS hierarchy will have the same work packages as the WBS but different control packages above the work package level in the OBS hierarchy. The reason this is possible is because of our rule that work packages be small enough to be assigned to a single person. Since each person is a member of some section or department or division, the work packages assigned to a person in a given organizational unit will be considered to belong to the control package that represents this organizational unit in the OBS hierarchy diagram.

Figure 2-2.

WBS for example project.

There is one more thing that should be mentioned about the WBS. Even if a client requires that his or her WBS be a product breakdown structure or an OBS, our policy will still be to subdivide the work in the manner in which it is to be done and to utilize alternate reporting hierarchies to provide the client with his or her required reports. Subdividing the work in the manner that it will actually be accomplished provides project management and assisting departments with the best understanding of how to accomplish the project's objectives. The importance of subdividing the work in the way it will actually be performed cannot be overemphasized. If the WBS does not reflect the way in which the work will actually be done, the WBS is not really useful to the project manager as a communications and control mechanism.

alternate views of the project that are meaningful to different organizations. Each of these reporting hierarchies will possess the same set of work packages. They will differ only in the way the control packages above the work packages are organized. It should be noted that not all of these alternate reporting hierarchies will have the same number of levels. A WBS is often expected to have more levels than an OBS, but there can be exceptions to this rule. Finally, it should be noted that, even within the WBS, each branch of the WBS should not be expected to have the same number of levels. Some parts of the work may naturally be expected to be more complicated than other parts, and this may be reflected in the WBS by branches with unequal numbers of levels of control packages before work packages are encountered.

By accommodating multiple subdivisions of the work (e.g., the OBS) via multiple hierarchies, which collectively will be referred to as reporting hierarchies, these desktop tools allow a project to provide all the components of an organization with reports about the project that are meaningful for them. Essentially, these alternate reporting hierarchies provide

2.2— Quantification of the Work

The next step after subdividing the work is quantification of the work. Quantification of the work consists of assigning an appropriate unit of measure to each control package and then assigning a quantity to the work content of the package that quantifies the amount of work in the package in terms of its unit of measure. The way this is done requires some explanation. We first discuss how it is done for work packages. The work content of a work package is further subdivided into tasks or activities. The terms task and activity are interchangeable in this book. These individual tasks are the things that are eventually scheduled, usually with an automated scheduling software package. This produces a start date and an end date for each task. But this is not our concern at the moment. The important thing to understand just now is that each task needs to be assigned a unit of measure.

It is the responsibility of the work package manager to subdivide the work packages for which he or she is responsible into appropriate tasks. It is also this manager's responsibility to quantify and estimate these tasks. Suppose the work package manager for the ''Siteprep" work package, after careful consideration and perhaps consultation with those who will actually perform the work, decides to subdivide the work package into four tasks, say:

Task 1: Clear and Grub the Site

Task 2: Remove Excess Earth

Task 3: Grade the Site

Task 4: Excavate for a Foundation

The unit of measure for Task 1 might be "square feet," since the site that is to be prepared for the structure is likely to be measured in square feet. On the other hand, the unit of measure for Task 2 might be "cubic yards," since earthmovers usually estimate the amount of earth to be removed in cubic yards of earth. On the other hand, if the project is a computer software development project and the activity is to write a computer program, the unit of measure might be "source lines of code." If the activity is to write a chapter of a book, the unit of measure might be "pages." First-time project managers are often faced with the claim from some member of the project team to whom a task has been assigned that this type of work has never been done before and so there is no known unit of measure for this task. This often happens on research or development projects. While this is never really the case, it is often easier for the project manager to just assign this task the unit of measure called each (abbreviated "EA"), rather than argue about it. Then a quantity of 1 can be assigned to the task in the EA unit of measure. This means that this task is considered as a single unit.

The effect on the overall project of doing this occasionally is not usually great, since work packages are assumed to be of short duration and, therefore, so are tasks. But, as the reader will see in Chapter 3, assigning a unit of measure of EA will curtail the options for a work package manager to take partial credit for work in progress on the periodic status reports. This can cause the task leader to appear not to be making progress until the task is completed. This usually leads task leaders to wish they had taken time to quantify their tasks correctly in the first place. For the project manager, this is not a problem. Most project managers prefer a conservative approach for claiming credit for work in progress, anyway, and assigning a task a unit of measure of EA is extremely conservative. Task leaders do not get credit for any task until it is completely finished when the unit of measure is EA.

Some experienced project managers force this type of quantification uniformly on their project to maintain a conservative progress measurement policy. But we consider this an extreme measure that should be avoided. The reason is that better cost and manpower estimates can be made if the work packages are quantified meaningfully. An old saying among project managers and cost estimators is: "If the work can't be quantified, it can't be estimated." It is important for project team members to understand this and to do their best to produce a meaningful quantification.

After each task in a work package has been quantified, the work package itself needs to be

quantified. Again, the responsibility for the quantification of a work package rests with the work package manager. And again, quantification of a work package involves selecting an appropriate unit of measure for the package and an appropriate quantity for the package expressed in this unit of measure. Often, it is the case that the unit of measure for a work package is the same as the unit of measure for one of the tasks within the work package.

For instance, the Siteprep work package in the example project, as we will see in Section 2.3.3, has Tasks 1 and 3 with a unit of measure of Square Feet (SF) and Tasks 2 and 4 with a unit of measure of Cubic Yards (CY). We will also see in Section 2.3.3 that the unit of measure chosen for the Siteprep work package is SF, rather than CY or some other measure.

This reflects the belief of the work package manager that quantifying the Siteprep work package is best done via SF, as opposed to CY or some other measure. In a case like this, it is sometimes said that among the units of measure for the tasks, SF is the dominant unit of measure, since it determines the unit of measure for the package.

Unlike quantification of work packages, quantification of control packages above the work package level is the responsibility of the project manager. Quantification at this level does not affect the progress and performance measures that are based on the status information at the work package level. Nonetheless, it is important that the project manager or the project manager's staff select meaningful quantifications for the summary level control packages. This enables those reading reports to relate the progress measures at summary levels to something intuitively meaningful.

For instance, we will see in the WBS Listing report (Figure 2-6) that the unit of measure for the summary level "Foundation" control package is CY (of concrete). If a progress report shows this control package is 50% complete, the reader of the report can relate this to the 290 CY of concrete quantification for the package and envision that about 145 cubic yards of concrete has been poured so far.

2.3 Using Modern Project© to Create a WBS

Before moving on to a discussion of sequencing the work, we first cover how to enter a work

breakdown structure into the project database. A desktop toolset called Modern Project is included with this book. In order to run the tools provided in this toolset, it is necessary for you to have Microsoft Access 97, or a later version, such as Access 2000, installed on your computer. Modern Project is a learning aid intended to demonstrate how a set of desktop tools can support the project management techniques covered in this book. Modern Project has been tested on the example project described in the book but has not been subjected to exhaustive testing. Neither the author nor the publisher takes any responsibility for the correct operation of this toolset. It is intended to be useful on projects on which it is used, but the reader must understand that it is to be used at his or her own risk.

There is a file on the electronic media provided with the book that you need to copy to one of your disk drives. If you are using Access 97, then the file is the one named example97.mde. If you are using Access 2000, then the file is the one named example2K.mde. For simplicity, we will just use the filename example.mde in what follows instead of repeatedly distinguishing between the two. Example.mde is a database that will eventually contain the example project data that will be used throughout the book to illustrate project management concepts and the use of Modern ProjectAfter you have saved the file example.mde to your disk drive, you may need to change the read only attribute. For instance, if you use Microsoft Windows Explorer to copy the file from the CD to your disk drive, it will set the read only attribute to "true" since the CD supplied with the book is a read only medium. This will prevent you from entering any data into the example database until you change the read only attribute to "false."

To change the read only attribute to false, first open the file with Microsoft Access. A window should appear that looks like Figure 2-3. Now click on the File control button, and select the Database Properties option by clicking on the option's entry in the File menu that dropped down. This will cause the Properties window to appear. Make sure the Properties window is displaying the General (properties) with Attributes: showing at the bottom of the window. If not, click on the General tab at the top of the Properties window.

Now look at the "read only" attribute. If it has a checkmark in the box in front of it, click on the box to remove the checkmark. If there is no checkmark in the read only attribute box, there is nothing to change. Next, click on the OK control button at the bottom of the Properties window. You should now be able to write data into the example database. You will begin learning how to do this shortly.

If you do not have either Microsoft Access 97 or Microsoft Access 2000 installed on your computer, it should not interfere with your ability to understand the project management methods, philosophy, and tools discussed in this book. During the past three decades, many project managers have used these methods and policies manually, without the aid of a computer. On large projects this requires a considerable staff, but it has been done and continues to be done.

Packaged within example.mde is the Modern Project toolset. When you open example.mde with Microsoft Access the Main Menu for the Modern Project toolset will be displayed as shown in Figure 2-3. Assuming you have one of these versions of Microsoft Access available on your computer, start it up and open the example database (example.mde). Your computer screen should now look like Figure 2-3.