CHAPTER 2 Project Management

Before we begin to discuss the application of the Earned Value Management System to projects, we will review some basic project management principles to ensure a common starting point. Experienced project managers may elect to skim this chapter. A common understanding of projects and their management provides the basic structure required to support EVMS.

Using project methods has become the recognized way to perform an organization’s work. After all, the work of most top executives primarily involves projects. The Project Management Institute, headquartered in the United States, and several comparable organizations in other parts of the world are dedicated to having project management achieve professional status through programs and constant updating of materials. In addition, many other professions recognize the desirability of project management knowledge. For example, the new Content and Skill Specification Outline for the Uniform CPA Examination, approved by the Board of Examiners and expected to take effect in future years, for the first time includes a section on project management (American Institute of Certified Public Accountants 2008, 30–31).

A PROJECT

A project is a unique production event in the life of an individual or organization. While similar events may have been accomplished in the past, the type of event, the people working on it, the deliverables, and the environment in which it takes place, or all of these elements, differentiate this event. A project can be as small as trying a new dinner recipe or as complex as constructing a space station—they all take planning, organization, and control. R.E. Westney, an engineer, suggests a definition of a project that we really like: “A project can be defined as the work required to take an opportunity and convert it into an asset” (Westney 2001, 128).

Setting out activities in an orderly way to accomplish a goal is the result of an orderly thought process that has been occurring as long as humankind has been recording history. Thomas P. Hughes wrote about four incredibly complex projects in his book Rescuing Prometheus (Hughes 1998). Hughes describes Prometheus as a mythological second creator and uses this reference to describe the transformation of our world from a natural state to a technological one. As these four enormous projects progressed, new ways of managing activities had to be developed. If your project seems overwhelming at times, read in Hughes’ book about some of the trials and accomplishments of the SAGE air-defense project, the Atlas missile project, the Boston Central Artery/Tunnel project, and the development of the Internet. From these projects came the inspiration for new technology, new organizational structures, and new management styles.

Most studies show that the majority of projects do not meet at least one criterion for the estimates of their original cost, schedule, or expected result. Indeed, the Boston project described by Hughes was popularly christened the “Big Dig” and later the “Big Leak.” It became infamous for its cost overruns and unsatisfactory management. Project goals will not be realized if the efforts to meet them are unrealistic, not approved, underestimated, or not planned, or if the project is not given adequate resources. Managing a project requires extensive planning and careful management using a consistent system.

A tremendous amount of material about project management has been published. The material is becoming fairly well defined as associations such as the Project Management Institute (www.pmi.org), the Association of Project Management (www.apm.org.uk), and the International Project Management Association (www.ipma.ch/intro) publish and continue to update their bodies of knowledge on project management.

A project is a temporary and unique activity. Projects are usually undertaken by extensions of the organization that existed before and will exist after the duration of the project. As we will see in later discussions of project organization, this typical organizational approach means that a project rarely has fully committed resources. Projects are not production-oriented, even though they might have a production component. They begin and end to fulfill a particular need. The features “temporary” and “unique” describe not only the project but also its organizational system. The resources assigned to a project do not usually make up a permanent functional unit; they are linked together in a constantly changing and evolving way.

THE PROJECT CHARTER

Many activities and documents are part of a project. The project charter is one of the first and one of the most important documents. It is the primary agreement between the organization requesting a product or service and the organization providing that product or service. The charter identifies the project stakeholders and the project team’s roles, responsibilities, and accountabilities. In other words, a charter establishes who will do what for whom.

The project manager should develop the project charter in cooperation with the project sponsor. It is not uncommon, however, for the project manager to draft the charter for the sponsor’s signature. The charter ensures clear communication about what is to be accomplished, the timeframe in which it will be completed, and the resource support that the project team can expect. The charter provides an overview created at the project’s initiation—before any detailed planning—and key stakeholders should sign the charter to indicate their approval.

The charter provides a brief description of the scope of the project and its objectives. Detailed specifications will be developed later in the planning process. Because the project charter typically becomes the basic reference document for large and/or complex projects, it also should discuss how the project will be structured, the acceptance criteria, and the processes for mitigating potential risks, resolving issues, and managing project changes. In addition, it is a good idea to specify project deliverables and conditions under which the project will end.

There are some generally accepted components that a project charter should contain. We have compiled an outline of typical items that should be included (Figure 2.1), but the size and complexity of the project will dictate the amount of detail for each entry. Your organization may have a template for constructing a project charter. If not, you may have to create a charter from scratch. Even for a small project, we recommend that you list some information for each of the standard headings shown in Figure 2.1, even if that information only cites a standard procedure.

Charters for large and complex projects undoubtedly will require the use of brief summaries and references to other documents that contain the detailed information. Charters for such projects also may contain information that could be considered part of the project planning that is completed after the initial project is approved. Examples include a Gantt chart, work breakdown structure, organizational breakdown structure, risk analysis and management, project control methodologies (including required progress reporting), quality control activities, plans for project support activities such as training and documentation assistance, project facilities and resource requirements, required interim approvals, and change control procedures. Although these elements are project requirements, they may be shown in the project charter as planning deliverables.

FIGURE 2.1 Essential Charter Elements

The term statement of work (SOW) is used in many different ways. Many times it is considered interchangeable with project charter; at other times it refers to a very detailed description of the activities required to fulfill the objectives of a low-level part of the project plan. We describe some different uses of the term in later chapters.

PROJECT LIFE CYCLES

The term life cycle probably became popular because most projects follow a very general pattern of investigation, approval, definition, resource assignment, implementation, and termination. We agree with Wideman (2004) that life span might be a more appropriate description. Your organization may have a standardized project pattern (life cycle) or may allow each project team to develop the pattern that its project will follow.

There have been many approaches to defining a generally accepted project life cycle. They all attempt to lend some standardization to the very difficult process of including all necessary elements of a successful project. Sometimes, generally accepted life cycles emerge for a particular industry. For example, several industry groups have established accepted standards that provide a structure for the processes of the software development life cycle from conception through termination.

The International Organization for Standardization (ISO)/International Engineering Consortium (IEC) 12207, created by committees of national representatives, and IEEE/EIA 12207, created by the Institute of Electrical and Electronics Engineers (IEEE) and the Electronics Alliance Industry (EIA), were developed with some of the same leadership and share the same life cycle process. The documents are very similar; IEEE/EIA incorporates ISO/IEC 12207 and adds a foreword, a series of annexes, and much more extensive guidance. The ISO/IEC standard is voluntarily followed by businesses in the United States, whereas the IEEE/EIA standard may be required for companies doing business with the Department of Defense (DoD).

The Basic Approach

We are all familiar with the age-old argument about how we should divide time between planning the project and doing the project. This basic debate is illustrated in Figure 2.2. Part a of the figure follows the thoughts “Do we waste our precious time planning?” and “We need to get started on the necessary work right away.” The second illustrates the idea that if your plan is thoughtful and complete, it will take less time to deliver.

FIGURE 2.2 A Time for Planning, a Time for Doing

We often hear the familiar exhortation, “Plan your work, and work your plan,” but how much time do we actually devote to planning? Hoping to reduce the constant variations normally encountered in meeting customer requirements, W. Edwards Deming originated a cycle for business planning and continuous improvement that is relevant for projects. It is described in some detail by Henry Neave (1990, 143). Deming’s cycle is commonly called the PDCA Cycle because it contains four primary elements: plan, do, check, and act (Figure 2.3). The model is applied in projects through attention to feedback, an essential element for all projects.

FIGURE 2.3 Deming’s Plan, Do, Check, and Act (PDCA) Cycle

A More Comprehensive Approach

One traditional pattern in software development projects is called the waterfall approach. The approach got its name because the activity cascades down a single line. The idea was to construct the software product with the same methodology used for hard products—a serial process (Figure 2.4). One of the major problems with this approach is that most projects require some iterative or review activities between stages and do not proceed continuously down the waterfall process. For many years, the software industry has been evolving the process to move from the waterfall model to a more modern, iterative development model.

FIGURE 2.4 Waterfall Development Model

An alternative approach that overcomes the lack of iterations in the typical waterfall model is the spiral development model. Barry Boehm (1988, 64) described this concept for a software development project, but it can be applied to any project that requires iterative stages. Each iteration in this model provides increasing capability. This concept is shown in Figure 2.5.

The model is divided into four quadrants representing the major phases of the management process: determine objectives, evaluate alternatives, develop/verify, and plan next phases. Beginning at the center of the spiral and moving clockwise, each transverse goes through each of the four management processes (resulting in the four prototypes) with increasing detail added at each loop. One caveat about using a spiral model is that you must limit the number of cycles, or the project will just keep going around in circles. As a project manager, especially if you tend to be a perfectionist, you need to learn the phrase “It’s good enough!”

There is often a conflict between those who would like to have a complete and detailed plan before any activity is started and those who prefer an iterative approach, with details only for the beginning of the project. For a large project using EVMS, it is very difficult to plan using the same level of detail over the entire project’s duration.

FIGURE 2.5 Boehm’s Spiral Development

Minimum Life Cycle Requirements

Regardless of the model used, it is helpful in the planning stage to divide the project into phases. Along with a controlling function that runs throughout the project, the four commonly accepted phases for the project life cycle are:

Initiation: the concept and initiation phase

Planning: the design and development phase

Execution: the implementation or construction phase

Closeout: the commissioning or termination phase.

It is important to note that each of these phases can be subphased using the same four phases, and the deconstruction can continue until you reach a desired level of detail.

Almost all discussions on project life cycles insist that there be checkpoints at each phase for evaluation, proposed change, and approval for continuation. For your projects, you may choose one of the models we have discussed or create one of your own; however, as our foray into the world of project life cycles shows, you can’t just dive in and do the work—even on a small project. That is where project management tools like EVMS enter the picture.

EVMS PROJECTS

EVMS specifically uses a work breakdown structure to delineate the authorized work elements of a project into identifiable pieces. A work package refers to a deliverable at the lowest level of the work breakdown structure and describes a work unit or one element of work in the project. There is an unusual but interesting example of the term work unit in the breakdown of the very unusual distributed computing project for the SETI program, which searches for signals of extraterrestrial life. Ksetiwatch is a monitoring tool that logs and manages all the sessions that are assigned to home computers for the project participants. The program appropriately calls these participant sessions work units (SETI@home 2005).

Of course, in a book on earned value that has a great deal to do with metrics, the importance of project measurements must be emphasized early in our discussion. You’ve certainly heard the expression “What gets measured gets done” or “You can’t manage what you can’t measure.” People always find a way to deal with the way they are being measured, so it is most important to have measurements that will promote desired rather than dysfunctional behavior.

We need measurements to understand how well we are meeting the estimates for all projects. We need to measure—even if it is done informally—progress in time (schedule), cost (budget), scope (requirements), and quality to know where we are and how closely we are following the project plan. It is necessary to rely on metrics to communicate information, from the use of a simple three-color “traffic light” approach to a complete EVMS. We also use measurement information to help develop corrective actions when we are off track and to predict where we will be at the end of the project.

In general, and especially with EVMS, a metric used to communicate progress may not be the best metric for developing corrective action plans. Measurements are designed to provide a basis for decisions and are reported to project owners so they can make priority and resource allocation decisions. The same measures are seldom useful in making corrective-action decisions on project work. Very often a metric tells us where we are but does not give us any indication of what to do.

Metrics cannot replace experience and good judgment. Poor project management generates poor EVMS data. Just as costs cannot be reduced by focusing on the costs instead of focusing on the processes that generate them, EVMS metrics cannot be improved by trying to directly influence the metrics. Instead, you must focus on the project processes that generate the metrics.

THE PROJECT MANAGEMENT OFFICE

The use of project management processes for accomplishing more of the work of an organization is rapidly increasing. This concept has become known by such names as managing by project and enterprise project management. A slightly different concept, project portfolio management (PPM), is about managing all the projects in the organization; however, that does not mean that the organization is managed by projects. Many organizations have adopted an organizational concept called a project management office (PMO) to deal with the growing phenomenon of project portfolio management. The basic functions of the PMO are summarized in Figure 2.6.

FIGURE 2.6 Project Management Office (PMO) Functions

If you are involved in establishing or operating a PMO, you should be aware that not everyone will appreciate the benefits of such an office. Be sure to publicize the PMO’s mission as one that will support the entire organization and will not serve merely as the project police. In trying to address all concerns up front, be aware that you may be required to deal with different and sometimes very personal agendas. To counteract these forces, the PMO must have firm senior management commitment and support.

A team of senior-level representatives from each functional area, with representation by the PMO, is the control behind PPM. This team sets the policies that the PMO will follow. One of the biggest challenges to successful project management is that the project resources most often are owned by various functional departments and not by the project managers. It is easier to apply these resources to the most strategic projects if there is a portfolio management process in place.

An often-unrecognized challenge is managing the number of projects that the organization has active at any given time. The prevailing management thought is the more projects in the pipeline, the busier everyone will be and the more projects will be completed. Whenever an opportunity arises, it is tempting to start a project right away; once it is started, everyone involved will be pressured to keep the project active by reporting its progress.

A great deal of anecdotal evidence strongly indicates that when resources are stretched, efficiency and effectiveness are drastically reduced. In general, the more projects in the pipeline, the longer it will take for any one project to finish because resources are rarely sufficient to complete work on one task or project without interruption.

The selection, prioritization, and termination of projects are very important functions of PPM. Having a balanced view from outside the project management function (including the PMO) can allow you to concentrate on potential overall value and control the number of projects in order to better accomplish resource utilization and quicker returns. An analysis from a PPM team of the strategic value of projects will eliminate most of the parochial interests too often used as selection criteria.

The PPM team may use a risk/benefit grid to be more selective and to ensure a balanced project selection. Figure 2.7 illustrates a simple risk/benefit decision grid with example projects located at various points within the grid. A continuing risk/benefit analysis should be made for each project after every major phase. Early termination can be as valuable as appropriate selection and initiation.

FIGURE 2.7 Simple Risk/Benefit Grid

A great deal of software is available to help with both PPM and enterprise project management. An Internet search on either term will provide voluminous data about these vital components of project management.

EVOLVING PROJECT MANAGEMENT MATURITY

Public literature and the media abound with personal improvement schemes. We all want to be better at something—our appearance, our job performance, our relationships, something. You probably want to be a better project manager, or you wouldn’t be reading this book! Organizations, too, should have a plan to continuously improve their ability to gather the right measurements, construct realistic plans, and exploit their constraints.

Several tools and programs offer guidance in improving an organization’s project management maturity. They are designed to move an organization’s processes from an unpredictable, sometimes chaotic state to a disciplined process of continuous improvement. Most of the models include four basic steps:

1.An early learning phase

2.The integration of lessons learned with processes

3.A reengineering of the business processes

4.Moving to a new phase of maturity.

Maturity models are becoming more sophisticated as they are updated over time. A detailed explanation of improvement programs is beyond the scope of this book, so we have provided the following abbreviated list if you wish to investigate further:

Organizational Project Management Maturity Model (OPM3R), second edition (Project Management Institute 2008b). The standard details knowledge, assessment, and improvement elements and probably is the most comprehensive treatment for projects.

CMMI-ACQ, V1.2 Capability Maturity Model Integration for Acquisition Software. This document addresses specific and generic practices for both capability levels and maturity levels. Capability levels include incomplete, performed, managed, defined, quantitatively managed, and optimizing (numbered from Level 0 to Level 5, respectively); maturity levels include initial, managed, defined, quantitatively managed, and optimizing (numbered from Level 1 to Level 5, respectively) (Software Engineering Institute 2007, 22).

Project Management Maturity Model, second edition (Crawford 2006). In addition to covering the usual five levels of maturity, this second edition provides a comprehensive framework for continuously improving project management skills and results.

ISO 9001:2008 Quality Management Systems (International Organization for Standardization 2008). In this family of standards, most of the standards are highly specific, but they are considered generic management system standards because they can be applied across almost all sectors of business, industry, and technology.

A maturity model—The Earned Value Management Maturity Model or EVM3 (Stratton 2006)—also has been developed for EVMS itself. The EVM3 and its key process areas are described fully in Stratton’s book.

The objective of all of these models is to continually enhance the project delivery processes of the organization, with the goal of reaching a consistent level of success.

THE PROJECT MANAGER

Successfully managing a project has a set of very demanding requirements, including organizational ability, communication skills, leadership, persistence, consistency, hard work, and a system (think EVMS). Too often, we expect the best technical person in a particular area to be the most capable of managing a project in that area. It is true that technical knowledge may be required for a project, but that knowledge does not necessarily have to be possessed by the project manager, who must exhibit all the skills of a successful salesperson, a disarming negotiator, a clear communicator, and a charismatic leader. A perfect example is the coach of a winning athletic team made up of individual stars.

The most important characteristic for a project manager is goal orientation. All human beings have an innate desire to achieve goals—even our games have goals. Numerous journal articles and books have been written on the subject. One such book is even called The Goal: A Process of Ongoing Improvement (Goldratt and Cox 1992).

Establishing a baseline in EVMS has very practical benefits for a project’s goals. Beyond the obvious benefits, working toward a goal is a major motivational factor for the project team. Locke and Latham developed this idea in their goal-setting theory (Locke et al. 1990).

One of the project manager’s greatest challenges is dealing with many different people both inside and outside the organization. To further complicate matters, some of them will be managers of functional areas who control resources that affect the project. The project manager’s degree of power and authority depends to a great extent on the organizational structure.

Organizational structures are generally considered functional, matrixed, project-oriented, or some combination of the three. Of course, the project manager will find the most organizational power in project-oriented structures. (Organizational structures are covered in detail in Part III, where we discuss EVMS Criterion 2.)

THE PROJECT TEAM

When you have the authority to choose team members, you must be very careful to resist selection by reputation alone. Sometimes personal reputations are developed at the expense of others. Remember that your project will be evaluated not on the reputation or popularity of its team members but on its results. Herb Brooks, the coach of the U.S. 1980 Olympic gold medal hockey team, often said that he did not want the “best” players—he wanted the “right” players.

A manager once told us that the ideal player has four traits: intelligence, professional skills, a pioneering spirit, and a hint of excellence in innovation and creativity. Having team members with diversity in both their work backgrounds and skills will foster your team’s inventiveness and creativity. In today’s more competitive marketplace, the old ways of working no longer ensure success.

For all team members to be on the same page, the project manager must communicate with them and not just establish rules. The project’s mission statement is a perfect example. The team must understand what it is trying to accomplish; therefore, it is necessary to hold straight-to-the-point discussions of the project’s objectives and what will be required to accomplish them. Some questions that need to be asked and answered are:

Why are they on the team?

What are they individually expected to accomplish?

How must they operate differently?

You may find it useful to construct a team charter establishing the team’s operating assumptions and rules.

In our efforts to improve team performance, we have spent a substantial amount of time looking at the problems experienced by teams. If you are interested in learning more about teams, we recommend Lencioni’s Five Dysfunctions of a Team, in which he lists absence of trust, fear of conflict, lack of commitment, avoidance of accountability, and inattention to results as the most significant problems affecting team effectiveness (Lencioni 2002, 240). Kerzner (2005) and Flannes and Levin (2001) have some interesting material in their chapters on resolving conflict for project managers that you will find very helpful. For a more positive approach, try Glickman’s Optimal Thinking (Glickman 2002).

One more term, expectation, must be mentioned. Although you will not usually find this term in project management journals, we think it is one of the most important aspects of team leadership. Our good friend Harry Morgan coached a very successful high school football team for many years. His secret was not hard-driving discipline, expert football strategy, or rigorous conditioning (although these also were part of his philosophy); his teams executed well because that was what he expected.

Joe Batten—author, speaker, trainer, one of the authors’ mentors, and the person who created the U.S. Army tagline “Be all you can be”—often said that the finest gift we can give another person is a stretching expectation of excellence. One of his numerous publications that we refer to often is Expectations and Possibilities (Batten 2003).

DISCUSSION QUESTIONS

1.Discuss the following statement: “The processes of performing repetitive manufacturing processes and project management are entirely different.”

2.In your experience, what is the major reason that a project succeeds in delivering on time, on budget, and with full specifications?

3.Are charters necessary for internal projects?

4.How long and detailed should a charter be?

5.Why is it important to understand project life cycles?

6.Describe your organization’s project life cycle template. If none exists, how would you initiate one?

7.In general, what percentage of total project time should be consumed in planning the project?

8.Respond to the following statement: “Earned value is primarily a project management philosophy.”

9.What are the major objectives of a project management office (PMO)?

10.What is the major purpose of project maturity models?

11.Discuss the following statement: “Project managers have power only through their position.”

12.Describe your ideal project team.