Introduction

PM Milestone Project Management Templates

PM Milestone Business Templates

Get Instant Access

In the last chapter, you learned about defining and managing the project's scope, i.e., j the work to be done in order to achieve the project's MOV or goal. Defining and understanding what you have to do is an important first step to determining how you're going to do the work that has to be done. In this chapter, we will focus on defining the tasks or activities that need to be carried out in order to complete all of the scope-related deliverables as promised. Moreover, we also need to estimate or forecast the amount of time each activity will take so that we can determine the overall project schedule.

The Project Management Body of Knowledge (PMBOK) area called project time management focuses on the processes necessary to develop the project schedule and to ensure that the project is completed on time. As defined in the PMBOK, project time management includes:

• Activity definition—identifying what activities must be completed in order to produce the project scope deliverables.

• Activity sequencing—determining whether activities can be completed sequentially or in parallel and any dependencies that may exist among them.

• Activity duration estimation—estimating the time to complete each activity.

• Schedule development—based upon the availability of resources, the activi ties, their sequence, and time estimates, a schedule for the entire budget can be developed.

• Schedule control—ensuring that proper processes and procedures are in place in order to control changes to the project schedule.

In this chapter, we will concentrate on two of these processes: activity definition and activity estimation. These are key processes that deserve special attention because they are required inputs for developing the project network model that will determine the project's schedule and budget. In the next chapter, you will see how we put this all together to develop the detailed project plan.

The remainder of this chapter will introduce several important tools, techniques, and concepts. A work breakdown structure (WBS) is discussed first. It provides a hierarchical structure that outlines the activities or work that needs to be done in order to complete the project scope. The WBS also provides a bridge or link between the project's scope and the detailed project plan that will be entered into a project management software package.

Today, most project management software packages are relatively inexpensive and rich in features. It is almost unthinkable that anyone would plan and manage a project without such a tool. Project success, however, will not be determined by one's familiarity with a project management software package or the ability to produce nice looking reports and graphs. It is the thought process that must be followed before using the tool that counts! Thinking carefully through the activities and their estimated durations first will make the use of a project management software package much more effective. You can still create nice looking reports and graphs, but you'll have more confidence in what those reports and graphs say.

Once the project activities are defined, the next step is to forecast, or estimate, how long each activity will take. Although a number of estimation methods and techniques are introduced here. Estimation is not an exact science. It is dependent upon a number of variables—the complexity of activity, the resources (i.e., people) assigned to complete the activity, and the tools and environment to support those individuals working on the activity (i.e., technology, facilities, etc.). Moreover, confidence in estimates will be lower early in the project because a full understanding of the problem or opportunity at hand is probably lacking. However, as we learn and uncover new information from our involvement in the project, our understanding of the project will increase as well. Although estimates may have to be revised periodically, we should gain more confidence in the updated schedule and budget. Even though no single estimation method will provide 100 percent accuracy all of the time, using one or a combination of methods is preferable to guessing.

THE WORK BREAKDOWN STRUCTURE (WBS)

In the last chapter, you learned how to define and manage the project's scope. As part of the scope definition process, several tools and techniques were introduced. For example, the deliverable definition table (DDT) and deliverable structure chart (DSC) identify the deliverables that must be provided by the project team.

Once the project's scope is defined, the next step is to define the activities or tasks the project team must do to fulfill the scope deliverable requirements. The work breakdown structure (WBS) is a useful tool for developing the project plan and links the project's scope to the schedule and budget. According to Gregory T. Haugan (2002),

The WBS represents a logical decomposition of the work to be performed and focuses on how the product, service, or result is naturally subdivided. It is an outline of what work is to be performed. (17)

The WBS provides a framework for developing a tactical plan to structure the project work. PMBOK originally defined the WBS as a "deliverable-oriented hierarchy," but much debate and confusion has existed as to what a WBS should look like and how one should be built. Recently, the Project Management Institute formed a committee to recommend standards for the WBS. That committee recommends that no arbitrary limits should be imposed because the WBS should be flexible. Subsequently, the WBS can be used in different ways depending on the needs of the project manager and team.

Work Packages

The WBS decomposes, or subdivides, the project into smaller components and more manageable units of work called work packages. Work packages provide a logical basis for defining the project activities and assigning resources to those activities so that all the project work is identified (Haugan 2002). A work package makes it possible to develop a project plan, schedule, and budget and then later monitor the project's progress.

Project

Phase

Deliverable t Activity/Task

Milestone—De I i vera hie completion Milestone—Phase completion Figure 6.1 Work Package

As illustrated in Figure 6.1, a work package may be viewed as a hierarchy that starts with the project itself. The project is then decomposed into phases, with each phase having one or more deliver-ables as defined in the deliverable definition table and deliverable structure chart. More specifically, each phase should provide at least one specific deliverable—that is, a tangible and verifiable piece of work. Subsequently, activities or tasks are identified in order to produce the project's deliverables.

Deliverables and Milestones

One departure from most traditional views of a WBS is the inclusion of milestones. A milestone is a significant event or achievement that provides evidence that that deliverable has been completed or that a phase is formally over.

Deliverables and milestones are closely related, but they are not the same thing. Deliverables can include such things as presentations or reports, plans, prototypes, and the final application system. A milestone, on the other hand, must focus on an achievement. For example, a deliverable may be a prototype of the user interface, but the milestone would be a stakeholder's formal acceptance of the user interface. Only the formal acceptance or approval of the user interface by the project sponsor would allow the project team to move on to the next phase of the project.

In theory, if a project team succeeds in meeting all of its scheduled milestones, then the project should finish as planned. Milestones also provide several other advantages. First, milestones can keep the project team focused. It is much easier to concentrate your attention and efforts on a series of smaller, short-term deliverables than on a single, much larger deliverable scheduled for completion well into the future. On the other hand, if milestones are realistic, they can motivate a project team if their attainment is viewed as a success. If meeting a milestone signifies an important event, then the team should take pleasure in these successes before gearing up for the next milestone.

Milestones also reduce the risk of a project. The passing of a milestone, especially a phase milestone, should provide an opportunity to review the progress of the project. Additional resources should be committed at the successful completion of each milestone, while appropriate plans and steps should be taken if the project cannot meet its milestones.

Milestones can also be used to reduce risk by acting as cruxes or proof of concepts. Many times a significant risk associated with IT projects is the dependency on new technology or unique applications of the technology. A crux can be the testing of an idea, concept, or technology that is critical to the project's success. For example, suppose that an organization is building a data warehouse using a particular vendor's relational database product for the first time. A crux for this project may be the collection of data from several different legacy systems, cleansing this data, and then making it available in the relational database management system. The team may ensure that this can be accomplished using only a small amount of test data. Once the project team solves this problem on a smaller scale, they have proof that the concept or technique for importing the data from several legacy systems into the data warehouse can be done successfully. This breakthrough can allow them to incorporate what they have learned on a much larger scale. Subsequently, solving this crux is a milestone that would encourage the organization to invest more time and resources to complete the project.

Milestones can also provide a mechanism for quality control. Continuing with our example, just providing the users with an interface does not guarantee that it will be acceptable to them. Therefore, the completion of user interface deliverable should end only with their acceptance; otherwise, the team will be forced to make revisions. In short, the deliverable must not only be done, but must be done right.

Developing the WBS

Developing the WBS may require several versions until everyone is comfortable and confident that all of the work activities have been included. It is also a good idea to involve those who will be doing the work—after all, they probably know what has to be done better than anyone else.

The WBS can be quite involved, depending upon the nature and size of the project. To illustrate the steps involved, let's continue with our electronic commerce project example from the last chapter. As you may recall, we created a DDT and DSC to define the scope of the project. To make things easier to follow, let's focus on only one portion of the project—creating a document called the test results report. Figure 6.2 provides the DSC that we developed in Chapter 5. As you can see, two deliver-ables—the test plan and test results report—are to be completed and delivered during the testing phase of the project.

The DSC defines the phases and deliverables for our project. The next step is to develop sets of work packages for each of the phases and deliverables. After a team meeting, let's say that we have identified and discussed several activities that we need to do in order to produce the test results document:

• Review the test plan with the client so that key stakeholders are clear as to what we will be testing, how we will conduct the tests, and when the tests

Deliverable Structure Chart
Figure 6.2 Deliverable Structure Chart (DSC) for EC Example

will be carried out. This review may be done as a courtesy or because we need specific support from the client's organization and, therefore, must inform them when that support will be required.

• After we have informed the client that we will test the system, we basically carry out the tests outlined in the test plan.

• Once we have collected the test results, we need to analyze them.

• After we analyze the results, we will need to summarize them in the form of a report and presentation to the client.

• If all goes well, then the client will approve or signoff on the test results. Then, we can move on to the implementation phase of our project. If all does not go well, we need to address and fix any problems. Keep in mind, that the test phase is not complete just because we have developed a test plan and created a test report. The client will sign off on the test results only if the system meets certain predetermined quality standards.

Figure 6.3 provides an example of a WBS with the details shown for only the testing phase of the project. As you can see, the WBS implements the concept of a work package for the project, phase, deliverable, task/activity, and milestone components that were illustrated in Figure 6.1. This particular WBS follows an outline format with a commonly used decimal numbering system that allows for continuing levels of detail.1 If a software package is used to create the WBS, signs in front of each item can either hide or show the details. For example, clicking on "-6.2 Test Results Report" would roll up the details of this work package into "+6.2 Test Results Report". Similarly, clicking on any item with a "+" in front of it would expand that item to show the details associated with it.

The skills to develop a useful WBS generally evolve over time with practice and experience. Everyone, experienced or not, should keep in mind the following points when developing a WBS.

The WBS Should Be Deliverable-Oriented Remember, the focus of a project should be to produce something, not merely on completing a specified number of activities. Although the WBS does not provide for any explicit looping, some activities may have to be repeated until the milestone is achieved. For example, software testing may uncover a number of problems or bugs that make the software system unacceptable to the client. As a result, these problems will have to be addressed and fixed and the same tests may have to be conducted again. This process may be repeated a number of times (while consuming the project schedule and budget) until the quality standards are met.

The WBS Should Support the Project's MOV The WBS should include only tasks or activities that allow for the delivery of the project's deliverables. Before continuing with the development of the project plan, the project team should ensure that the WBS allows for the delivery of all the project's deliverables as defined in the project's scope. In turn, this will ensure that the project is more likely to achieve its MOV.

1 Many people prefer to develop a WBS using a chart format, and the DSC in Figure 6.3 could be easily adapted by adding the work package levels. Although a graphic WBS can be visually appealing, it can also become extremely complex and confusing as more detail is added. Feel free to experiment with the WBS. The correct form will depend on the situation or your preference.

-0.0 EC Bank Project

+ 1.0 Conceptualize & initialize project

+2.0 Develop charier & plan

+3.0 Analysis

+4.0 Design

+5.0 Construction

+6.1 Test plan

-6.2 Test results report

Was this article helpful?

0 0
Project Management Made Easy

Project Management Made Easy

What you need to know about… Project Management Made Easy! Project management consists of more than just a large building project and can encompass small projects as well. No matter what the size of your project, you need to have some sort of project management. How you manage your project has everything to do with its outcome.

Get My Free Ebook


Post a comment