PROJECT CONTROL

CHAPTER ONE P CO PY RI GH TE D Peter Harpum MA TE RI AL PROJECT CONTROL roject control is about ensuring that the project delivers what it is set up to deliver. Fundamentally, the process of project control deals with ensuring that other project processes are operating properly. It is these other processes that will deliver the project’s products, which in turn will create the change desired by the project’s sponsor. This chapter provides an overview of the project control processes, in order to provide the conceptual framework for the rest of this section of the book. Introduction Control is fundamental to all management endeavor. To manage implies that control must be exercised. Peter Checkland connects the two concepts as follows: The management process. . .is concerned with deciding to do or not to do something, with planning, with alternatives, with monitoring performance, with collaborating with other people or achieving ends through others; it is the process of taking decisions in social systems in the face of problems which may not be self generated. Checkland, 1981 In short to • plan • monitor • take action 1 2 The Wiley Guide to Project Control One may ask what is the difference between project control and any other type of management control? Fundamentally there is little that project managers must do to control their work that a line manager does not do. Managers of lines and projects are both concerned with planning work; ensuring it is carried out effectively (the output from the work ‘‘does the job’’) and efficiently (the work is carried out at minimum effort and cost). Ultimately, managers of lines and projects are concerned with delivering what the customer wants. The line management function is usually focussed on maximizing the efficiency of an existing set of processes—by gradual and incremental change—for as long as the processes are needed. The objective of operations management (or ‘‘business–as–usual’’) is rarely to create change of significant magnitude. Projects, on the other hand, are trying to reach a predefined end state that is different to the state of affairs currently existing; projects exist to create change. Because of this, projects are almost always time-bound. Hence, the significant difference is not in control per se, but in the processes that are being controlled— and in the focus of that control. Project management is seen by many people as mechanistic (rigidly follow set processes and controlled by specialist tools, apropos a machine) in its approach. This is unsurprising given that the modern origins of the profession lie in the hard-nosed world of defense industry contracting in America. These defense projects (for example, the Atlas and Polaris missiles) were essentially very large systems engineering programs where it was important to schedule work in the most efficient manner possible. Most of the main scheduling tools had been invented by the mid-1960s. In fact, virtually all the mainstream project control techniques were in use by the late 1960s. A host of other project control tools were all available to the project manager by the 1970s, such as resource management, work breakdown structures, risk management, earned value, quality engineering, configuration management, and systems analysis (Morris, 1997). The reality, of course, is that project management has another, equally important aspect to it. Since the beginning of the 1970s research has shown that project success is not dependent only on the effective use of these mechanistic tools. Those elements of project management to do with managing people and the project’s environment (leadership, team building, negotiation, motivation, stakeholder management, and others) have been shown to have a huge impact on the success, or otherwise, of projects (Morris, 1987; Pinto and Slevin, 1987—see also Chapter 5 by Brandon. Both these two aspects of project management—‘‘mechanistic’’ control and ‘‘soft,’’ people-orientated skills—are of equal importance, and this chapter does not set out to put project control in a position of dominance in the project management process. Nevertheless, it is clear that effective control of the resources available to the project manager (time, money, people, equipment) is central to delivering change. This chapter explains why effective control is fundamentally a requirement for project success. The first part of the chapter explains the concept of control, starting with a brief outline of systems theory and how it is applied in practice to project control. The second part of the chapter outlines the project planning process—before project work can be controlled, it is critical that the work to be carried out is defined. Finally, the chapter brings project planning and control together, describing how variance from the plan is identified using performance measurement techniques. Project Control 3 Project Control and Systems Theory Underlying control theory in the management sciences is the concept of the system. The way that a project is controlled is fundamentally based on the concept of system control—in this case the system represents the project. Taking a systems approach leads to an understanding of how projects function in the environment in which they exist. A system describes, in a holistic manner, how groups are related to each other. These may, for instance, be groups of people, groups of technical equipment, groups of procedures, and so on. (In fact, the systems approach grew out of general systems theory, which sought to understand the concept of ‘‘wholeness’’—see Bertalanffy, 1969.) The systems approach exists within the same conceptual framework as a project; namely, to facilitate change from an initial starting position to an identified final position. The Basic Open System A closed system is primarily differentiated from an open system in that the former has impermeable boundaries to the environment (what goes on outside the system does not affect the system), while the latter has permeable boundaries (the environment can penetrate the boundary and therefore affect the system). In a closed system, fixed ‘‘laws’’ enable accurate predictions of future events to be made. A typical example of this is in physical systems (say, for instance, a lever) where a known and unchanging equation can be used to predict exactly what the result will be of applying a force to one part of the system. Open systems do not allow such accurate predictions to be made about the future, because many influences cross the boundary and interact with the system, making the creation of predictive laws impossible. The key feature of the open system approach that makes it useful in the analysis and control of change is that the theory demands a holistic approach be taken to understanding the processes and the context they are embedded in. It ensures that account is taken of all relevant factors, inputs or influences on the system, and its environmental context. Another key feature of an open system is that the boundaries are to a large extent set arbitrarily, depending on the observer’s perspective. Moreover, wherever the boundaries are placed, they are still always permeable to energy and information from the outside. It is this quality that allows the relationships between the system and its environment to be considered in the context of change, from an initial condition to a final one. A critical part of this theory that is useful when considering management control is that the open system always moves toward the achievement of superordinate goals. This means that although there may be conflicting immediate goals within the creative transformation process(es), the overall system moves toward predefined goals that benefit the system as a whole (see Katz and Kahn, 1969). In a project system these goals are the project objectives. In simple terms the basic open system model is shown in Figure 1.1. The Open System Model Applied to Project Control If the generic system diagram is redrawn to represent a project and its environment, the relationship of control to planning (how the project is going to achieve its objectives) can be made clear (see Figure 1.2). 4 The Wiley Guide to Project Control FIGURE 1.1. THE BASIC SYSTEMS MODEL. Matter/ energy return Maintenance boundaries Inputs from environment Creative transformation Outputs into environment Maintenance boundaries Feedback The system: A set of components that are The creative transformation: The process(es) that act interrelated, acting in a unified way, to achieve a on the energy, resources, and materials from the goal. environment to turn inputs into outputs. Inputs: Energy, resources, and materials from the Outputs: Products, knowledge, or services that help the environment. system achieve its goals. Maintenance boundaries: The mechanism that Matter/ energy return: Matter and energy are returned to defines the transformation process(es)—and the environment in order to ensure the system remains in therefore creates the system’s unique identity. equilibrium. Feedback: The feedback required to ensure The environment: These are all the influences that act on the system stays on course to deliver its the system, and the control system attempts to mitigate. goals. Source: After Jackson (1993). The value of the open system model of the project shows how the ‘‘mechanistic’’ control meta process attempts to ensure that the project continues toward achievement of its objectives and the overall goal. The ‘‘softer’’ behavioral issues are evident throughout the project system: within the project processes, acting across the permeable boundaries with the project stakeholders and wider environment, and indeed around the ‘‘outside’’ of the project system but nevertheless affecting the project goal—and hence the direction the project needs to move in to reach that goal. The boundaries of the project are defined by the project plans. These plans define what the project processes need to do to reach the system’s goals (defined by the project’s environment). The plans also determine where in the organizational hierarchy the project exists, because projects have subsystems (work packages) and exist within a supra-system (programs and portfolios of projects). This is shown in Figure 1.3. 5 Project Control FIGURE 1.2. THE PROJECT AS A SYSTEM. Interaction with the project’s environment The project plans Resources from environment The project — creating change Deliverables into environment The project plans Information feedback creating management control actions FIGURE 1.3. THE HIERARCHICAL NATURE OF PROJECT CONTROL SYSTEMS. Business as usual Business planning process Portfolio control process The Portfolio Portfolio planning process Program control process Program 1 Program 2 Program planning process Project control process Project A Project B Project planning process Work package X Work package Y Work package control process 6 The Wiley Guide to Project Control To make the distinctions clear between portfolio and program, their definitions are listed in the following, elaborated for clarity from the Association for Project Management Body of Knowledge, 4th edition (APM, 2000): Program management Portfolio management Often a series of projects are required to implement strategic change. Controlling a series of projects that are directed toward a related goal is program management. The program seeks to integrate the business strategy, or part of it, and the projects that will implement that strategy in an overarching framework. In contrast to a program, a portfolio comprises a number of projects, or programs, that are not necessarily linked by common objectives (other than at the highest level), but rather are grouped together to enable better control to be exercised over them. The feedback loop measures where the project is deviating from its route (the plans) to achieving the project goals and provides inputs to the system to correct the deviation. Control is therefore central to the project system; it tries to ensure that the project stays on course to meet its objectives and to fulfill its goals. The deviation away from the project’s goals can be caused by suboptimal project processes (poor plan definition, for instance) or by positive or negative influences from the environment penetrating the permeable boundaries and affecting the processes or goal (poor productivity, failures of technologies to perform as expected, market changes, political influence, project goals being changed, and a host of similar inputs). At each of these levels of management there is a planning process. This process ensures alignment between objectives of work at different levels, for example, between programs and projects—the program plan. Consequently, the control of these systems is hierarchical in nature. The abstract models described so far can be used to diagrammatically show the overarching project control process, in which all the system elements are combined. This process is shown in Figure 1.4. In this diagram the way in which the project life cycle stages of initiate (define objectives), plan, and implement (carry out work) are overlaid with the control process is clearly shown. The next part of this chapter describes how the project plan is developed; that is, how the project system is defined. Defining the Project Objectives The clear and unambiguous definition of project objectives is fundamental to achieving project success. However, prior to project definition it is necessary to understand the business strategy, or at least that part of the strategy, being delivered (or facilitated) by the project. If the strategic goal is not understood, there is little chance of the project’s objectives being accurately defined. There are various definitions of strategy, viz: 7 Project Control FIGURE 1.4. THE PROJECT CONTROL PROCESS. Define project objectives Scope of work Schedule Budget Plan project: • Deliverables to achieve project objectives • Forecast time to carry out work • Forecast cost to carry out work Revise and update plan Measure performance of project Carry out work Monitor work against plan Implement control actions Deliverables • ‘‘Strategic thinking is the art of outdoing an adversary, knowing that the adversary is trying to do the same to you’’ (Dixit and Nalebuff, 1991). • ‘‘. . .the general direction in which the [company’s] objectives are to be pursued’’ (Cleland and King, 1983). • ‘‘ . . . strategies embrace those patterns of high leverage decisions (on major goals, policies, and action sequences) which affect the viability and direction of the entire enterprise or determine its competitive posture for an extended period of time’’ (Quinn, 1978). Business strategies have dual functions; firstly to communicate the strategy at a detailed level and identify the method of implementation (in part by programs and projects), and secondly to act as a control device. Both of these functions rely on the strategy having the characteristic of a plan—in other words, strategy is represented in a decomposed and articulated form. The communication aspect of the program informs people in the organization (and those external to it) of the intended strategy and the consequences of the strategy being implemented. They not only communicate the intention of the strategy but also the role that the employees have to take in its implementation (project, nonproject, or business-asusual work). The control aspect of the strategic program assesses not only performance toward the implementation of strategy but also behavior of the organization as the strategic actions take effect—has the behavior of the firm adjusted as predicted by the strategy? This then forms the feedback loop anticipated in the control system. See Figure 1.5. 8 The Wiley Guide to Project Control FIGURE 1.5. MECHANISM FOR ACHIEVING STRATEGIC CHANGE. Portfolio of Projects Business strategy The world Nonprojects Consequence Business as usual Feedback to business strategy Business strategy provides two or three high-level project objectives, and from these are developed additional project specific objectives and the project strategy. Traditionally, project objectives have been defined in terms of the ‘‘project triumvirate’’ of time to complete, cost to complete, and adherence to technical specifications (i.e., quality) (Barnes, 1988). This does not mean that other objectives should not be considered. Objectives for a project to build an oil platform, for example, could be stated as follows: Primary objectives • • • • Safety. Minimum number of accidents Operability. Minimum number of days downtime Time. Maximum acceptable duration before start-up Cost. Through-life cost for maximum business benefit Secondary objectives • Reliability. Minimum number of failures per month • Ease of installation. Non-weather-dependent process • Maintainability. Minimum number of maintenance staff required It is important to reduce uncertainty to the minimum for a project, and setting clear and prioritized objectives is a fundamental part of this process. However, sometimes changes to the objectives become inevitable. Occasionally the environment changes unexpectedly—for example, new legislation may be introduced; economic conditions may change; business conditions may alter. That this may happen is not necessarily in itself a bad thing, or a failure of either the sponsoring organization’s management or project management. Such Project Control 9 changes may impact on the organization, and its projects, to such an extent that organizational strategy has to be changed and projects either canceled or their objectives changed to meet the needs of the new strategy. Planning the Project The essence of project planning is determining what needs to be created to deliver the project objectives (the project deliverables or products), and within what constraints (of time, cost, and quality). Although this may seem like a statement of the obvious, many projects still fail to meet some or all of their objectives because of inadequate definition of the work required to achieve those objectives. Planning must also consider multiple other factors in the project’s environment if it is to have any real chance of success—the critical success factors discussed later in the chapter. There are a number of processes that need to be followed to plan projects effectively (see Project Management Institute, 2000): • • • • • • • • • Define the deliverables Define the work packages Estimate the work Schedule the work packages Manage resource availability Create the budget Integrate schedule and budget Identify key performance indicators Identify critical success factors Each of these processes are briefly described in this section of the chapter (and are described in detail in subsequent chapters of the book). Defining the Deliverables Projects are run to create change, and the change is defined by the objectives set for the project. The way in which objectives are achieved is by organizing work (the creative transformation from the basic systems model) to deliver tangible and intangible products into the environment that is to be changed. Therefore, it is central to project success that the specific set of deliverables required is understood and articulated. This set of deliverables forms the project scope. Accurately defining the project scope entails five subprocesses. Each of these process steps can be highly specialist in nature for projects delivering sophisticated products or services. For this overview chapter they are described briefly in the following paragraphs. The first of these subprocesses is requirements definition—understanding what is required to create the change required from running the project. Requirements are ‘‘needs’’ to be satisfied; they are not the solutions to deliver the change (Eisner, 1997). They are the essential starting point for determining what deliverables need to be made by the project. 10 The Wiley Guide to Project Control Poor requirements definition and management has been found to be one of the primary contributory factors leading to project failure. There is little point in managing a project perfectly if the project’s deliverables do not solve the right problem, or provide the necessary capability to the organization. Requirements definition consists of the following elements: Gathering the project requirements Assessing the requirements This is partly art and partly science (considered by many to be more art usually), particularly when seeking to draw out from the project stakeholders and document as complete a set of desired requirements as possible. The analysis and definition of business and technical requirements to assess the • project’s and organization’s technical capability to deliver them • priorities of the project’s requirements, taking into consideration —the perceived importance of each requirement to create the change needed —the availability of resource (time, people, money, materials) to deliver the requirements —the technical capability to deliver the requirements (the requirements may be unachievable technically) —the risk profile that the project is able to manage effectively Creating an adequate testing regime It is often necessary to iterate the assessment to get a set of requirements that will deliver the entire change desired. In order to be sure that all the conditions to create the change have been met, it must be possible to test that the requirements have been satisfied. In order for requirements statements to be used efficiently they should be Structured Traceable Testable The project requirements should be clearly linked to the need to create change, and this is done through matching requirements to objectives. It should be possible to identify the source of each requirement and trace any changes to the requirements definition, and of the emerging solution to the requirements, as the project evolves. There should be clear acceptance criteria for each requirement. After defining the requirements a number of conceptual designs are created, the options for delivering the change. This process is highly creative and seeks to find efficient solutions to meet the requirements. Whenever solutions are being sought, there are always trade-offs to be considered. Each solution will have with it a set of constraints in terms of what resource is needed to create the solution; that is to say, each solution will have different needs for 11 Project Control money, people, time, and materials. The point of generating a number of solutions is to enable decisions to be taken on what is the most effective trade-off to make for satisfying the project requirements and hence delivering the change required of the project. At this point the concept design decision gate is reached—the various concept design options are analyzed in the context of the change that is required to be delivered by the project. There will usually be an economic analysis to determine the following: • • • • Financial viability of each option Schedule to deliver the solution Technical capability of the project organization to create the solution Availability of suitable materials to create the solution When the decision is made, it is important that the complete set of deliverables defined by the concept design is clearly documented. Once the concept design has been selected, the deliverables that form that design must be specified—the exact details of the particular set of deliverables must be established. This is obviously important for those carrying out the work to make the deliverables. It is also fundamental to the control process (Reinertsen, 1997). It is against this specification that the project deliverables will be measured; have the deliverables created by the project been made as specified? (This is part of the quality management process). As with the previous subprocesses involved in defining the scope, specifying deliverables can be a complex and sophisticated task. There are essentially two ways to specify a deliverable: Performance specification Detailed specification This type of specification is stated in terms of required results, with criteria for verifying compliance—without stating methods for achieving the required results. (At a work package level the performance specification defines the functional requirements for the deliverable, the environment in which it must operate, and the interface and interchangeability requirements.) The opposite of a performance specification is a detail specification. A detail specification gives design solutions, such as how a requirement is to be achieved or how an item is to be fabricated or constructed. After the project scope has been defined as described to this point, a final process to manage change to the scope must be established. Scope change control is a critical part of the overall project control meta process. Projects frequently suffer from poor scope change control, leading to the wrong deliverables being produced by the project, which means failing to satisfy the project requirements and ultimately, of course, not delivering the change that the project was set up to create. For this reason, change control is considered one of the ‘‘iron rules’’ of effective project management. 12 The Wiley Guide to Project Control It is also important to realize that scope change is sometimes inevitable within the life cycle of a project. Defining requirements is dependent on having information available on what change the project is set up to achieve. It is rare that all this information is available at the beginning of the project; more usually, as the project scope is developed, additional information becomes available on the true nature of the project requirements, which means that changes to the scope are required. The management of this scope change needs to be thorough and strictly controlled (Project Management Institute, 2000; Dixon, 2000). The change control process incorporates the following elements: Identifying changes to scope Assessing the need for the scope change Accepting or rejecting the scope change request Adjusting the project plan What new or changed deliverables are required to meet the newly identified, or more clearly understood, requirement. It also includes transmitting the request for scope change to the project’s management. This includes deciding whether the change requested is genuinely needed to meet the requirements, any implications on the entire set of project deliverables, and the impact on project constraints (time, money, people, material). This includes documenting the reasons for the decision and communicating the changed set of deliverables (or that part of the deliverables changed) to those making them and to other project stakeholders. This is done to take account of the changed set of deliverables (meaning changes to budget, schedule, people carrying out the work, etc.). FIGURE 1.6. EASE OF CHANGE COMPARED TO COST OF CHANGE OVER THE PROJECT LIFE CYCLE. Ease of change/Cost of change Cost of change Ease of change Time Definition of project objectives Source: Developed from Allinson (1997). Deliverables in use 13 Project Control Figure 1.6 shows how the cost of changes on the project increases dramatically once the project has entered the implementation stages, compared with the much lower cost of change during the concept, feasibility, and design stages. During the early stages, fewer people are involved and the decisions made are more strategic in nature. A simple example is a change fed back from the corporate executive, at the concept stage of an organizational change project, to have separate sales and marketing departments instead of a combined one. This requires reworking the project objectives and reassessing the risk associated with the change on the overall project. It can be carried out by a small number of people relatively quickly. This same change, brought into the project during the implementation stages, will require significant amounts of time and resource to adjust the project plan to meet the new requirement. It may also cause demotivation in the project team, as work already implemented has to be ‘‘undone’’ and the new structure put in place. It is worth remembering that objectives may need to be changed during the project, reflecting the reality that situations change over time. If this is the case, it may be decided that the best course of action is to complete the project (because some of its objectives are still valid and/or the cost of cancellation would outweigh the benefits of continuing) but accept a lower effectiveness of the deliverables. A number of specialist project management techniques can be used to help in the scope definition and change control processes and are described in detail in other chapters of this book. They include the following: Configuration management Interface control Systems engineering The definition and control of how all the deliverables are configured; how they all ‘‘fit’’ together The exact specification of the interfaces between different deliverables The way in which a set of deliverables are arranged within a hierarchical ‘‘systems architecture’’ (The chapter by Cooper and Reichelt addresses the issue of managing changes in more detail.) Defining the Work Packages Three tools are used to define the work packages: • Product breakdown structure (PBS). What needs to be made by the project. • Work breakdown structure (WBS). The work required to make these products • Organizational breakdown structure (OBS ). Where in the organization the skills reside for doing the work needed The first part of the work package definition process is to break down the main set of deliverables (identified in the scope process) into their component parts—the deliverables 14 The Wiley Guide to Project Control breakdown structure, more commonly known as the product breakdown structure (PBS). The disaggregation of the deliverables is developed to the level of detail that is needed by those working on the project, and commensurate with the degree of control that is required to be exercised. The work associated with making the deliverables is also divided into discrete work packages—and documented in the work breakdown structure (WBS). The two models must be consistent with each other; the work packages identified in the WBS must be associated with specific deliverables (i.e., products). The PBS and WBS are often combined together, and when this is the case, the diagram is usually called the WBS. The decomposition of deliverables, and associated work, is fed into the processes for creating the forecasts of time and cost to make them; this is the estimating process. Without a clear understanding of the finite elements that need to be made by the project, it would be very difficult to carry out effective estimation of the duration to complete the tasks required and the cost to make the deliverables. Fundamental to the planning process is deciding who will be carrying out the project work, documenting this information, and communicating it to the project team. The allocation of people to work packages is recorded in the organizational breakdown structure (OBS). The human resources needed to undertake the tasks to make the deliverables are often in short supply. This means that there will rarely be enough suitably skilled people available to create the deliverables as quickly as may be desired. The resources available for the work will ultimately determine the time to make the deliverables. Estimating the Work Forecasting how long a work package will take to complete and the cost to carry out that work is essential to effective planning. There are a number of techniques used to estimate time and cost. Essentially, the estimating process is iterative. A number of estimates are produced, reviewed, validated against the availability of resources required for the work packages, and revised accordingly. In the estimating process, it is important to refer to historical information on the cost and time taken to carry out the same or similar work packages. Since cost is normally directly related to time (because time to complete work packages is mainly dependent on people and materials), time estimates are produced first. The cost estimate is then generated based on the forecast time to complete the work packages and the cost of materials needed: Time estimating Cost estimating Time estimates are developed by calculating how long the work package will take to complete. The inputs for the estimates of duration typically originate from the person or group on the project team who is most familiar with the nature of the tasks required to complete the work package. Cost estimating involves calculating the costs of the resources needed to complete project activities. This means the cost of peoples’ time must be known, as well as the cost of materials needed to make the deliverables. This includes identifying the project management overhead—the cost of managing the project. 15 Project Control With estimating, there is uncertainty about the exact duration and exact cost of a work package—by definition. The uncertainty can be reflected by estimating the range within which the duration and cost for each work package will fall. The optimistic, most likely, and pessimist values for each can be provided—known as three-point estimating. This information can then be fed into the scheduling and budgeting processes to provide a more realistic view of the ranges of outcomes for the project as a whole. (A number of different probability distribution curves can be used.) A fourth tool used in project planning can now be used—the cost breakdown structure (CBS). This documents the cost to carry out each work package, taken from the cost estimate. The information is set out in an integrated way with the PBS, WBS, and OBS to form the fundamental framework for project control. These four fundamental tools describe what has to be made to meet the project requirements, what work is needed to be carried out to make the deliverables, who is allocated to the work packages, and what the cost to create the set of deliverables will be. In large and complex projects, this information can be combined into a three-dimensional matrix (called the cost cube) to show the cost per product or deliverable, per resource (Turner and Remenyi, 1995). See Figure 1.7. One advantage of creating the cost cube is that it provides a framework, or structure, for developing the estimate. For instance, one can more easily identify whether all the appropriate elements of cost associated with resources for a particular product have been included. It also enables the summing along any plane of ‘‘cubes’’ to provide cost information for any of the discrete items on the three axes. For instance, it is a straightforward matter to identify the total cost of resource R4 to the project by adding together the costs in each cube of the plane, as shown on the diagram. FIGURE 1.7. THE COST CUBE MATRIX. Resources allocated (from OBS) R1 R2 R3 R4 P1 P2 P3 Work packages or products (from WBS or PBS) P4 P5 C1 Source: Adapted from Turner and Remenyi (1995). C2 C3 C4 C5 Cost per product per resource (from CBS) 16 The Wiley Guide to Project Control Scheduling the Work Packages The essence of scheduling work packages is simple. The following factors must be known: • Upon what previous work each subsequent work package depends • The estimated duration of the work package • How much ‘‘float’’ is available for the work—whether the work package must be carried out within a certain time or whether the time period in which it must be done can float between two known extremes It is the combination of this information that determines what can be done when. There are a number of well-known and commonly used techniques for modeling project work (critical path method, program evaluation and review technique, precedence diagramming, amongst others). All these techniques aim to provide flexibility in the manipulation of the model information until the optimum solution is found to suit the particular work packages of the project. Some were invented in the field of operations research, whilst others were developed by organizations for their own use. These modeling techniques are able to create projects schedules, either directly or by feeding into other techniques. There are two distinct approaches to these scheduling techniques: activity-on-the-arrow, depicted in Figure 1.8, and activity-on-the-node, depicted in Figure 1.9. They both model the sequence of work packages by using nodes and arrows to build up a diagram that shows dependency and time for all the work packages for the project. It is then a relatively straightforward (and using PC-based software, quick) task to calculate how long it will take to complete all the work packages and, hence, the project’s overall schedule. The route through the network that determines the shortest possible time to complete all the work packages is called the critical path. This is important information for the project manager because these work packages will be the focus of management attention, particularly those projects for which completion ‘‘on schedule’’ is critical. FIGURE 1.8. ACTIVITY-ON-THE-ARROW NETWORK. Work package (or activity) 3 B D F A 1 2 5 C “State” (product, or subproduct) 4 E 6 17 Project Control FIGURE 1.9. ACTIVITY-ON-THE-NODE NETWORK. Work package (or activity) A 2 1 C 4 6 B E 3 D F 5 “State” (product, or subproduct) The differences between the two basic network modeling techniques appear trivial at first sight of the diagrams. However, the two approaches have significant differences in the operation of the logic used. Both have advantages and disadvantages. Once the schedule has been established from the network diagram, it is often presented graphically on a Gantt chart. This format makes it easier to see when the work packages will be carried out in relation to each other. It also allows simple graphical representation of work completed at a given point in time, making reporting of project progress easier to show. Many current software-based scheduling tools allow the user to enter time duration for work packages directly into a Gantt chart, without first going through the process of building a network diagram. This is user-friendly but does not necessarily lead to more effective scheduling! The schedule must be reassessed in light of the availability of people (and indeed materials—particularly those being supplied by third parties and contractors to the core project team). This part of the scheduling process is called resource leveling—making the schedule fit the available resources. There is likely to be an impact on the cost to complete the project, so the budget must also be reassessed (hence, the estimate is progressively elaborated and becomes progressively more accurate). Understanding the causes of variance between the actual time taken to complete the work packages and the schedule is important information for the estimating process in future projects. Similarly, variances between the actual cost to carry out the work packages and the estimated cost will also provide valuable historical estimating information. The risk management and estimating processes will identify where there is uncertainty in the project. This uncertainty can be modeled in the schedule by allowing extra time for the work packages likely to be affected. It is clear that the entire planning process is iterative, and a number of cycles of scheduling, budgeting, and assessment of resource availability and productivity are required before a final project plan can be established. Managing Resource Availability The initial estimates of time and cost to complete the project are ideal estimates; the assumptions are made that sufficient people, materials, facilities, equipment, and services will 18 The Wiley Guide to Project Control be available to carry out the project at the maximum efficiency. However, before the schedule and budget can be finalized, the impact of resource availability, and the productivity of those resources, must be taken into account. For example: • Sufficient people are rarely available (particularly where a few experts must input to many work packages). • ‘‘Ideal’’ materials are often either not available where and when required, or their cost would make the project untenable (meaning less efficient materials need to be used). • Equipment is often expensive to use and therefore must be shared across a number of projects. • The same applies for facilities and services. In addition to this, the resource ‘‘profile’’ (the types of resources needed at different times in the project) usually changes over the project life cycle. The process for managing resource allocation can be broken down into five stages: Planning resource allocation Allocating resources Optimizing the schedule Monitoring resource allocation Reviewing and revizing the resource allocation Identifying the types of resources required, based on the information defined in the PBS, WBS, OBS, and CBS. Coordinating the availability of resources with the suppliers of those resources and allocating them to work packages: be they internal to the organization within which the project exists (and this is commonly a major task for people—human resources—where organizations have a matrix structure) or external, such as thirdparty suppliers of materials, equipment, services, and facilities. Inputting resource availability in the schedule, which normally means having to use the technique of resource leveling— ‘‘smoothing’’ resource usage to balance schedule and the availability of resources. Tracking resource usage and identifying and resolving conflicts associated with resource availability as this, and the project’s needs, change over time. Modeling the impact of changing resource use and availability on the project budget and schedule Productivity of resources clearly has a significant influence on the schedule, and hence the cost, of the project. Productivity of equipment is often fairly easy to measure and predict; predicting productivity of people is a far more complex thing to do (and predicting productivity of highly creative design resources even more difficult). Productivity information can be gained from historical records of performance on similar work—for people and equipment. Finding and using this information is vital to effective resource allocation and resource ‘‘smoothing’’ of schedules. Budgeting The costs to complete all the work packages are identified in the estimating process. Combining the cost information with the schedule allows the cash flow curve to be created. This Project Control 19 curve is a key piece of control information. This is particularly the case for organizations that are contracted to deliver projects on behalf of a client. These types of projects have large cash outflows (to pay for material and human resources), which are usually then charged on to the client sometime after the expenditure is incurred. If this is not managed very carefully, the project can become heavily indebted. The difference between what has been spent and what has been recovered by a project, at a given time, can cause the funders of this difference (the owners of the firm running the project) to become insolvent. Hence, effective cash flow management is a highly valued skill in project-based industries, such as construction and engineering, where huge amounts of money flow through the project. The cash flow curve and the cost forecast are the basis of the project budget. This describes what amounts of money will be spent, on what resources, and when they will be spent. Before the cost forecast becomes a budget (the budget is the agreed amount of money that the project manager can spend), the effect of risk on the project needs to be assessed in cost terms and then added to the forecast. This additional amount of money allows the project manager to deal with ‘‘certain uncertainty’’ in the forecasts (the uncertainty can be predicted through the risk management process), and also ‘‘uncertain uncertainty’’ that can affect the project (uncertainty that cannot be assessed—as an example, a key human resource may leave the project without warning). These extra sums of money are the budget contingencies. The importance of creating accurate budgets, and controlling against the budget, is obvious in a commercial environment—overspending reduces profit; underspending (whilst still making the correct project deliverables) increases profit. In the not-for-profit sector, control of money is clearly still critical. The budget document therefore identifies, line by line (hence the term ‘‘line item’’), how much money is agreed to be spent per deliverable, or part deliverable. It is this detailed breakdown against which actual costs are measured and reported, and control action initiated. After the forecasts have been analyzed and the deliverables set has been revisited to seek optimization of all the project constraints, a schedule and budget are agreed upon by the project sponsors. The budget and schedule are absolutely fundamental to the control process. It is against these two documents that the progress of the project in carrying out the work packages, and hence the production of the deliverables, is measured (see Figure 1.4). However, having two separate documents means there exists a lack of integrated information related to deliverables (or products), schedule, and the budget to produce those deliverables—the complete picture of predicted project performance cannot easily be discerned. This can be overcome by combining information on schedule, budget, and the project deliverables. This is called earned value analysis. Earned Value Analysis The technique of earned value analysis (EVA) allows the actual performance of the project to be compared to the predicted performance. All the information required for this type of analysis should be available from standard project reporting against the schedule and budget (reporting is described later in this chapter). The schedule per work package (or, if preferred, 20 The Wiley Guide to Project Control discrete product) is plotted on one axis of a graph, and the budget per work package (or product) is plotted against the other axis. See Figure 1.10. Common acronyms are used for the information required for the analysis: • BCWS. Budgeted cost of work scheduled (how much money has been allocated to each work package or product in the schedule) • BCWP. Budgeted cost of work performed (how much money was allocated to each work package or product that has been completed) • ACWP. Actual cost of work performed (how much it actually cost for the work package to be performed or the product to be delivered) The figure for budgeted cost of work performed (BCWP) is the earned value at the point in time that the analysis is being done. The chapter by Brandon looks at this technique in greater detail. At this point it is just worth noting the control information that can be determined from EVA. By manipulation of the data gathered from project performance reporting, project schedule and budget performance can be assessed. The Schedule Performance Index (SPI) and Cost Performance Index (CPI) are calculated as follows: SPI ⫽ BCWP BCWS CPI ⫽ BCWP ACWP If, at the time of measurement, budgeted cost of work performed and the budgeted cost of work scheduled are the same (i.e., the SPI ⫽ 1), the project is exactly on schedule. In the FIGURE 1.10. EARNED VALUE ANALYSIS PRESENTED GRAPHICALLY. Cumulative cost per work package (or product) Report date The Budgeted Cost of Work Scheduled (the “planned value” curve) Actual Cost of Work Performed The Budgeted Cost of Work Performed (the “earned value” curve) Schedule Project Control 21 same manner, if the budgeted cost of work performed is the same as the actual cost of work performed (i.e., the CPI ⫽ 1) the project is exactly on budget. If the BCWP is less than the BCWS, the SPI is less than 1; therefore, the project is behind schedule. Equally if the BCWP is less than the ACWP, the CPI is less than 1; there, the project is over budget. EVA appears relatively straightforward to use, and predictions of future performance can be made using the data (by projecting final time and cost to complete using SPI and CPI values). However, care must be taken to moderate the results from this technique with other project data. There are also inherent dangers in believing that the information provided is a foolproof indicator of current and future progress. EVA does not report the subtleties of project control; it only provides an overview. Key Performance Indicators Key performance indicators (KPIs) are used to measure project progress toward achieving objectives, rather than the detail of progress of the work packages. They may be used to • Measure project performance that is directly related to the change the project is delivering (which could be shareholder value, return on investment, market share, etc.) • Measure project specific performance—that is, the performance of the project processes (e.g., effectiveness of project control mechanisms, degree of project cost reduction by using designated procurement practices, amount of change occurring in project, etc.). KPIs must be determined at the beginning of the project and provide direct progress information toward project objectives. The information these measures of performance provide can help the project manager make decisions on trade-offs between the various (usually conflicting) control actions needed. KPIs also need to be measurable (otherwise how will one know if they have been achieved?). Whilst this sounds obvious, it must be remembered that KPIs can only be useful if the information needed to determine the KPI during and at the end of the project is actually available. This implies that the project management information system must collect relevant data and generate the appropriate information outputs to provide the KPIs to the project’s management team—upon which control action will be based. If the KPIs to be used in a project have been determined by consultation between those needing the change to be delivered by the project (the project sponsor) and the project manager, it is possible to define success as meeting the KPIs at project completion. Critical Success Factors Critical success factors (CSFs) are sometimes used synonymously with KPIs. Literally, however, CSFs are the factors that are critical to success. Identification of the CSFs for a project will mean that the project manager and project team know where to concentrate their attention in order to achieve the project objectives. CSFs are therefore the factors that are critical to achieving success, not a measure of performance—which is what KPIs are. 22 The Wiley Guide to Project Control A number of studies have been conducted into the factors found to be critical to project success. Many are generic across all projects, but each project will also have its own very specific factors. In their definitive research on success factors in projects Morris and Hough (1987) identified CSFs under the following general headings: • • • • • • • • • Project definition Politics/social factors Schedule urgency Legal agreements Human factors Planning, design, and technology management Schedule duration Finance Project implementation The development of CSFs for the project (with the involvement of the project manager, project team, project sponsor, and other senior stakeholders) is an important exercise in its own right, since all those associated with the project gain mutual understanding of what is critical to project success. Performance Measurement and Control Action The elements of the project plan have all now been described. On large and complex projects, these elements are often combined into a comprehensive project management control system. These systems also usually aggregate information from many projects, up to their respective program plan, if they are part of a program, and then up to the organization’s business management system. The project plan is constantly adjusted to reflect the reality of what is happening during the project, and so enable the effect of control actions to be predicted on the progress of the current and future work packages. The updated plan provides information to the following: • The project team. Who can then plan their work packages to suit the revised plan • The project sponsor. Who can assess the impact of the new plan on the delivery of the change required • Other project stakeholders. Who may have other areas of work impacted by the changed project plans (including other projects being run—which is particularly important for program managers) It is critically important, however, that the original plan is not lost—the project plan must be ‘‘baselined.’’ This means that while the plan is updated and used to replan future work, Project Control 23 it is still possible to compare what should have been completed (the baseline plan) with what has been completed (the updated plan). Knowledge of the variance between the two plans provides performance information and therefore helps • Guide the development of the control actions required to bring the project back towards its original plan (if so desired) • Improve the future control actions to make meeting the new plan more likely • Gain knowledge to improve future planning (for replanning the same project and for plans for new projects) The gathering of information to be used for project control is known as project performance measurement. The process provides an integrated view of the performance of the project— cost, schedule, technical issues, commercial, and business issues—so that control action can be taken where necessary to correct undesirable variances from the project plan. Equally important is the appropriate reporting of this information—at the right time, to the right people, and in the right format. The measurement and reporting of progress must fundamentally begin at the work package level. It is here that the information for performance measurement originates. The work package managers must gather information on progress on the specific deliverables that they, or their team, are responsible for creating. The information must be presented in the same manner as the project plan presents it. In this way, variances from the plan are identified at the point where the variance occurs. The work package manager can then instigate control action to bring performance back in line with the project plan—normally a day-to-day management activity. (See Figure 1.3 for a reminder of how all the project control loops nest within a hierarchical control system.) Performance information is reported to the project manager on a regular basis (weekly and monthly usually). Integrated reporting means that all the work package managers report the same measurements, together with the control actions they have taken to reduce negative variance from the plan. Hence, an aggregated project performance report can be compiled. (Sometimes project performance is reported on an exception basis; i.e., a report is generated only when there is a variance to the project plan requiring the attention of the project manager. Even in those organizations that use such reporting methods, a monthly reporting cycle is common.) From this report the project manager can determine which work packages are underperforming and whether the control action taken is likely to correct the situation. This reporting is the control feedback loop shown in the diagrams earlier in the chapter. With the overview of project progress afforded by the integrated report, the project manager is in a position to assist the work package managers to improve performance in a manner that does not compromise other work package performance. This is important, since many work packages will be interrelated and may also share resources. The information can be used to replan work packages, and hence the project, and may also mean that the project manager can take action at a level above the work packages. Examples (amongst many possibilities) include the following: work packages could be rescheduled, the specifications of the work package deliverables may be changed, the acceptance criteria of 24 The Wiley Guide to Project Control the deliverables against the requirements may be adjusted, or the project scope may be changed. This entire process is central to the notion of effective project management. The project manager is the single point of integrative responsibility. It is his or her principal function to integrate control action for the greater needs of the project, to ensure that objectives are met and that the desired change is created by the project. After the control action has been taken, the subsequent work package reports will provide evidence of whether variances from the plan have been successfully controlled—and so the process continues. Organizations often require visibility of project performance at a program or portfolio level. This enables better management of organizational budgets and control of the changes being created by multiple projects and programs. ‘‘Rolled-up’’ performance measurement information, often supported by a program support office (see the chapter by Young and Powell), enables summary reporting to be available to appropriate levels of management in the organization. Summary This chapter has outlined the processes that constitute project control, and in so doing introduced many other project processes upon which effective control depends. Fundamentally, the project must have a • • • • • Set of objectives directly related to the need for the change the project is set up to deliver Plan against which the project can be controlled—and so deliver those objectives Process to measure performance against the plan—the feedback loop Process to control changes to the scope Project manager who is truly the single point of integrated control action, with responsibility for delivering the change required of the project The control process goes on throughout the project life cycle because the internal and external environment of the project is continuously changing. For example: • Performance of resources is often other than predicted (better or worse). • New information is generated that may indicate the original plan was not feasible to begin with. • The objectives for the project may change because the change required to be brought about (by running the project) is itself changed. In combination, these processes can be seen as forming the ‘‘iron rules’’ for the project. Project control is about • Good planning of scope, schedule, and budget • Setting up appropriate metrics to monitor performance Project Control 25 • Reporting the performance against those metrics • Replanning and instigating corrective action to reduce variance from the baseline plan References Association for Project Management. 2000. Body of Knowledge 4th Edition. High Wycombe, UK. Allinson, K. 1997. Getting there by design. Oxford, UK: Architectural Press. Barnes, M. 1988. Construction project management. International Journal of Project Management 6 (2, May): 69–79 Bertalanffy, L., von. 1969. General systems theory: Essays on its foundation and development. New York: Braziller. Checkland, P. 1981. Systems thinking, systems practice. Chichester, UK: Wiley. Cleland, D. I., and W. R. King. 1983. Systems analysis and project management. International ed. Singapore: McGraw-Hill. Dixit, A. K., and B. J. Nalebuff. 1991. Thinking strategically: The competitive edge in business, politics, and everyday life. New York: W. W. Norton & Co. Dixon, M. 2000. Project management body of knowledge. 4th ed. High Wycombe, UK: The Association for Project Management. Eisner, H. 1997. Essentials of project and systems engineering management. New York: Wiley. Jackson, T. 1993. Organisational behaviour in international management. Oxford, UK: ButterworthHeinemann. Katz, D., and R. L. Kahn, 1969. Common characteristics of open systems. In Systems thinking, ed. F. E. Emery. 86–104. Harmondsworth, UK: Penguin Books. Morris, P. W. G. 1994. The management of projects. London: Thomas Telford. Morris, P. W. G., and G. H. Hough. 1987. The anatomy of major projects. Chichester, UK: Wiley. Pinto, J. K., and D. P. Slevin, 1988. Critical success factors across the project life cycle. Project Management Journal. 19(3):67–75. Project Management Institute. 2000. A guide to the project management body of knowledge. Newtown Square, PA: Project Management Institute. Quinn, J. B. 1978. Strategic change: Logical incrementalism. Sloan Management Review. (Fall) 7–22. Reinertsen, D. G. 1987. Managing the design factory. New York: Free Press. Turner, J. R., and D. Remenyi. 1995. Estimating costs and revenues. In The commercial project manager by J. R. Turner. 31–52. London: McGraw-Hill. Suggested Further Reading Archibald, R. D. 2003. Managing high technology programs and projects. New York: Wiley. Hartman, F. 2000. Don’t park your brain outside. Newtown Square, PA: Project Management Institute. Murray-Webster, R., and M. Thiry. 2000. Managing programmes of projects. In The Gower handbook of project management. 3rd ed, ed. R. Turner, S. Simister, and D. Lock. Aldershot, UK: Gower. Smith, N. J. 2002. Engineering project management. 2nd ed. Oxford, UK: Blackwell Science.