Quantitative Tools of Project Management

David L. Olson

• Publisher: Business Expert Press
• Year: 2020
• Print ISBN: 9781951527839
• eBook ISBN: 9781951527846
• Topic: Business
• Subtopic: Project Management
• Index: Business

This book addresses the use of quantitative tools to support general project management.

Part I of the book deals with critical path modeling. Part II discusses risk modeling tools to include Program Evaluation and Review Technique (PERT), critical chain modeling, and agile/scrum approaches. Project control through earned value analysis is also covered. Part III is a Microsoft Project orientation. A feature of the book is an effort to tie content to that of the Project Management Body of Knowledge (PMBOK).

Each chapter includes reference to how each chapter relates to the PMBOK structure and its relationship to the 2020 Project Management Professional (PMP) Exam Outline.

CHAPTER 1

Estimation

Key points:

• Discussion of the estimation process through development of work breakdown structure
• Coverage of organization, scheduling, and control concepts
• Demonstration of three approaches to estimating information systems projects, with the intent of showing broad outlines of how estimation could be accomplished in other fields

Once a system is developed, more detailed estimation is required. At the strategic level, macro estimates were used to evaluate the project for approval. As the project moves to requirements analysis and determination of feasibility, more accurate estimates are possible as more detailed planning is conducted. During the planning process, detailed tasks (things to do—deliverables) and milestones (completed project module elements, resulting in a completed, functioning system) are identified. This chapter discusses the planning process, as well as factors important in information system project estimation. Several quantitative methods of software project estimation are explained.

The chapter demonstrates concepts using information systems project contexts, but other projects have similar features. For instance, in construction the human emphasis of information systems projects is less dominant, relying more on equipment and materials. Both contexts often rely on subcontracting in various forms. But the principles demonstrated are transferable. Two dominant estimating methods are demonstrated. In information systems, lines of code utilize some broad metric, whereas function point (FP) analysis focuses on types of activities. Regression has been used in information systems estimation, and also has been applied in construction, but care needs to be taken in both contexts to obtain accurate data.

Planning Process

Information systems projects have high levels of uncertainty. The size of the project is usually not well understood until systems analysis has been completed. Most of the unexpected delay in these projects occurs during the latter stages of testing, late in the project. Systems builders tend to report projects as on time and budget targets until the last stages of testing. But at this point, most projects are found to require additional work, often substantial in scope.

Information systems projects have several unique factors that lead to high variability in project durations, including variances in the productivity across people for specific work, and in the technology used. Resources available are often not known at the beginning of a project. Many specific resources may be planned for use on a project during the planning stages, but months later other events may arise that make it impossible to use the best people on a project.

The planning process consists of a number of steps, including the following:

• Set objectives and requirements—determining requirements
• Specify work activities—identifying specific work to be done
• Plan project organization
• Develop the schedule
• Control points—establish control mechanisms to include budgeting resources

Set Objectives and Requirements

The first step is to determine requirements. Project objectives are set in the early stages of project proposals. Once these objectives are identified, the measures of accomplishment needed to identify successful completion of the project have to be established. These are the standards for each element of the project. In building a bridge, this would be the carrying capacity of the structure. In terms of information systems projects, this would be a statement of what the final project is ultimately supposed to do.

A statement of work, can be viewed as a contract between the information systems development team and project end users (see Figure 1.1). The statement of work can contain product descriptions, discussion of project constraints, schedule requirements, budget limits, and an explanation of the roles and responsibilities of project participants.

Figure 1.1 Statement of work

Constraints under which the system must be developed should be identified early in the project. These include time parameters, such as deadlines. The project may have to be accomplished within existing skill levels. Levels of project complexity can be specified. Budgets are an important resource limitation. Technology might be imposed, such as using Computer-Aided Software Engineering (CASE) tools. Interoperability opportunities, such as the availability of proprietary or open systems, may be specified.

Specify Work Activities

A work breakdown structure is a top-down hierarchical chart of tasks and subtasks required to complete the project (see Figure 1.2). The work breakdown structure can be focused on a product, a function, or anything describing what needs to be accomplished. The work breakdown structure is hierarchical, in that different levels of detail can be described. The overall project consists of a set of major activities, or project subelements. The schedule consists of a set of tasks, usually denoting work done by a specific worker or work group. This is usually the lowest level of project activity that is used for planning. In Figure 1.2, task “System Design” is a major task with four subelements at two levels. Subactivity “Design Software System to Support Work Process” consists of three unique subactivities. Task “Installation” consists of only one level of five activities. For large projects, quite a few levels in the work breakdown structure hierarchy may be required.

Figure 1.2 Work breakdown structure

A detailed task list is a listing of unique work packages briefly describing work to be done. The detailed task list also includes the assignment of responsibilities by job title and predecessor relationships. P...

Table of contents

• Cover
• Halftitle Page
• Title Page
• Copyright Page
• Contents
• Preface
• Chapter 1 Estimation
• Chapter 2 The Critical Path Method
• Chapter 3 Project Crashing
• Chapter 4 Probabilistic Scheduling Models
• Chapter 5 Critical Chain Project Management
• Chapter 6 Project Control and Assessment
• Chapter 7 Microsoft Project
• Glossary
• About the Author
• Index
• Backcover