Defining and Managing Project Scope

CHAPTER OVERVIEW

Chapter 5 focuses on developing a scope management plan to define and manage the project and product deliverables of the project. After studying this chapter, you should understand and be able to:

• Identify the five processes that support project scope management. These processes, defined by the Project Management Body of Knowledge (PMBOK), include initiation, planning, scope definition, scope verification, and scope change control.

• Describe the difference between product scope (i.e., the features and functions that must support the IT solution) and project scope (i.e., the deliverables and activities that support IT project methodology).

• Apply several tools and techniques for defining and managing the project's scope.

1 GLOBAL TECHNOLOGY SOLUTIONS

On Friday evening Matt and Kellie were still at the GTS office, working on the project charter and project plan for Husky Air. Rubbing her eyes, Kellie asked, "I know we defined the goal of the project by developing the MOV, but what about the work that has to be done to get us there?"

"Glad you asked," Matt said as he put down his personal digital assistant on the desk in front of him. "I think we're ready to start defining the scope of the project, which will help us define all of the deliverables and activities that support the MOV."

"I remember working on a project that never seemed to end," she replied. "The users always wanted to add more bells and whistles to the system, and the project ended up missing its deadline and costing a lot more than we had planned."

Matt thought for a moment, then asked. "So, what can we learn from that experience?"

102 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE Kellie smiled. "First of all," she said. "I think we need to have a plan in place to

make sure that the scope of the project is well-defined. I think part of our problem was that we never really got a clear idea of the project's goal; so we never defined the scope of the project properly. And secondly, we should've had some kind of process in place to control scope changes once we started the project."

Matt agreed. "That sounds like an excellent idea. But why not just say no to any scope change requests?"

Kellie sat back in her chair. "The way I see it, if we say yes to each and every scope change request, we run the risk of escalating the project's schedule and, in turn, the project's budget. On the other hand, if we say no to all scope change requests, we run the risk of missing some opportunities or appearing non-responsive to our client's needs."

"Good point, but how do you know when to say yes to a scope change and when to say no?" asked Matt.

"I guess we could let the project's MOV be our guide," she answered. "If a scope change supports the MOV, then it's worth doing. Otherwise, if it doesn't support the MOV, then the scope change isn't worth the time or money. Besides, the client has to make the decision whether the change in scope is worth the increase in schedule and cost. All we can do is keep the schedule and budget under control and then point out to them how any requested scope change will impact the project."

Matt stood up, saying "I think what we need is a scope management plan that can be part of the project charter. It's also important that we let everyone involved with the project know about it. Let's call it a day and get started on it first thing Monday morning."

Kellie agreed. "That's the best idea I've heard all day. Why don't you go ahead? I'll lock up after I make a few phone calls."

Things to Think About

1. What is the importance of ensuring that the scope of a project has been defined completely and accurately?

2. What is the relationship between the project's MOV and its scope?

3. What is the importance of having scope control procedures in place?

4. Why should a scope control process be communicated to all of the stake holders of a project?

INTRODUCTION

This chapter focuses on defining and managing the work that must be accomplished by the project team over the course of the project. The term scope is used to define the work boundaries and deliverables of the project so what needs to get done, gets done—and only what needs to get done, gets done. Therefore, it is important to define not only what is part of the project work, but also what is not part of the project work. Any work not part of the project is considered to be outside of the project's scope.

Project Scope Management Processes

The Project Management Body of Knowledge (PMBOK) defines five processes to support the knowledge area of project scope management, as shown in Table 5.1. This process group begins with a scope initiation process whereby the project sponsor gives

PROJECT SCOPE MANAGEMENT PROCESSES 103

the project manager the authority and resources to define the scope of the project. In the context of the IT project methodology, the authority to commit time and resources to define the project's scope is included in the second phase when the project charter and project plan are developed.

Once the commitment and resources to develop the project charter and plan are in place, the next process focuses on scope planning. This planning process entails setting the boundary of the project in order to determine what is and what is not to be included in the project work.

The third process centers on scope definition. While scope planning defines the project boundary, scope definition identifies the project deliverables (as identified in the IT project methodology) and the product deliverables (the high-level functionality or features of the IT product to be delivered by the project team). As a result, the boundary and deliverables defined by the scope planning and definition processes provide a key component for developing the project charter and plan. Moreover, the boundary and deliverables become critical inputs for estimating the project's schedule and budget.

Once the scope is defined, the process of scope verification confirms that the scope is complete and accurate. The project team and sponsor must agree to all of the project deliverables. This not only sets expectations, but also focuses the project team on what needs to get done and what is outside the scope of the project.

Time and resources will be wasted needlessly if the scope of the project is never defined accurately or agreed upon. However, changes to the scope may be inevitable as new information becomes available or if the needs of the organization change. Therefore, a process called scope change control is needed to handle these changes so that if a scope change is appropriate, the change can be approved in order to amend the project's schedule and budget accordingly. In addition, scope change control procedures also protect the scope boundary from expanding as a result of increasing featurism, requests by project stakeholders to keep adding additional features and functions (i.e., bells and whistles) to the project once the scope has been set. Remember that the scope, schedule, and budget relationships suggest that increasing the project's scope (i.e., expanding the scope boundary) will generally require an increase in schedule and budget. Therefore, adding additional work to the project's scope will ultimately lead to a project that misses its deadline and costs more than originally estimated. Subsequently, once the project's

104 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE scope has been set, approved changes to the project's scope must be reflected in

the project's baseline plan.

Together, the processes and techniques for defining and managing scope make up the scope management plan. Depending on the size and nature of the project, this plan can be separate and/or summarized in the project charter. Regardless, the procedures for defining and managing the scope of a project must be communicated and understood by all of the project's stakeholders to minimize the likelihood of misun- derstandings. Moreover, the project's scope must align and support the project's MOV. Why spend time and resources to perform work that will not add any value to the organization or help the project achieve its MOV? Again, work that does not add value consumes valuable time and resources needlessly. Figure 5.1 summarizes the components and processes of a scope management plan.

PROJECT SCOPE INITIATION

Scope initiation provides a beginning process that formally authorizes the project manager and team to develop the scope management plan. In terms of the IT project methodology, this authorization is given after the project is formally accepted and funds are committed to developing the project charter and plan by the project sponsor or client. The business case provides important information about the project's description, MOV, risks, assumptions, and feasibility. In addition, the business case provides information about the background of the project in terms of why it was proposed and how it aligns with the organization's overall strategic plan.

Figure 5.1 Scope Management Plan

PROJECT SCOPE INITIATION 105 Project Scope Planning

Failure to define what is part of the project, as well as what is not, may result in work being performed that was unnecessary to create the product of the project and thus lead to both schedule and budget overruns.

Olde Curmudgeon, PM Network Magazine, 1994. Scope planning is a process for defining and documenting the project work. More

specifically, a project's scope defines all the work, activities, and deliverables that the project team must provide in order for the project to achieve its MOV. It is an important step in developing the project plan since one must know what work must be done before an estimate can be made on how long it will take and how much it will cost.

Scope Boundary Defining the scope boundary is the first step to establishing what is, and what is not, part

of the project work to be completed by the project team. Think of the scope boundary as a fence designed to keep certain things in and other things out. As Figure 5.2 illustrates, any work within the scope boundary should include only the work or activities that support the project's MOV. This work is what we want to capture and keep within our fence. On the other hand, a project team can spend a great deal of time doing work and activities that will not help the project achieve its MOV. As a result, the project will consume time and resources with very little return. Therefore, the scope boundary must protect the scope from these activities once it is set and agreed upon by the project stakeholders. Having a clear and agreed upon definition of the project MOV is critical for defining and managing the scope boundary.

The Scope Statement One way to define the scope boundary is to create a scope statement that documents the

project sponsor's needs and expectations. For example, let's say we are outside consultants hired to develop an electronic commerce application for a bank. After developing and presenting a business case to our client, we have been given the authority to develop the project charter and plan. Although the business case provides a great deal of relevant information, we will still set up several meetings and interviews with key

stakeholders in the bank. Based upon these meetings and interviews, we create a scope statement.

Scope Statement

1. Develop a proactive electronic commerce strategy that identifies the processes, products, and services to be delivered through the World Wide Web.

2. Develop an application system that supports all of the processes, products, and services identified in the elec tronic commerce strategy.

3. Integrate the application system with the

bank's existing enterprise resource planning system.

106 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE scope of a project is defined through interviews, meetings, or brainstorming sessions.

Stakeholders often suggest ideas that are interesting, but not feasible or appropriate for the current project.

Let's say that in our example a certain bank vice president pushed for a customer relationship management (CRM) and a data mining component to be included in the application system. The bank's president, however, has decided that the time and effort to add these components cannot be justified because launching the Web site in eight months is vital to bank's competitive strategy. Let's also assume that conducting technology and organizational assessments of our client's current environment is an important piece of our project methodology. But because the bank would like to control some of the costs of this project, we agree that its IT department will conduct that study. The results of this study will then be documented and provided to us.

In this case, it is critical that we define explicitly both what is and what is not part of the project scope. Individuals from both organizations may believe that specific project work (i.e., the assessment study), system features, or functionality (i.e., CRM and data mining) will be part of this project. These beliefs may result in misunder- standings that lead to false expectations or needless work. To manage these expectations, it is useful to list explicitly what is not part of the project's scope.

Out of Scope for this Project

1. Technology and organizational assessment of the current environment

2. Customer resource management and data mining components Setting the scope boundary for the project not only sets expectations, but also can

define the constraints of the project and how the product of the organization fits within the organization, that is, the system must integrate with the organization's existing systems.

The scope statement provides a very general and high-level view of the project work and provides only a starting point for defining the scope of our project. At the beginning of a project understanding of the project's scope may be limited. However, as we work more closely with our client more information is uncovered and our understanding of the project increases. Subsequently, the project scope will evolve from being very general and high level to more detailed and defined.

PROJECT SCOPE DEFINITION 107 PROJECT SCOPE DEFINITION

Developing a scope statement is a useful first step for defining the scope of the project and setting a boundary. A project's scope, however, should also be defined in terms of the deliverables that the team must provide. These deliverables can be divided into project-oriented deliverables and product-oriented deliverables. This separation gives the team a clearer definition of the work to be accomplished and improves the likelihood of accurately assigning resources and estimating the time and cost of completing the work. Moreover, a clear definition of the project's deliverables sets unambiguous expectations and agreement among all of the project stakeholders.

Project-Oriented Scope Project-oriented deliverables, or scope, support the project management and IT devel-

opment processes that are defined in the information technology project methodology (ITPM). Project scope includes such things as the business case, project charter, and project plan and defines the work products of the various ITPM phases. Project-oriented deliverables also include specific deliverables such as a current systems study, requirements definition, and the documented design of the information system. These are deliverables supported by the systems development life cycle (SDLC) component of the overall ITPM.

Project-oriented deliverables require time and resources and, therefore, must be part of the overall project schedule and budget. Their role is to ensure that the project processes are being competed so that the project's product (i.e., the information system) achieves the project's MOV and objectives. Project-oriented deliverables also provide tangible evidence of the project's progress (or lack of progress). Finally, they allow the project manager to set a baseline for performance and quality control because they usually require some form of approval before work on the next project phase or deliverable begins.

Project-Oriented Scope Definition Tools All of the project deliverables must have a clear and concise definition. One way to communicate the project's deliverables is to create a deliverable definition table (DDT). An example of a DDT for our bank's electronic commerce system is illustrated in Table 5.2.

The purpose of the DDT is to define all of the project-oriented deliverables to be provided by the project team. Each deliverable should have a clear purpose. In addition, it is important to define the structure of the deliverable. For example, a deliverable could be a document (paper or electronic), prototype, presentation, or the application system itself. This sets the expectation of what will be delivered by the project team. Moreover, the standards provide a means to verify whether the deliverable was produced correctly. These standards could be defined within the IT Project methodology, controlling agency (e.g., International Organization for Standardization), or through various quality standards established by the organization. Each deliverable must be verified and approved generally by the project sponsor and/or the project manager. It is important that the responsibility for approving a deliverable be clearly defined as well. Once a deliverable is approved, the project team is authorized to begin work on the next deliverable. This provides authorization control as well as a basis for logically sequencing the work. Finally, it is important that the resources required to complete the deliverable be defined. This will provide the foundation for determining not only what resources will be needed for the project, but also for estimating the time and cost in completing each deliverable.

108 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE

SOURCE : Inspired by Graham McLeod and Derek Smith, Managing Information Technology Projects (San Francisco: Boyd & Fraser, 1996), 51-52.

Once the deliverables have been defined in the DDT, a deliverable structure

chart (DSC) can be developed as an interim step to define detailed work packages that will be used to estimate the project schedule and budget. Later on, these work packages will be used to create a work breakdown structure (WBS)—a tool used to help create the project plan. For example, Figure 5.3 provides an example of a

PROJECT SCOPE DEFINITION 109

Deliverable Structure Chart that maps the project life cycle and systems development life cycle phases to the deliverables defined in the DDT.

Product-Oriented Scope Although the electronic commerce application system is listed as a project-oriented

deliverable, we really do not have any idea what exactly will be delivered to the client. In general, the application system will be the largest project deliverable and will, therefore, require the most time and resources to complete. Identifying the features and functionality of the application system (and their complexity) will be piv- otal for estimating the time and cost of producing this deliverable.

Product-Oriented Scope Definition Tools Product scope therefore focuses on identifying the features and functionality of the information system to be implemented.

110 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE

A useful tool for refining the scope boundary and defining what the system must do is a modeling tool called a context level data flow diagram (DFD). A DFD is a process model that has been available for quite some time and is often taught in systems analysis and design courses. A context level DFD, however, presents a high-level representation of the system that has one process (i.e., a circle or rounded rectangle that represents the system as a whole) and depicts all the inflows and outflows of data and information between the system and its external entities. The external entities are usually represented by a square and can be people, departments, or other systems that provide or receive flows of data. Arrows represent the directional flow of data between external entities and the system. Each arrow and entity should be labeled appropriately. Lower level DFDs can be developed later to model the processes and flows of data in greater detail. An example of a context level DFD for our banking electronic commerce system is provided in Figure 5.4. As you can see, the high level features and functionality of the system focus on what the system must do.

Another useful tool for defining the product scope is the use case diagram,

which has been used in the object-oriented world as part of the Unified Modeling Language (UML). While Jacobson (Jacobson, Cristerson et al. 1992) introduced the use case as a tool for software development, a use case diagram can provide a high level model for defining, verifying, and reaching agreement upon the product scope.

The use case diagram is a relatively simple diagram in terms of symbols and syntax, but it is a powerful tool for identifying the main functions or features of the system and the different users or external systems that interact with the system. At this early stage of the project, the use case can provide a high level diagram that can be further refined and detailed during requirements analysis later in the project.

Actors are people (i.e., users, customers, managers, etc.) or external systems (i.e., the bank's ERP system) that interact, or use, the system. Think of actors in terms of roles (e.g., customer) instead of as specific individuals (e.g., Tom Smith). A use case,

PROJECT SCOPE VERIFICATION 111 on the other hand, depicts the major functions the system must perform for an actor or

actors. When developing a use case diagram, actors are identified using stick figures, while use cases are defined and represented using ovals. Figure 5.5 provides an example of a use case diagram for the bank example.

As you can see in Figure 5.5, the use case diagram provides a simple yet effective overview of the functions and interactions between the use cases and the actors. The box separating the use cases from the actors also provides a system boundary that defines the scope boundary. Use cases inside the boundary are considered within the scope of the project, while anything outside of the boundary is considered outside the scope of the project. Listing the actors provides an opportunity to identify various stakeholders and can be useful for understanding the needs of the organization as a whole. It can be useful not only for addressing competing needs among various stakeholders, but also for identifying security issues as well (Fowler and Scott 1997). The development of a use case diagram is an iterative process that can be developed during

a joint application development (JAD) session. JAD is a group-based method where the users and systems analysts jointly define the system requirements or design the system (Turban, Rainer and Potter 2001).

The use case diagram used to define the product scope can be used to refine the level of detail and functionality later on in our project. Following our example, the use case diagram in Figure 5.5 identifies the customer actor as using the system to transfer payments. However, a scenario or set of scenarios could be developed during the analysis and design phases of our project to determine how a customer would transfer funds successfully, while another scenario might focus on what happens when a customer has insufficient funds in their account. This level of detail is more suited to the requirements definition rather than the scope definition. At this point, it is more important to identify that the system must allow a customer to transfer funds than to identify how the funds may be transferred. Later on, the product scope can be compared or measured against the detailed requirements. These detailed requirements will be defined during the SDLC component of the ITPM.

But what is the appropriate level of detail for defining the product scope? Knowing the right level of detail is more an art than a science. The right level allows the project manager to estimate the time it will take to produce the application system accurately. As the next chapter shows, estimating the time and effort to produce the application system deliverable depends on the size of the application, the number of features incorporated, and their level of complexity. Therefore, the quality of the estimates will be greatly influenced by our understanding of the information system to

be delivered. The time and resources committed to developing the project charter and plan may limit the amount of time and energy we can devote to defining the details of the information system. Thus, the objective during this planning stage of the project should be to secure enough detail about the information system to allow us to estimate the time and effort needed to produce this deliverable. During the analysis and design phases, we can commit more time and resources to increasing our understanding and to documenting the level of detail needed to built and deliver the system.

PROJECT SCOPE VERIFICATION

Once the project's scope has been defined, it must be verified. Project scope verifi-

cation is the scope management process that provides a mechanism for ensuring that the project deliverables are completed according to the standards described in the

112 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE

SCOPE CHANGE CONTROL 113 DDT. Gray and Larson (2000) provide a project scope checklist for ensuring that the

deliverables are completed—and completed correctly. This checklist has been adapted to include the MOV concept.

• MOV—Are the project's MOV clearly defined and agreed upon? Failure to define and agree upon the MOV could result in scope changes later in the proj ect, which can lead to added work impacting the project's schedule and budget.

• Deliverables—Are the deliverables tangible and verifiable? Do they support

the project's MOV? • Quality standards—Are controls in place to ensure that the work was not

only completed, but also completed to meet specific standards? • Milestones—Are milestones defined for each deliverable? Milestones are

significant events that mark the acceptance of a deliverable and give the project manager and team the approval to begin working on the next deliv erable. In short, milestones tell us that a deliverable was not only com pleted, but also reviewed and accepted.

• Review and acceptance—Are both sides clear in their expectations? The project's scope must be reviewed and accepted by the project stakeholders. The project sponsor must formally accept the boundary, product to be pro duced, and the project-related deliverables. The project team must be clear on what it must deliver. In both cases, expectations must be realistic and agreed upon.

SCOPE CHANGE CONTROL

According to the PMBOK, scope change control is concerned with ensuring that any changes to the project scope will be beneficial, with determining that an actual scope change has occurred, and with managing the actual changes when and as they occur. Scope control is also concerned with:

• Scope grope—Scope grope is a metaphor that describes a project team's inability to define the project's scope. This situation is common early in a project when the project team and sponsor have trouble understanding what the project is supposed to accomplish. Scope grope can be minimized by having a clearly defined MOV and by following or applying the processes, concepts, and tools described in this chapter.

• Scope creep—Scope creep refers to increasing featurism, adding small yet time- and resource-consuming features to the system once the scope of the project has been approved. For example, a project sponsor may try to add various bells and whistles to the project scope. Yet, scope creep does not always come from the project sponsor side. The project team itself may come across interesting or novel ideas as the project work progresses. Its enthusi asm for adding these ideas can divert its attention or add features and func tions to the system that the project sponsor did not ask for and does not need. Scope creep must be identified and controlled throughout the project because it will lengthen the project schedule and, in turn, lead to cost overruns.

• Scope leap—If scope creep is caused by increasing featurism, scope leap suggests a fundamental and significant change in the project scope. For example, the original scope for the bank's electronic commerce project was

114 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE

to provide new products and services to its customers. Scope creep may be adding a new feature, such as a new product or service, not originally defined in the project's scope. Scope leap, on the other hand, is an impetus to change the project so that the electronic commerce system would allow the bank to obtain additional funding in the open market. Adding this activity would dramatically change the entire scope and focus of the project. Scope leap can occur as a result of changes in the environment, the business, and the competitive makeup of the industry. Scope leap entails changing the MOV and, therefore, requires that the organization rethink the value of the current project. If this change is critical, the organization may be better off pulling the plug on the current project and starting over by conceptualizing and initiating

a new project.

Scope Change Control Procedures

A scope change procedure should be in place before the actual work on the project commences. It can be part of, or at least referenced in, the project charter so that it is communicated to all project stakeholders. This procedure should allow for the identi- fication and handling of all requested changes to the project's scope. Scope change requests can be made, and each request's impact on the project can be assessed. Then, a decision whether to accept or reject the scope change can be made.

SCOPE CHANGE CONTROL 115

A scope change procedure may include a scope change request form. An example of a scope change request form is illustrated in Figure 5.6. The individual or group making the scope change request should complete the form.

Regardless of the format for a scope change request form, it should contain some basic information. First, the description of the change request should be clearly defined so that the project manager and project team understand fully the nature and reason for the scope change. Second, the scope change should be justified, which separates the would likes from the must haves. In addition, several alternatives may be listed in order to assess the impact on scope, schedule, resources, and cost. Often a trade-off or compromise will be suitable if the impact of the scope change is too great. The project sponsor must understand and approve these impacts because the baseline project plan will have to be adjusted accordingly. Alternatives may include reducing functionality in other areas of the project, extending the project deadline, or adding more resources in terms of staff, over- time, or technology. Finally, all scope changes must be approved so that additional resources can be committed to the project.

However, nothing can be more frustrating than making a request and then not hearing anything. Too often requests fall through the cracks, leading to credibility con- cerns and accusations that the project manager or project team is not being responsive to the client's needs. Therefore, a scope change control procedure should be logged with the intention that each request will be reviewed and acted upon. As seen in Figure

5.7, an example of a Change Request Log includes information as to who has the authority to make the scope change decision and when a response can be expected. Although this may seem like the beginning of a bureaucracy, it is really designed to protect all project stakeholders. Too often the project manager and project team feel the pressure to say yes to each and every scope change request because their refusal may be interpreted as being uncooperative. Unfortunately, introducing scope creep will impact the schedule and budget. As the deadline passes or as costs begin to overrun the budget, the project manager and team then may come under fire for not controlling the project objectives.

116 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE

Figure 5.6 Scope Change Request Form

Figure 5.7 Scope Change Request Log

Still, a project manager and team should not say no to every scope change request. Some changes will be beneficial and warranted as the project proceeds. The question then becomes, What should be the basis for making a scope change decision?

REVIEW QUESTIONS 117 As you have seen, the project's MOV guides the project planning process.

Similarly, the project's MOV can also guide scope change decisions. A scope change request should be approved if—and only if—the scope change can bring the project closer to achieving its MOV; otherwise, why bother adding additional work, resources, time, and money to activities that will not bring any value to the organization?

Benefits of Scope Control The most important benefit of scope change control procedures is that they keep the

project manager in control of the project. More specifically, they allow the project manager to manage and control the project's schedule and budget. Scope control procedures also allow the project team to stay focused and on track in terms of meeting its milestones because it does not have to perform unnecessary work.

I CHAPTER SUMMARY

Although scope is the work to be performed on the project, a project's scope can be defined as the boundary and deliverables that the project team will provide to the project sponsor. A scope boundary acts as a fence to ensure that what needs to get done, gets done—and only what needs to get done, gets done. Performing work that does not help the project achieve its MOV needlessly consumes valuable time and resources. Therefore, the project's boundary helps the project team define the limits of the project and how it will interact with its environment. In addition, deliverables are tangible units of work that ensure that the project is on track. Deliverables may be product-oriented or project-oriented. Product-oriented deliverables focus on the high level features and functionality of the application system—the project's product. On the other hand, project-oriented deliverables focus on the project's processes as defined in the IT project methodology.

The Project Management Body of Knowledge identifies five processes that make up the scope management process group. These processes include: (1) Scope Initiation, (2) Scope Planning, (3) Scope Definition, (4) Scope Verification, and (5) Scope Change Control. Figure 5.8 summarizes these processes and the tools used to support them.

Scope grope is a common occurrence in the early stages of the project. Often the project team struggles to define what the project is all about and what work must be done. By applying the concept of an MOV and the tools introduced in this chapter, the time a project team spends searching for these answers should be reduced. Scope creep, on the other hand, is a common occurrence in many projects. It entails adding additional features or functions to the scope once the scope has been set and approved. This phenomenon can increase the schedule and budget, causing the project to miss its deadline and budget targets. Scope creep can be managed by (1) verifying that the scope is accurate and complete by using a scope verification checklist, and (2) ensuring that appropriate scope changes are approved and reflected in the baseline plan by having scope change procedures. The MOV concept can guide this decision process. For example, scope changes that move the project closer to achieving its MOV should

be approved, while those that do not merely waste time and resources. Lastly, scope leap entails a major and fundamental change to the project scope. It may be the result of a changing business environment or the competitive makeup of the industry. Such a radical departure from the original business case may require the project stakeholders to rethink the viability of the current project.

| REVIEW QUESTIONS

1. What is meant by project scope?

2. Briefly describe the five scope management processes.

3. What is the project's scope initiation process? When does it occur? Why is it important?

4. How is a project's scope initiation process sup ported by the IT project methodology?

5. Briefly describe the scope planning process.

6. Briefly describe the scope definition process.

7. Briefly describe the scope verification process.

118 CHAPTER 5 / DEFINING AND MANAGING PROJECT SCOPE

Scope Management Processes

8. Briefly describe the scope change control process.

18. What is a deliverable structure chart (DSC)? How

9. Describe the scope management plan in Figure 5.1. does it map to a deliverable definition table (DDT)?

10. Why is it important to define the project's scope

19. What is a work breakdown structure (WBS)? How accurately and completely? does it map to the DDT and DSC?

20. Briefly describe what must be included in a scope serve?

11. What is a scope boundary? What purpose does it

verification checklist?

21. What is the purpose of verifying a project's scope? deliverables and project-oriented deliverables?

12. What is the difference between product-oriented

22. What is the purpose of scope change control pro

13. How does a project's scope support the MOV

cedures?

concept? 23. Briefly describe scope grope.

24. Briefly describe scope creep. serve?

14. What is a scope statement? What purpose does it

25. Briefly describe scope leap.

15. What is a context dataflow diagram (DFD)? What

26. What are the benefits of having scope control pro purpose does it serve? cedures?

16. How does a use case diagram help to define the pro

27. Briefly describe what should be included on a scope ject's scope? change request form.

28. What is the purpose of a scope change request log? purpose does it serve?

17. What is a deliverable definition table (DDT)? What

BIBLIOGRAPHY 119

The Work Breakdown Structure and Project Estimation

CHAPTER OVERVIEW

Chapter 6 focuses on developing the work breakdown structure, as well as on introducing a number of project estimation approaches, tools, and techniques. After studying this chapter, you should understand and be able to:

• Develop a work breakdown structure. • Describe the difference between a deliverable and a milestone. • Describe and apply several project estimation methods. These include the

Delphi technique, time boxing, top-down estimation, and bottom-up estimation. • Describe and apply several software engineering estimation approaches. These

include lines of code (LOG), function point analysis, COCOMO, and heuristics.

GLOBAL TECHNOLOGY SOLUTIONS

The white board in the GTS conference room was filled with multicolor markings reflecting the ideas and suggestions from the Husky Air team. Several empty pizza boxes were piled neatly in the corner. It had been an all-day working session for the Husky Air project team. Although it was late in the day, the energy in the room was still high. Everyone felt they were drawing closer to a first draft of the project plan.

Tim Williams stood up and walked over to the electronic white board. Addressing the group, he said, "It looks like we have just about everything we need, but I would like to make sure all of the activities or tasks in the systems testing phase are defined more clearly. Let's start out by identifying what deliverables we need to produce as a result of the testing phase."

Sitaramin paged through his notes and said that the team had identified a test plan and a test results report as part of the project scope. Yan, the project's database administrator, suggested that the test report summarize not only the results of

GLOBAL TECHNOLOGY SOLUTIONS 121 the system tests, but also what was tested and how the tests were conducted. The

rest of the team agreed, and Tim wrote TESTING PHASE in capital letters on the board and then Deliverable: Test Results Report underneath it. Yan then suggested that the phase needed a milestone. Sitaramin said that the testing phase would not

be completed when the report was finished, but only when the test results were acceptable to the client. The rest of the team agreed and Tim wrote Milestone: Client signs off on test results.

Tim then asked what specific activities or tasks the team would have to do to create the test results report. For the next ten minutes, the entire team brainstormed ideas. Tim dutifully wrote each idea on the board without judgment and only asked for clar- ification or help spelling a particular word. After working together for only a short time, the team had already adopted an unwritten rule that no one was to evaluate an idea until after they finished the brainstorming activity. They had found that this encouraged participation from everyone and allowed for more creative ideas.

After a few minutes, the frequency of new ideas suggested by the team started to slow. Tim then asked if any of these ideas or suggestions were similar—i.e., did they have the same meaning or could they be grouped. Again, everyone had ideas and suggestions, and Tim rewrote the original list until the team agreed on a list of activities that would allow them to develop the test results plan.

"This looks pretty good!" exclaimed Tim. Then he added, "But do all of these activities have to be followed one after the other? Or can some of these activities be completed in parallel by different team members?"

Once again, the team began making suggestions and discussing ideas of how to best sequence these activities. This only took a few minutes, but everyone could to see how the testing phase of the project was taking shape. Tim paused, took a few steps back, and announced, "Ok, it looks like we're headed in the right direction. Now who will be responsible for completing these tasks and what resources will they need?"

Since everyone on the team had a specific role, the assigning of team members to the tasks was pretty straightforward. Some of the tasks required only one person, while others needed two or more. The team also identified a few activities where the same person was assigned to tasks scheduled at the same time. The team's discussion also identified an important activity that was overlooked and needed to

be added.

Tim joked that he was glad they were using a white board that could easily be erased as he carefully updated the activities and assignments. Then he smiled and said, "Our work breakdown structure is almost complete. All we need to do now is estimate how long each of these testing activities will take. Once we have these estimates, we can enter the work breakdown structure into the project management software package we're using to get the schedule and budget. I think we'll need to review our project plan as a team at least one more time before we present it to our client. I'm sure we'll have to make some changes along the way, but I would say the bulk of our planning work is almost complete."

It was getting late in the day, and the team was starting to get tired. Ted, a telecommunications specialist, suggested that they all meet the next day to finalize the time estimates for the testing phase activities. He also asked that before they adjourned, the team should once again develop an action plan based upon facts the team knew to be true, any assumptions to be tested, and what they would need to find out in order to estimate each of the testing phase activities.

The rest of the team agreed, and they began another learning cycle.

122 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION

Things to Think About

1. What are some advantages of a project team working together to develop the project plan? What are some disadvantages?

2. Why should the project team members not be too quick to judge the ideas and suggestions provided during a brainstorming session?

3. How can the concept of learning cycles support the project planning process?

INTRODUCTION

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

THE WORK BREAKDOWN STRUCTURE (WBS) 123 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.

124 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION 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 col- lection 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

THE WORK BREAKDOWN STRUCTURE (WBS) 125

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

Figure 6.2 Deliverable Structure Chart (DSC) for EC Example

126 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION 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.

THE WORK BREAKDOWN STRUCTURE (WBS) 127

Haugen (2002) also suggests that the 100 percent rule is the most important criterion in the developing and evaluating the WBS. The rule states: "The next level decomposition of a WBS element (child level) must represent 100 percent of the work applicable to the next higher (parent) element." (17) In other words, if each level of the WBS follows the 100 percent rule down to the activities, then we are confident that 100 percent of the activities will have been identified when we develop the project schedule. Moreover, 100 percent of the costs or resources required will be identified when we create the budget for our project.

The Level of Detail Should Support Planning and Control The WBS provides a bridge between the project's scope and project plan—that is, the schedule and budget. Therefore, the level of detail should support not only the development of the project plan but also allow the project manager and project team to monitor and compare the project's actual progress to the original plan's schedule and budget. The two most common errors when developing a WBS are too little or too much detail. Too little detail may result in a project plan that overlooks and omits important activities and tasks. This will lead to an overly optimistic schedule and budget. On the other hand, the WBS should not be a to-do list of one-hour tasks. This excessive detail results in micromanagement that can have several adverse effects on the project. First, this may impact the project team's morale because most people on projects are professionals who do not want someone constantly looking over their shoulders. Second, the progress of each and every task must be tracked. As a result, the project plan will either not be updated frequently or clerical staff will have to be hired (at a cost to the project) just to keep everything current.

128 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION Developing the WES Should Involve the People Who Will Be Doing the Work One

way to ensure that the WBS has the appropriate level of detail is to ensure that the people who do the work are involved in its development. A person who has experience and expertise in a particular area probably has a better feel for what activities need to

be performed in order to produce a particular project deliverable. Although the project manager is responsible for ensuring that a realistic WBS is developed, the people who must carry out the activities and tasks may be more committed to the plan if they are involved in its development.

Learning Cycles and Lessons Learned Can Support the Development of a WBS By using the concept of learning cycles, the project team can focus on what they know (the facts), what they think they know (assumptions), and what they need to find out (research) in order to develop a more useful WBS. Lessons learned from previous projects can be helpful in ensuring that the WBS and subsequent project plan are realistic and complete.

PROJECT ESTIMATION

Once the project deliverables and activities have been defined, the next step in developing the project schedule and budget is to estimate each activity's duration. One of the most crucial—and difficult—activities in project management is estimating the time it will take to complete a particular task. Since a resource generally performs a particular task, a cost associated with that particular resource must be allocated as part of the time it takes to complete that task. The time estimated to complete a particular task will have a direct bearing on the project's budget as well. As T. Capers Jones (Jones 1998) points out:

The seeds of major software disasters are usually sown in the first three months of commencing the software project. Hasty scheduling, irrational commitments, unprofessional estimating techniques, and carelessness of the project management function are the factors that tend to introduce terminal problems. Once a project blindly lurches forward toward an impossible delivery date, the rest of the disaster will occur almost inevitably. (120)

In this section, we will review several estimation techniques—guesstimating, Delphi, top-down and bottom-up estimating.

Guesstimating

Estimation by guessing or just picking numbers out of the air is not the best way to derive a project's schedule and budget. Unfortunately, many inexperienced project managers tend to guesstimate, or guess at the estimates, because it is quick and easy. For example, we might guesstimate that testing will take two weeks. Why two weeks? Why not three weeks? Or ten weeks? Because we are picking numbers out of thin air, the confidence in these estimates will be quite low. You might as well pick numbers out of a hat. The problem is that guessing at the estimates is based on feelings rather than hard evidence.

However, many times a project manager is put on the spot and asked to provide a ballpark figure. Be careful when quoting a time frame or cost off the record, because whatever estimates you come up with often become on the record.

PROJECT ESTIMATION 129 People are often overly optimistic and, therefore, their guesstimates are overly

optimistic. Underestimating can result in long hours, reduced quality, and unmet client expectations. If you ever find yourself being pressured to guesstimate, your first impulse should be to stall until you have enough information to make a confident estimate. You may not, however, have that luxury so the best approach is to provide some kind of confidence interval. For example, if you think something will probably take three months and cost $30,000, provide a confidence interval of three to six months with a cost of $30,000 to $60,000. Then quickly offer to do a little more research to develop a more confident estimate. Notice that even though three months and $30,000 may be the most likely estimate, an estimate of two to six months was not made. Why? Because people tend to be optimists and the most likely case of finishing in three months is probably an optimistic case.

Delphi Technique The Delphi technique involves multiple experts who arrive at a consensus on a par-

ticular subject or issue. Although the Delphi technique is generally used for group decision-making, it can be a useful tool for estimating when the time and money war- rant the extra effort (Roetzheim and Beasley 1998).

To estimate using the Delphi technique, several experts need to be recruited to estimate the same item. Based upon information supplied, each expert makes an estimate and then all the results are compared. If the estimates are reasonably close, they can be averaged and used as an estimate. Otherwise, the estimates are distributed back to the experts who discuss the differences and then make another estimate.

In general, these rounds are anonymous and several rounds may take place until

a consensus is reached. Not surprisingly, using the Delphi technique can take longer and cost more than most estimation methods, but it can be very effective and provide reasonable assurance when the stakes are high and the margin for error is low.

Time Boxing Time boxing is a technique whereby a box of time is allocated for a specific activity

or task. This allocation is based more on a requirement rather than on just guesswork. For example, a project team may have two (and only two) weeks to build a prototype. At the end of the two weeks, work on the prototype stops, regardless of whether the prototype is 100 percent complete.

Used effectively, time boxing can help focus the project team's effort on an important and critical task. The schedule pressure to meet a particular deadline, however, may result in long hours and pressure to succeed. Used inappropriately or too often, the project team members become burned out and frustrated.

Top-Down Estimating Top-down estimating involves estimating the schedule and/or cost of the entire proj-

ect in terms of how long it should take or how much it should cost. Top-down estimating is a very common occurrence that often results from a mandate made by upper management (e.g., Thou shalt complete the project within six months and spend no more than $500,000!).

Often the schedule and/or cost estimate is a product of some strategic plan or because someone thinks it should take a certain amount of time or cost a particular amount. On the other hand, top-down estimating could be a reaction to the business

130 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION environment. For example, the project may have to be completed within six months

as a result of a competitor's actions or to win the business of a customer (i.e., the customer needs this in six months).

Once the target objectives in terms of schedule or budget are identified, it is up to the project manager to allocate percentages to the various project life cycle phases and associated tasks or activities. Data from past projects can be very useful in applying percentages and ensuring that the estimates are reasonable. It is important to keep in mind that top-down estimating works well when the target objectives are reasonable, realistic, and achievable.

When made by people independent from the project team, however, these targets are often overly optimistic or overly aggressive. These unrealistic targets often lead to what Ed Yourdon (1999) calls a death march project:

I define a death march project as one whose "project parameters" exceed the norm by at least 50 percent. This doesn't correspond to the "military" definition, and it would be a travesty to compare even the worst software project with the Bataan death march during the Second World War, or the "trail of tears" death march imposed upon Native Americans in the late 1700s. Instead, I use the term as a metaphor, to suggest a "forced march" imposed upon relatively innocent victims, the outcome of which is usually a high casualty rate." (2)

Project parameters include schedule, staff, budget or other resources, and the functionality, features, performance requirements, or other aspects of the project. A death march software project means one or more of the following constraints has been imposed (Yourdon 1999):

The project schedule has been compressed to less than 50 percent of its original estimate.

The staff originally assigned or required to complete the project has been reduced to less than 50 percent.

The budget and resources needed have been reduced by 50 percent or more.

The functionality, features, or other performance or technical requirements are twice what they should be under typical circumstances.

On the other hand, top-down estimating can be a very effective approach to cost and schedule analysis (Royce 1998). More specifically, a top-down approach may force the project manager to examine the project's risks more closely so that a specific budget or schedule target can be achieved. By understanding the risks, trade-offs, and sensitivities objectively, the various project stakeholders can develop a mutual understanding that leads to better estimation. This outcome, however, requires that all stakeholders be willing to communicate and make trade-offs.

Bottom-Up Estimating

Most real-world estimating is made using bottom-up estimating (Royce 1998). Bottom-up estimating involves dividing the project into smaller modules and then directly estimating the time and effort in terms of person-hours, person-weeks, or person-months for each module. The work breakdown structure provides the basis for bottom-up estimating because all of the project phases and activities are defined.

The project manager, or better yet the project team, can provide reasonable time estimates for each activity. In short, bottom-up estimating starts with a list of all

SOFTWARE ENGINEERING METRICS AND APPROACHES 131 required tasks or activities and then an estimate for the amount of effort is made. The

total time and associated cost for each activity provides the basis for the project's target schedule and budget. Although bottom-up estimated is straightforward, confusing effort with progress can be problematic (Brooks 1995).

Continuing with our earlier example, let's assume that after meeting with our software testers, the following durations were estimated for each of the following activities:

6.2 Test results report

6.2.1 Review test plan with client

1 day

6.2.2 Carry out test plan

5 days

6.2.3 Analyze results

2 days

6.2.4 Prepare test results report and presentation

3 days

6.2.5 Present test results to client

1 day

6.2.6 Address any software issues or problems

5 days

If we add all of the estimated durations together, we find that creating the test results report will take seventeen days. How did we come up with these estimates? Did we guesstimate them? Hopefully not! These estimates could be based on experience—the software testers may have done these activities many times in the past so they know what activities have to be done and how long each activity will take. Or,

these estimates could be based on similar or analogous projects. Analogous estima-

tion refers to developing estimates based upon one's opinion that there is a significant similarity between the current project and others (Rad 2002).

Keep in mind that estimates are a function of the activity itself, the resources, and the support provided. More specifically, the estimated duration of an activity will first depend upon the nature of the activity in terms of its complexity and degree of structure. In general, highly complex and unstructured activities will take longer to complete than simple, well-structured activities.

The resources assigned to a particular activity will also influence an estimate. For example, assigning an experienced and well-trained individual to a particular task should mean less time is required to complete it than if a novice were assigned. However, experience and expertise are only part of the equation. We also have to consider such things as a person's level of motivation and enthusiasm.

Finally, the support we provide also influences our estimates. Support may include technology, tools, training, and the physical work environment. These are just some of the variables that we must consider when estimating. You can probably come up with a number of others. Subsequently, estimates will always

be a forecast; however, by looking at and understanding the big picture, we can increase our confidence in them.

SOFTWARE ENGINEERING METRICS AND APPROACHES

The discipline of software engineering focuses on the processes, tools, and methods

for developing a quality approach to developing software (Pressman 2001). Metrics

on the other hand, provide the basis for software engineering and refers to a broad range of measurements for objectively evaluating computer software.

The greatest challenge for estimating an IT project is estimating the time and effort for the largest deliverable of the project—the application system.

132 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION

Maintenance projects and the installation of packaged software can experience similar difficulties.

The challenge lies in trying to estimate something that is logical, rather than physical, and that is not well defined until the later stages of the project life cycle. Scope definition can only provide a high-level view of what is and what is not within the scope boundary of the project. Specific requirements, in terms of features and functionality, are generally not defined until later, during the design phase. In addition, the complexity and technical challenges of implementing those features are either unknown or optimistically glossed over in the early stages of the project. As a result, estimating an IT project can be like trying to hit a moving target—hitting either one accurately requires continuous adjustments.

As illustrated in Figure 6.4, the first step to accurately estimating an IT application is determining its size (Jones 1998). In other words, how big is the application? Without getting into too much detail at this point, it should be intuitive that it takes more effort (i.e., in terms of schedule, resources, and budget) to build a larger system than a smaller system. However, the size of the application is only one piece of the estimation puzzle. A good portion of time and effort will be spent on features and functionality that are more complex. As a result, the greater the complexity, the more time and effort that will be spent. Constraints and various influences will also affect the time and effort needed to develop a particular application. These constraints could

be attributes of the application (Jones 1998) or include the processes, people, technology, environment, and required quality of the product as well (Royce 1998). Once the resources and time estimates are known, the specific activities or tasks can be sequenced in order to create the project's schedule and budget.

SOFTWARE ENGINEERING METRICS AND APPROACHES 133

Lines of Code (LOC)

Counting the number of lines of code in computer programs is the most traditional and widely used software metric for sizing the application product. It is also the most controversial.

Although counting lines of code seems intuitively obvious—a 1,000 LOC Java program will be ten times larger than a 100 LOC Java program—counting LOC is not all that straightforward. First, what counts as LOC? Do we include comments? Maybe we should not because a programmer could artificially boost his or her productivity by writing one hundred comment lines for every line of code that actually did something. On the other hand, comments are important because they tell us what the code should be doing. This makes it easier to debug and for others to understand what sections of code in the program are doing.

What about declaring variables? Do they count as LOC? In

Figure 6.4 Software Engineering Estimation Model addition, experienced programmers tend to write less code

than novice programmers. After all, an experienced Royce 1998. programmer can write more efficient code, code that does the

SOURCE : Adapted from Garmus and Herron 1996; Jones 1998,

same thing in fewer lines of code than a novice programmer would use. The same can be said for different programming languages. Writing a program in Assembler requires a great deal more code than writing a similar program in Visual Basic. In fact, one could argue that counting LOC could encourage programmers to write inefficient code, especially when LOC are used as a productivity metric. Finally, it is much easier to count the lines of code after a program is written than it is to estimate how many lines of code will be required to write the program.

Function Points 1

The inherent problems of LOC as a metric for estimation and productivity necessi- tated the need for a better software metric. In 1979, Allan Albrecht of IBM proposed the idea of function points at a conference hosted by IBM in Monterey, California (Albrecht 1979). Function points are a synthetic metric, similar to ones used every day, such as hours, kilos, tons, nautical miles, degrees Celsius, and so on. However, function points focus on the functionality and complexity of an application system or a particular module. For example, just as 20 degree Celsius day is warmer than a 10 degree Celsius day, a 1,000 function point application is larger and more complex than a 500 function point application.

The good thing about function points is that they are independent of the technology. More specifically, functionality and the technology are kept separate so we can compare different applications that may or may not use different programming languages or technology platforms. That is, we can compare one application written in COBOL with another application developed in Java. Moreover, function point analysis is reliable—i.e., two people who are skilled and experienced in function point

134 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION analysis will obtain function point counts that are the same, that is, within an acceptable

margin of error.

Counting function points is fairly straightforward; however, the rules can be complex for the novice. It is recommended that anyone serious about learning function point analysis become certified. Although several function point organizations exist, the two main ones are the International Function Point Users Group (IFPUG) and the United Kingdom Function Point Users Group (UFPUG). Both of these nonprofit organizations oversee the rules, guidelines, standards, and certifications for function point analysis. In addition, there are resources at the end of the chapter if you are interested in learning more about function points.

The key to counting function points is having a good understanding of the user's requirements. Early on in the project, a function point analysis can be conducted based on the project's scope. Then a more detailed analysis of the user's requirements can be made during the analysis and design phases. Then, function point analysis can and should be conducted at various stages of the project life cycle. For example, a function point analysis conducted based on the project's scope definition can be used for estimation and developing the project's plan. During the analysis and design phases, function points can be used to manage and report progress and for monitoring scope creep. In addition, a function point analysis conducted during or after the project's implementation can be useful for determining whether all of the functionality was delivered. By capturing this information in a repository or database, it can be combined with other metrics useful for benchmarking, estimating future projects, and understanding the impact of new methods, tools, technologies, and best practices that were introduced.

Function point analysis is based on an evaluation of five data and transactional types that define the application boundary as illustrated in Figure 6.5.

Internal Logical File (ILF)—An ILF is a logical file that stores data within the application boundary. For example, each entity in an Entity- Relationship Diagram (ERD) would be considered as an ILF. The complex ity of an ILF can be classified as low, average, or high based on the number of data elements and subgroups of data elements maintained by the ILF. An example of a subgroup would be new customers for an entity called cus tomer. Examples of data elements would be customer number, name, address, phone number, and so forth. In short, ILFs with fewer data ele ments and subgroups will be less complex than ILFs with more data ele ments and subgroups.

External Interface File (EIF)—An EIF is similar to an ILF; however, an EIF is a file maintained by another application system. The complexity of an EIF is determined using the same criteria used for an ILF.

External Input (El)—An El refers to processes or transactional data that originate outside the application and cross the application boundary from outside to inside. The data generally are added, deleted, or updated in one or more files internal to the application (i.e., internal logical files). A com mon example of an El would be a screen that allows the user to input infor mation using a keyboard and a mouse. Data can, however, pass through the

application boundary from other applications. For example, a sales system may need a customer's current balance from an accounts receivable system. Based on its complexity, in terms of the number of internal files referenced,

SOFTWARE ENGINEERING METRICS AND APPROACHES 135 number of data elements (i.e., fields) included, and any other human factors, each

El is classified as low, average, or high. •

External Output (EO)—Similarly, an EO is a process or transaction that allows data to exit the application boundary. Examples of EOs include reports, confirmation messages, derived or calculated totals, and graphs or charts. This data could go to screens, printers, or other applications. After the number of EOs are counted, they are rated based on their complexity, like the external inputs (El).

• External Inquiry (EQ)—An EQ is a process or transaction that includes a combination of inputs and outputs for retrieving data from either the inter nal files or from files external to the application. EQs do not update or change any data stored in a file. They only read this information. Queries with different processing logic or a different input or output format are counted as a single EQ. Once the EQs are identified, they are classified based on their complexity as low, average, or high, according to the number of files referenced and number of data elements included in the query.

Once all of the ILFs, EIFs, Els, EOs, and EQs, are counted and their relative com- plexities rated, an Unadjusted Function Point (UAF) count is determined. For example, let's say that after reviewing an application system, the following was determined:

• ILF: 3 Low, 2 Average, 1 Complex •

EIF: 2 Average •

El: 3 Low, 5 Average, 4 Complex •

EO: 4 Low, 2 Average, 1 Complex •

EQ: 2 Low, 5 Average, 3 Complex Using Table 6.1, the (UAF) value is calculated.

The next step in function point analysis is to compute a Value Adjustment Factor (VAF). The VAF is based on the Degrees of Influence (DI), often called the Processing Complexity Adjustment (PCA), and is derived from the fourteen General

Systems Characteristics (GSC) shown in Table 6.2. To determine the total DI, each GSC is rated based on the following scale from 0 to 5:

0 = not present or no influence •

1 = incidental influence •

2 = moderate influence •

3 = average influence •

4 = significant influence •

5 = strong influence Continuing with our example, let's say that after reviewing the application, the

degrees of influence shown in Table 6.2 were determined to produce 210 total adjusted function points (TAFP). So what do we do with the total adjusted function point number? Once a total adjusted function point count is calculated, the function point count can be transformed into development estimates. The first approach focuses on productivity—i.e., a person, such as a programmer, can produce a certain number of function points in a given amount of time, such as in a day, a week, or a month. Once again, creating a repository of function point information and other metrics allows an organization to compare various projects and support more realistic estimates.

The second approach focuses on converting the function point count into an equivalent number of lines of code. Continuing with our example, we can determine how many lines of code will be required for several different programming languages. Table 6.3 provides an example that approximates the number of lines of code per function point for some of the more popular programming languages. As you can see, the number of lines of code depends on the programming language. An application or module that has 210 total unadjusted function points would require, for example, 134,440 lines of code if programmed in machine language, but only 6,090 lines of code using Visual Basic 5. Again, these estimates not only provide an estimate for the size of the application, but also for the complexity of the application.

In addition, T. Capers Jones has conducted extensive research and has come up with

a technique called backfiring, which allows direct conversion from an application's source code to an equivalent function point count. Individual programming styles can create variation in the number of LOG so the accuracy of backfiring is not very high. It can, however, provide an easy way to create a function point inventory of an organization's project portfolio if LOG are readily available.

SOFTWARE ENGINEERING METRICS AND APPROACHES 137

COCOMO COCOMO is an acronym for

Constructive COst MOdel, which was first introduced in 1981 by Barry Boehm in his book Software Engineering Economics. Based on LOG estimates, it is used to estimate cost, effort, and schedule (Boehm 1981). The original COCOMO model received widespread interest and is an open model, meaning that all of the underlying equations, assumptions, definitions, and so on are available to the public. The original COCOMO model was based on a study of 63 projects and is a hierarchy of estimation models.

COCOMO is an example of a parametric model because it uses dependent variables, such as cost or duration, based upon one or more independent variables that are quantitative indices of performance and/or physical attributes of the system. Often, parametric models can be refined and fine-tuned for specific projects or projects within specific industries (Rad 2002).

Estimating with COCOMO begins with determining the type of project to be estimated. Project types can be classified as:

• Organic—These are routine projects where the technology, processes, and people are expected to all work together smoothly. One may view these types of projects as the easy projects where few problems are expected.

SOURCE : http://www.spr.com

138 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION

Heuristics Heuristics are rules of thumb. Heuristic approaches rely on the fact that the same

basic activities will be required for a typical software development project and these activities will require a predictable percentage of the overall effort (Roetzheim and Beasley 1998). For example, when estimating the schedule for a software development task one may, based on previous projects, assign a percentage of the total effort as follows:

30 percent Planning

20 percent Coding

25 percent Component Testing

25 percent System Testing In his book, Estimating Software Costs, T. Capers Jones provides a number of

heuristics or rules of thumb for estimating software projects based on function points. Some of these rules include:

• Function points raised to the 1.15 power predict approximate page counts for paper documents associated with software projects.

• Creeping user requirements will grow at an average rate of 2 percent per

month from the design through coding phases. • Function points raised to the 1.2 power predict the approximate number of

test cases created.

140 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION

Function points raised to the 1.25 power predict the approximate defect potential for new software projects.

Each software test step will find and remove 30 percent of the bugs that are present.

Each formal design inspection will find and remove 65 percent of the bugs present.

Each formal code inspection will find and remove 60 percent of the bugs present.

Maintenance programmers can repair eight bugs per staff month.

Function points raised to the 0.4 power predict the approximate develop ment schedule in calendar months.

Function points divided by 150 predict the approximate number of person nel required for the application.

Function points divided by 750 predict the approximate number of mainte nance personnel required to keep the application updated.

Multiply software development schedules by the number of personnel to predict the approximate number of staff months of effort.

Jones makes an important observation: Rules of thumb are easy, but they are not accurate. As Garmus and Herron point out (Garmus and Herron 1996):

Accurate estimating is a function of applying a process and recogniz- ing that effort must be expended in creating a baseline of experience that will allow for increased accuracy of that process. Estimating does not require a crystal ball; it simply requires commitment. (142)

Automated Estimating Tools

A number of automated tools can be used for cost, schedule, and resource estimation. These tools include spreadsheets, project management tools, database management systems, software cost estimating, and process or methodology tools. Many of these tools not only help estimate, but also allow the organization to create a database or repository of past projects. In fact, it was found that estimates usually have an accuracy of between 5 and 10 percent when historical data was accurate. Moreover, automated estimating tools are generally more conservative when they are not accurate, as opposed to manual methods that are generally optimistic (Jones 1998).

As the complexity of software development projects increases, the market for software estimation tools will increase as well. Some of the automated tools available include COCOMO II, SLIM, CHECKPOINT, Knowledge Plan, and Cost*Xpert. Research suggests that projects that use a formal estimating tool have a better chance of delivering a system that is on time and within budget.

WHAT IS THE BEST WAY TO ESTIMATE IT PROJECTS?

Unfortunately, no single method or tool is best for accurately estimating IT projects. It may be a good idea to use more than one technique for estimating. You will, however, very likely have two different estimates.

If the estimates from different estimating techniques are fairly close, then you can average them with a fairly high degree of confidence. If the estimates vary widely,

CHAPTER SUMMARY 141 then you should probably be skeptical of one or both estimates and review the data

that was collected (Roetzheim and Beasley 1998).

Your initial estimates probably will have to be adjusted up or down based on past experience or data from past projects. Many times, however, the initial estimates are negotiated by upper management or the client. For example, you may come up with an estimate that the project will take twelve months and cost $1.2 million. Unless you can substantiate your estimates, upper management may counter and mandate that the project be completed in eight months and cost no more than $750,000. This counter may be a result of a real business need (i.e., they really do need it in eight months and can not spend more than $750,000) or their belief that you inflated the schedule and budget and some of the fat can be trimmed from your estimates. As a result, you may end up working on a death march project.

It basically comes down to whether the project can or cannot be delivered earlier. It is up to the project manager not only to arrive at an estimate, but also to support the estimates. Otherwise, the project's schedule and budget can be very unrealistic. Working long hours and under intense pressure will surely have a negative impact on the project team. A project manager's team must always come first, and protecting them by having a realistic deadline and adequate resources as defined by the project's schedule and budget is the first step.

CHAPTER SUMMARY

Although defining a project's scope in terms of • Top-Down Estimating—This system involves estimat project-oriented and product-oriented deliverables

ing a schedule or budget based upon how long the proj provides an idea of what must be done, the project

ect or an activity should take or how much it should manager and team must still develop a tactical approach

cost. For example, the project manager may be told that determines what needs to be done, when it will be

that the project must be completed in six months. The done, who will do the work, and how long will it take.

project manager then schedules or estimates the proj The work breakdown structure (WBS) is an important

ect and activities backwards so that the total duration of the activities adds up to six months or less. Although

and useful tool for bridging the project's scope with the this approach may be used when competitive necessity detailed project plan. More specifically, the WBS

is an issue, unrealistic expectations can lead to projects provides a logical hierarchy that decomposes the project

with very little chance of meeting their objectives. scope into work packages. Work packages focus on a

• Bottom-Up Estimating—Most real-world estimating particular deliverable and include the activities required

uses this approach. The WBS outlines the activities to produce the deliverable. In addition, milestones

that must be completed, and an estimate is made for provide a mechanism for ensuring that project work is

each of the activities. The various durations are then not only done, but also done right.

added together to determine the total duration of the Once the work packages have been identified, pro-

project. Estimates may be analogous to other proj jected durations must be made. Instead of

ects or based on previous experience. These esti guesstimat-ing, or guessing at the estimates, a number of

mates are also a function of the activity itself (e.g., degree of complexity, structuredness, etc.), the

project estimation methods and techniques were resources assigned (e.g., a person's knowledge, introduced. Traditional approaches to estimating

expertise, enthusiasm, etc.) and support (e.g., tech include:

nology, tools, work environment, etc.). • The Delphi Technique—This approach involves mul

In addition, several software engineering tiple experts who arrive at a consensus after a series

approaches were introduced for estimating the software of round-robin sessions in which information and

opinions are anonymously provided to each expert. development effort. These included: • Time-Boxing—A technique where a box of time is

• Lines of Code (LOG)—Although counting or trying allocated to a specific task. For example, a team may

to estimate the amount of code that must be written

be given two weeks (and only two weeks) to develop may appear intuitively pleasing, there are a number

a prototype of a user interface.

142 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION of deficiencies with this approach. The number of

calculated, a similar procedure using another model can LOG may provide an idea of the size of a project, but

estimate the project's duration. • it does not consider the complexity, constraints, or

Heuristics—Heuristics are rules of thumb that are influencers that must be taken into account. Function

applied to estimating a software project. The basic Points—Function points were introduced by Allen

premise is that the same activities will be repeated on Albrecht of IBM in 1979. They are synthetic

most projects. This approach may include assigning a measures that take into account the functionality and

specific percentage of the project schedule to specific complexity of software. Because function points are

activities or using other metrics such as function points. independent of the technology or programming language used, one application system can be

Estimating the effort and duration of an IT project compared with another. COCOMO—The

is not an exact science. No single method or technique Constructive COst MOdel was introduced by Barry

26. Boehm in 1981. Estimates for a software systems tion of approaches may help triangulate an estimate,

will provide 100 percent accuracy. Using a combina-

effort are determined by an equation based upon the which provides a confidence greater than when project's complexity. More specifically, a software merely guessing or using a single estimation tech- project may be classified as organic (relatively simple

nique. To be realistic, estimates should be revised as and straightforward), embedded (difficult), or understanding of the project increases and new infor- semi-detached (somewhere in the middle). Once the

mation acquired.

effort, in terms of person-months, is

WEB SITES TO VISIT

www.softwaremetrics.com: Articles and examples www.ifpug.org: International Function Point Users for learning more about function point analysis

2. www.spr.com: The site for Software Productivity

Group

sunset.usc.edu/research/COCOMOII/index.html: Research. Capers Jones articles and information about

The latest version and information about COCOMO software estimation and planning tools for IT projects

REVIEW QUESTIONS

1. Describe the PMBOK area of project time manage

13. How is estimating an IT project different from esti ment.

mating a construction project?

2. What is a WBS? What purpose does it serve?

14. What makes estimating an IT project challenging?

3. Discuss why a project's scope must be tied to the

15. What is guesstimating? Why should a project man WBS.

ager not rely on this technique for estimating a

4. What is a work package?

project?

5. What is the difference between a deliverable and a

16. Describe the potential problems associated with milestone?

providing an off-the-record estimate?

6. What purpose do milestones serve?

17. What is the Delphi technique? When would it be an

7. What are some advantages of including milestones appropriate estimating technique for an IT project? in the WBS?

18. What is time boxing? What are some advantages

8. What is a crux? Why should the project manager and disadvantages of time boxing project activities? and project team identify the cruxes of a project?

19. Describe top-down estimating. What are some advan

9. What is the proper level of detail for a WBS? tages and disadvantages of top-down estimating?

10. Why should the WBS be deliverable-oriented?

20. Describe bottom-up estimating. What are some advan tages and disadvantages of bottom-up estimating?

11. Explain why people who do the work on a project should be involved in developing the project plan?

21. What is a death march project? What situations in

12. How does the concept of knowledge management project planning can lead to a death march project? support the development of the project plan?

EXTEND YOUR KNOWLEDGE 143 22. Discuss why adding people to a project that is

28. What is COCOMO?

already behind schedule can make it later? 29. Under the COCOMO model, describe the organic, 23. What is software engineering?

semi-detached, and embedded models. 24. Why is counting lines of code (LOG) a popular

30. What are heuristics? Discuss some of the advan method for estimating and tracking programmer

tages and disadvantages of using heuristics for esti productivity? What are some problems associated

mating IT projects.

with this method? 31. What can lead to inaccurate estimates? How can an 25. What is a function point? What advantages do func

organization improve the accuracy of estimating IT tion points have over counting lines of code?

projects?

26. How can function point analysis be used to help 32. What is the impact of consistently estimating too manage scope creep?

low? Too high?

27. What is backfiring? How could an organization use backfiring to improve the accuracy of estimating IT projects?

144 CHAPTER 6 / THE WORK BREAKDOWN STRUCTURE AND PROJECT ESTIMATION BIBLIOGRAPHY

Albrecht, Allan J. 1979. Measuring Application Development Pressman, R. S. 2001. Software Engineering: A Practitioner's Productivity. Proceedings SHARE/GUIDE IBM Applications Approach. Boston: McGraw-Hill. Putnam, L. H. 1978.

Development Symposium, Monterey, Calif., October 14—17, 1979.

General Empirical Solution to the Macro Brooks, F. P. 1995. The Mythical Man-Month. Reading, Mass.: Software Sizing and Estimating Problem. IEEE Transactions

Addison Wesley. Boehm, B. W. 1981. Software Engineering Software Engineering SE 4(4): 345-361. Putnam, L. H. and A.

Economics. Englewood Fitzsimmons. 1979. Estimating Software Costs.

Cliffs, N.J.: Prentice Hall. Brooks, F. P. 1995. The Mythical Datamation 25(Sept-Nov): 10-12. Rad, P. F. 2002. Project

Man-Month. Reading, Mass.: Estimating and Cost Management. Vienna,

Addison Wesley. Garmus, D. and D. Herron. 1996. Measuring the Va.: Management Concepts, Inc. Roetzheim, W. H. and R. A.

Software Process. Beasley. 1998. Software Project Cost and

Upper Saddle River, N.J.: Prentice Hall PTR. Haugan, G. T. 2002.

Schedule Estimating: Best Practices. Upper Saddle River, N.J.: Efffective Work Breakdown Structures. Vienna, Prentice Hall. Royce, W. 1998. Software Project

Va.: Management Concepts, Inc. Jones, T. C. 1998. Estimating

Management: A Unified

Defining and Managing Project Scope