CHAPTER 6Project Activity and Risk PlanningThis chapter initiates our discussions of Scope, Time, and Risk Management, critical PMBOK knowledge areas. Time management is an extensive topic which is further discussed in Chapters 8, 10, and 11. Similarly, risk will be discussed further in Chapters 7 and 8.In the Reader’s Digest (March 1998, p. 49) Peter Drucker is quoted on planning: “Plans are only good intentions unless they immediately degenerate into hard work.” To make such a transformation possible is no easy task. Inadequate planning is a cliché in project management. Occasionally, articles appear in project management periodicals attesting to the value of good planning. Project managers pay little attention. PMs say, or are told, that planning “takes too much time,” “customers don’t know what they want,” “if we commit we will be held accountable,” and a number of similar weak excuses (Bigelow, 1998, p. 15). Tom Peters, well-known seeker of business excellence, was quoted in the Cincinnati Post: “Businesses [believe] a lot of dumb things. . . . The more time you spend planning, the less time you’ll need to spend on implementation. Almost never the case! Ready. Fire. Aim. That’s the approach taken by businesses I most respect.” We strongly disagree and, as we will report below (and in Chapter 13), there is a great deal of research supporting the view that careful planning is solidly associated with project success—and none, to our knowledge, supporting the opposite position. Indeed, Brian Tracy, author of Eat that Frog! (2007) argues that every minute allocated to planning saves as much as 10 minutes in execution. Of course effective planning requires avoiding the opposite pitfall of killing the plan with overanalysis. This leads to the well-known “paralysis by analysis.” In an excellent article, Langley (1995) finds a path in-between the two extremes.Thus far, we have dealt with initiating a project. Now we are ready to begin the process of planning the work of the project in such a way that it may be translated into the “hard work” that actually leads to the successful completion of the project. There are several reasons why we must use considerable care when planning projects. The primary purpose of planning, of course, is to establish a set of directions in sufficient detail to tell the project team exactly what must be done, when it must be done, what resources will be required to produce the deliverables of the project successfully, and when each resource will be needed. The entire planning process is, of course, dependent on gathering the correct requirements from the client in the first place. PMBOK lists a number of tools and techniques to help in doing this, including interviews, focus groups, facilitated workshops, group creativity techniques (described in the online Appendix B for this book), questionnaires, and surveys. The plan must be designed in such a way that the project outcome also meets the objectives, both direct and ancillary, of the parent organization, as reflected by the project portfolio or other strategic selection process used to approve the project. Because the plan is only an estimate of what and when things must be done to achieve the scope or objectives of the project, it is always carried out in an environment of uncertainty. Therefore, the plan must include allowances for risk and features that allow it to be adaptive, i.e., to be responsive to things that might disrupt it while it is being carried out. One frequent such disruption—“scope creep,” or the tendency of project objectives to be changed by the client, senior management, or individual project workers with little or no discussion with the other parties actively engaged in the work of the project—is particularly common in software projects. In addition, the plan must also contain methods to ensure its integrity, which is to say it must include means of controlling the work it prescribes.Finally, and quite apart from the deliverables required by the project itself, the plan must include any constraints on activities and input materials proscribed by law and society. Among the many sources of outside constraints are the Food and Drug Administration, the Occupational Health and Safety Administration, other federal and state laws and regulations, various engineering societies, labor unions, and the “Standard Practices” of many different industries. Such constraints are meant to protect us all from unsafe or harmful structures, machines, rugs, equipment, services, and practices.There is an extensive literature on project planning. Some of it is concerned with the strategic aspects of planning, being focused on the choice of projects that are consistent with the organization’s goals. Another group of works is aimed at the process of planning individual projects, given that they have been chosen as strategically acceptable. Most fields have their own accepted set of project planning processes. Except for the names given to the individual processes, however, they are all similar, as we shall soon see. The purpose of planning is to facilitate later accomplishment. The world is full of plans that never become deeds. The planning techniques covered here are intended to smooth the path from Project Management in Practice Beagle 2 Mars Probe a Planning FailureAs the Beagle 2 Mars probe designed jointly by the European Space Agency and British National Space Center headed to Mars in December of 2003, contact was lost and it was never heard from again. In retrospect, it appears that inadequate project planning (and replanning) was to blame. Excessive pressure on time, cost, and weight compromised the mission right from the start. With insufficient public funding, the design team had to spend much of their time raising private funds instead of addressing difficult technical issues. In addition, late chan- ges forced the team to reduce the Beagle’s weight from 238 pounds to 132 pounds! And when the three airbags failed to work properly in testing, a parachute design was substituted but inadequately tested due to lack of time. A review commission recommended that in the future: • Requisite financing be available at the outset of a project• Formal project reviews be conducted on a reg- ular basis • Milestones be established where all stakehold- ers reconsider the project • Expectations of potential failure be included in the funding consideration• Robust safety margins be included and funded for uncertaintiesQuestions: 1. What should the project manager have done about the challenges facing this project? 2. Are the recommendations complete? Would you add anything else?idea to accomplishment. It is a complicated process to manage a project, and plans act as a map of this process. The map must have sufficient detail to determine what must be done next but be simple enough that workers are not lost in a welter of minutiae. In the pages that follow we discuss a somewhat formal method for the development of a project charter (similar to a proposal, or preliminary plan) and final project plan. Almost all project planning techniques differ only in the ways they approach the process of planning. Most organizations, irrespective of the industry, use essentially the same processes for planning and managing projects, but they often call these processes by different names. What some call “setting objectives,” others call “defining the scope” of the project, or “identifying requirements.” What some call “evaluation,” others call “test and validation.” No matter whether the project is carried out for an inside or outside client, the project’s “deliverables” must be “integrated” into the client’s processes.We have adopted an approach that we think makes the planning process straightforward and fairly systematic, but it is never as systematic and straightforward as planning theorists would like. At its best, planning is tortuous. It is an iterative process yielding better plans from not-so-good plans, and the iterative process of improvement seems to take place in fits and starts. The process may be described formally, but it does not occur formally. Bits and pieces of plans are developed by individuals, by informal group meetings, or by formalized planning teams, and then improved by other individuals, groups, or teams, and improved again, and again. Both the plans themselves and the process of planning should start simple with the project charter which is then further elaborated and eventually becomes the project plan. . In this chapter we focus on designing the physical aspects of the project, defining what the project is supposed to accomplish, and who will have to do what for the project’s desired output to be achieved. Here we describe the actual process of project planning. Organizing the work of the project, acquiring a project manager, and forming a project team are parts of project initiation. The project’s budget and schedule are major parts of the project plan, but we delay discussion of them until Chapters 7 and 8. Indeed, what must be done to test and approve project outputs at both interim and final stages, and what records must be kept are both parts of the project plan and these are covered in later chapters, as is the part of the plan that covers terminating the project. There is nothing sacrosanct about this sequence. It is simply in the order that these parts of the project plan tend to develop naturally.INITIAL PROJECT COORDINATION AND THE PROJECT CHARTERIt is crucial that the project’s objectives be clearly tied to the overall mission, goals, and strategy of the organization, such as might be reflected in the project portfolio process. In the project charter, senior management should delineate the firm’s intent in undertaking the project, outline the scope of the project, and describe how the project’s desired results reinforce the organization’s goals. Without a clear beginning, project planning (and later progress) can easily go astray. It is also vital that a senior manager call and be present at the project chartering workshop or “launch” meeting, an initial coordinating meeting, as a visible symbol of top management’s commitment to the project. As Brox (2012a) points out, the sponsor and other key stakeholders should participate in this meeting for the purpose of establishing the project, agreeing on the top deliverables, discussing resourcing, establishing schedule and budget tolerances (so the PM knows when to check in with the sponsor), and defining the high-level risks. Having these key stakeholders involved early on creates buy-in and fosters early communication on potential issues and risks.The individual leading the launch meeting is first to define the scope of the project as detailed in the charter. The success of the project launch meeting is absolutely dependent on the existence of a well-defined set of objectives. Unless all parties to the planning process have a clear understanding of precisely what it is the project is expected to deliver, planning is sure to be inadequate or misguided. At the launch meeting, the project is discussed in sufficient detail that potential contributors develop a general understanding of what is needed. If the project is one of many similar projects, the meeting will be short and routine, a sort of “touching base” with other interested units. If the project is unique in most of its aspects, extensive discussion may be required.It is useful to also review the major risks facing the project during the launch meeting. The known risks will be those identified during the project selection process. These are apt to focus largely on the market reaction to a new process/product, the technical feasibility of an innovation, and like matters. The risk management plan for the project must be started at the launch meeting so that later risk identification can be extended to include the technology of the process/product, the project’s schedule, resource base, and a myriad of other risks facing the project but not really identifiable until the final project plan has begun to take form. In addition to the matters discussed below, one of the outcomes of the project planning process will be the formulation of the project’s risk management group and the initial risk management plan that the group develops during the process of planning the project.While various authors have somewhat different expectations for the project launch meeting (e.g., see Knutson, 1995; Martin et al., 1998), we feel it is important not to allow plans, schedules, and budgets to go beyond the most aggregated level, especially if the project deliverables are fairly simple and do not require much interdepartmental coordination. To fix plans in more detail at this initial meeting tends to prevent team members from integrating the new project into their ongoing activities and from developing creative ways of coordinating activities that involve two or more organizational units. Worse still, departmental representatives will later be asked to make “a ballpark estimate of the budget and time required” to carry out this first-blush plan. Everyone who has ever worked on a project is aware of the extraordinary propensity of preliminary estimates to metamorphose instantaneously into firm budgets and schedules. Remember that this is only one of a series of meetings that will be required to plan projects of more than minimal complexity.It is critical to the future success of the project to take the time required to do a technically and politically careful job of planning. This may mean many meetings and participatory decision making, but it is well worth the effort. In confirmation of this view, a survey of 236 project managers across a wide variety of projects (White et al., 2002) found that there were five criteria used to judge project success: on time, on budget, to scope, fit between the project and the organization, and the impact of the project on the performance of the organization. But the four top- ranking factors critical to project success were: a realistic schedule, adequate resources, clear scope, and support from senior management, all products of careful planning with a solid charter.Whatever the process, the outcome must be that: (1) technical scope is established (though perhaps not “cast in concrete”); (2) basic areas of performance responsibility are accepted by the participants; (3) any tentative delivery dates or budgets and their tolerances set by the parent organization are clearly noted; and (4) a risk management group is created. Each individual/unit accepting responsibility for a portion of the project should agree to deliver, by the next project meeting, a preliminary but detailed plan about how that responsibility will be accomplished. Such plans should contain descriptions of the required tasks, and estimates of the budgets (labor and resources) and schedules.Simultaneous with these planning activities, the risk management group develops a risk management plan that includes proposed methodologies for managing risk, the group’s budget, schedule, criteria for dealing with risk, and required reports. Further, necessary inputs to the risk data base are described and various roles and responsibilities for group members are spelled out, as noted in PMBOK (Project Management Institute, 2013). It must be emphasized that the process of managing risk is not a static process. Rather, it is ongoing, with constant updating as more risks are identified, as some risks vanish, as others are mitigated—in other words as reality replaces conjecture—and new conjecture replaces old conjecture.The various parts of the project charter, including the risk management plan, are then scrutinized by the group and combined into a composite project plan. The composite plan, still not completely firm, is approved by each participating group, by the project manager, and then by senior organizational management. Each subsequent approval hardens the plan somewhat, and when senior management has endorsed it, any further changes in the project’s scope must be made by processing a formal change order. If the project is not large or complex, informal written memoranda can substitute for the change order. The main point is that no significant changes in the project are made, without written notice, following top management’s approval. The definition of “significant” depends on the specific situation and the people involved. A useful tool for facilitating the management of changes to a project’s scope is the Requirements Traceability Matrix. With this matrix, a table is created that links the source of each project requirement to the project objectives, WBS deliverables, etc. intended to satisfy it. A variety of fields (columns) can be incorporated in the Requirements Traceability Matrix depending on the intended use of the matrix. A quick search of the Web will yield a variety of templates that are application-ready for use. An example is shown in PMBOK, p. 119.The PM generally takes responsibility for gathering the necessary approvals and assuring that any changes incorporated into the plan at higher levels are communicated to, and approved by, the units that have already signed off on the plan. Nothing is as sure to enrage functional unit managers as to find that they have been committed by someone else to alterations in their carefully considered plans without being informed. Violation of this procedure is considered a betrayal of trust. Several incidents of this kind occurred in a firm during a project to design a line of children’s clothing. The anger at this change without communication was so great that two chief designers resigned and took jobs with a competitor.Because senior managers are almost certain to exercise their prerogative to change the plan, the PM should always return to the contributing units for consideration and reapproval of the plan as modified. The final, approved result of this procedure is the project plan. When the planning phase of the project is completed, it is valuable to hold one additional meeting, a postplanning review. This meeting should be chaired by an experienced project manager who is not connected with the project (Antonioni, 1997). The major purpose of the postplanning review is to make sure that all necessary elements of the project plan have been properly developed and communicated.Outside ClientsWhen the project is to deliver a product/service to an outside client, the fundamental planning process described above is unchanged except for the fact that the project’s scope cannot be altered without the client’s permission. A common “planning” problem in these cases is that marketing has promised deliverables that engineering may not know how to produce on a schedule that manufacturing may be unable to meet. This sort of problem usually results when the various functional areas are not involved in the planning process at the time the original proposal is made to the potential client. We cannot overstate the importance of a carefully determined set of deliverables, accepted by both project team and client (Martin et al., 1998).Two objections to such early participation by engineering and manufacturing are likely to be raised by marketing. First, the sales arm of the organization is trained to sell and is expected to be fully conversant with all technical aspects of the firm’s products/services. Further, salespeople are expected to be knowledgeable about design and manufacturing lead times and schedules. On the other hand, it is widely assumed by marketing (with some justice on occasion) that manufacturing and design engineers do not understand sales techniques, will be argumentative and/or pessimistic about client needs in the presence of the client, and are generally not “housebroken” when customers are nearby. Second, it is expensive to involve so much technical talent so early in the sales process—typically, prior to issuing a bid or proposal. It can easily cost a firm more than $10,000 to send five technical specialists on a short trip to consider a potential client’s needs, not including a charge for the time lost by the specialists. The willingness to accept higher sales costs puts even more emphasis on the selection process.The rejoinder to such objections is simple. It is almost always cheaper, faster, and easier to do things right the first time than to redo them. When the product/service is a complex system that must be installed in a larger, more complex system, it is appropriate to treat the sale like a project, which deserves the same kind of planning. A great many firms that consistently operate in an atmosphere typified by design and manufacturing crises have created their own panics. (Software producers and computer system salespeople take note!) In fairness, it is appropriate to urge that anyone meeting customers face to face should receive some training in the tactics of selling.Project Charter ElementsAs noted earlier, the initial project planning task is the development of the project charter. The project charter is a high-level document that helps to define the scope of the project and is typically submitted to get project approval to move on to develop a project plan. Given a project charter, approvals really amount to a series of authorizations. The PM is authorized to direct activities, spend monies (usually within preset limits), request resources and personnel, and start the project on its way. Senior management’s approval not only signals its willingness to fund and support the project, but also notifies subunits in the organization that they may commit resources to the project.The process of developing the project charter varies from organization to organization, but should contain the following elements as described in PMBOK: • Purpose Thisisashortsummarydirectedtotopmanagementandthoseunfamiliarwiththe project. It contains a statement of the general goals of the project and a brief explanation of their relationship to the firm’s objectives (i.e., the “Business Case,” where we see how profits are gained). The Business Case includes not only market opportunities and profit potentials but also the needs of the organization, any customer requests for proposals, technological advancement opportunities, and regulatory, environmental, and social con- siderations. A properly crafted Business case should succinctly provide the financial and strategic justification for the project.• Objectives This contains a more detailed statement of the general goals of the project and their priorities, what constitutes success, and how the project will be terminated. The statement should include measurable objectives such as profit and competitive aims from the Business Case as well as technical goals based on the Statement of Work (generally abbreviated as SOW). • Overview Thissectionprovidesahigh-leveldescriptionoftheprojectanditsrequirements. Both the managerial and the technical approaches to the work are also described. The technical discussion describes the relationship of the project to available technologies. For example, it might note that this project is an extension of work done by the company for an earlier project. The subsection on the managerial approach takes note of any deviation from routine procedure—for instance, the use of subcontractors for some parts of the work. Also included here is a description of the assumptions the project is based on and contingency plans if the assumptions don’t prove to be correct, and the procedures for changes in the project, including scope, budget, and schedule.Schedules This section outlines the various schedules and lists all milestone events and/or phase-gates. Each summary (major) task is listed, with the estimated time obtained from those who will do the work. The projected baseline schedule is constructed from these inputs. The responsible person or department head should sign off on the final, agreed-on schedule. • Resources There are three primary aspects to this section. The first is the budget. Both capital and expense requirements are detailed by task, which makes this a project budget, with one-time costs separated from recurring project costs. Second, is a complete list and description of all contractual items such as customer-supplied resources, liaison arrange- ments, project review and cancellation procedures, proprietary requirements, purchasing/ procurement contracts (knowledge area 9 in PMBOK), any specific management agree- ments (e.g., use of subcontractors), as well as the technical deliverables and their specifications, delivery schedules, and a specific procedure for changing any of the above. Third, is the set of cost monitoring and control procedures. In addition to the usual routine elements, the monitoring and control procedures must also include any special resource requirements for the project such as special machines, test equipment, laboratory usage or construction, logistics, field facilities, and special materials. Finally, any constraints on the above should also be noted here.• Stakeholders Thissectionliststhekeystakeholders.Thetopicofidentifyingandanalysing stakeholders was discussed in Chapter 4. Key insights from this analysis should be included here. Besides the client, community, and other external stakeholders, the section also lists the expected personnel requirements of the project, especially the project manager and the sponsor/approver of the project. In addition, any special skill requirements, training needed, possible recruiting problems, legal or policy restrictions on work force composition, and security clearances, should be noted here. It is helpful to time-phase personnel needs to the project schedule, if possible. This makes clear when the various types of contributors are needed and in what numbers. These projections are an important element of the budget, so the personnel, schedule, and resources sections can be cross-checked with one another to ensure consistency.• Risk Management Plans At a high-level, this covers potential problems as well as potential lucky breaks that could affect the project. One or more issues such as subcontractor default, unexpected technical breakthroughs, strikes, hurricanes, new markets for the technology, and sudden moves by a competitor are certain to occur— the only uncertainties are which, when, and their impact. In fact, the timing of these disasters and benefits is not random since there are definite times in every project when progress depends on subcontractors, the weather, or timely technical successes. Plans to deal with favorable or unfavorable contingencies should be developed early in the project’s life. No amount of planning can definitively solve a potential crisis, but preplanning may avert or mitigate some. As Zwikael et al. (2007) report, in high-risk projects better project planning improved success on four measures: schedule overrun, cost overrun, technical performance, and customer satisfaction. They conclude that improving the project plan is a more effective risk management approach than using the usual risk management tools.• Evaluation Methods Every project should be evaluated against standards and by methods established at the project’s inception, allowing for both the direct and ancillary goals of the project, as described in Chapter 1. This section contains a brief description of the procedures to be followed in monitoring, collecting, storing, auditing, and evaluating the project, as well as in the post-project (“lessons learned”) evaluation following project termination.These are the elements that constitute the project charter and are the basis for more detailed planning of the budgets, schedules, work plan, and general management of the project. Once this project charter is fully developed and approved, it is disseminated to all interested parties. It is also important to point out that creating the project charter is not a onetime event where it is completed and then filed away never again to see the light of day. Rather, the project charter should be a living document that is continuously updated as conditions change.Once the project charter is completed and the project approved, a more detailed project plan can be developed. According to PMBOK, a proper project plan addresses the following issues: • The process for managing change • A plan for communicating with and managing stakeholders • Specifying the process for setting key characteristics of the project deliverable (technically referred to as configuration management)• Establishing the cost baseline for the project and developing a plan to manage project costs • Developing a plan for managing the human resources assigned to the project • Developing a plan for continuously monitoring and improving project work processes • Developing guidelines for procuring project materials and resources • Defining the project’s scope and establishing practices to manage the project’s scope • Developing the Work Breakdown Structure • Developing practices to manage the quality of the project deliverables• Defining how project requirements will be managed • Establishing practices for managing risk • Establishing the schedule baseline and developing a plan to manage the project’s scheduleBefore proceeding, we should reiterate that this formal planning process just described is required for relatively large projects that cannot be classified as “routine” for the organization. The time, effort, and cost of the planning process is not justified for routine projects such as most plant maintenance projects. Admittedly, no two routine maintenance projects are identical, but they do tend to be quite similar. It is useful to have a generic plan for such projects, but it is meant to serve as a template that can easily be modified to fit the specific routine project at hand.Project Management in Practice Child Support Software a Victim of Scope CreepIn March 2003, the United Kingdom’s Child Support Agency (CSA) started using their new £456 million ($860 million) software system for receiving and disbursing child support payments. However, by the end of 2004 only about 12 percent of all appli- cations had received payments, and even those took about three times longer than normal to process. CSA thus threatened to scrap the entire system and with- hold £1 million ($2 million) per month in service payments to the software vendor. The problem was thought to be due to both scope creep and the lack of a risk management strategy. The vendor claimed that the project was disrupted constantly by CSA’s 2500 change requests, while CSA maintained there were only 50, but the contract did not include a scope management plan to help define what constituted a scope change request. And the lack of a risk manage- ment strategy resulted in no contingency or fallback plans in case of trouble, so when project delays surfaced and inadequate training became apparent, there was no way to recover. Questions: 1. What was the source of the problem here? 2. How might a Project Charter as described above have helped avoid these shortcomings? 3. What would you suggest to recover the project?In today’s fiercely competitive environment, project teams are facing increasing pressure to achieve project performance goals while at the same time completing their projects on time and on schedule. Typically, project managers and project team members rely on the “left” side or the analytical part of the brain to address these challenges. Indeed, if you are a business or engineering student, the vast majority of techniques that you have been exposed to in your studies rely on the logical and analytical left side of your brain. On the other hand, art students and design students tend to be exposed to techniques that rely more on imagination and images which utilize the creative “right” side of the brain. Importantly, many activities associated with project management can be greatly facilitated through the use of a more balanced whole-brain approach (Brown and Hyer, 2002).One whole-brain approach that is particularly applicable to project management in general, and project planning in particular, is “mind mapping.” Mind mapping is essentially a visual approach that closely mirrors how the human brain records and stores information. In addition to its visual nature, another key advantage associated with mind mapping is that it helps tap the creative potential of the entire project team, which, in turn, helps increase both the quantity and quality of ideas generated. Because project team members tend to find mind mapping enjoyable, it also helps generate enthusiasm, helps obtain buy-in from team members, and often gets quieter team members more involved in the planning process.To illustrate the creation of a mind map to identify the work that must be done to complete a project, consider a project launched at a business school to reimagine its full-time MBA program. The mind mapping planning session is initiated by taping a large sheet of paper (e.g., 6 ft × 3 ft) on a wall. (One good source of such paper is a roll of butcher’s wrapping paper. Several sheets can be taped together to create a larger area if needed. Alternatively, sheets of flip chart can be taped together.) It is recommended that the paper be oriented in landscape mode to help stimulate the team’s creativity as people are used to working in portrait mode. In addition, team members should stand during the mind mapping exercise.The process begins by writing the project goal at the center of the page. As is illustrated in Figure 6-1a, the full-time MBA project team defined the goal for the project as “Develop Game Changing MBA Program.” In particular, notice the inspirational language used in defining the project goal which helps further motivate team members and stimulate their creativity.Figure 6-1a Begin mind mapping with statement of project’s objective.Develop Game Changing MBA ProgramDevelop Game Changing MBA 1-Understand Student Needs and Interests Program2-ID Trends3- Competencies NeededFigure 6-1b Major tasks branch off from project goal.6.1 INITIAL PROJECT COORDINATION AND THE PROJECT CHARTERDevelop Game Changing MBA Program1- ID Trends * Conduct Focus Groups * Develop Discussion Guide (Recruiters/Alumni) *Get Futurist Input *ID ParticipantsReview Data from GMAC and AACSB Interview Advisory Board Review Economist Data Review DoE Forecast Review TED Conference Materials Benchmark Other Types of Professional Schools2- Understand Student Needs and InterestsPredict Career-Long Educational Needs Predict How Students Will Learn Determine Student Expectations/Desires3- Predict Competencies NeededPredict Top Industries Seek Input from Leading Thinkers Determine Right Balance of Practice versus Theory Establish Skill SetsID Future JobsFigure 6-1c Major tasks are further broken down into more detailed tasks.Once the project goal is defined, team members can brainstorm to identify the major tasks that must be done to accomplish this goal. In developing the mind map for the MBA project, the project team initially identified three major tasks: (1) identify important trends in business and higher education, (2) gain an understanding of student needs and interests, and (3) predict competencies MBA graduates will need to be successful in their careers. As illustrated in Figure 6-1b, these major tasks branch off from the project goal. Developing the mind map proceeds in this fashion whereby activities in the mind map are sequentially broken down into greater detail. For example, Figure 6-1c illustrates how the three initial activities were subsequently broken down into greater detail. Figure 6-2 provides the final mind map for the full-time MBA project.A few comments regarding the process of mind mapping are in order. First, when initially developing the mind map, color, word size, word shape, and pictures should all be used to add emphasis. In fact, team members should be encouraged to use pictures and images in the mind map to represent activities instead of using words. The reason for this is because the brain processes and responds to symbols and pictures differently than it does to words. When using words, key words as opposed to full sentences should be used. Also, it should be noted that it is OK to be messy when developing the original mind map. Indeed, one should not expect the original mind map to resemble something as polished as the mind map shown in Figure 6-2. Rather, the mind map will typically need to go through several iterations of polishing and refining. It should also be noted that the polishing and refining can be greatly facilitated with the use of a computer graphics program (the software package Mindjet MindManager was used to create Figures 6-1 through 6-4). Typically, one person on the project team will take ownership for cleaning up the original mind map and distributing it to the other team members for additional input.In addition, when the initial mind map is being created, multiple team members should contribute to the mind map simultaneously as ideas occur to them. In fact, a best practice is to designate one team member as the facilitator to ensure that all team members are involved and contributing, and to ensure that team members are focusing on identifying the work that must be done—not goals for the project. Finally, at the most detailed level, seek to express tasks using a verb and a noun (e.g., develop guidelines, identify participants). Unfortunately, it is all too common for projects to go over budget and/or be completed late. In many cases, insufficient upfront planning is the major culprit. With inadequate upfront planning, important tasks are overlooked, which in turn results in underestimating the project budget and duration. Mind mapping is a fast and effective tool that can greatly facilitate comprehensively identifying the work that needs to be completed which in turn helps minimize problems that result from inadequate upfront planning and overlooking important work elements. Finally, it is worth noting that a polished and refined mind map facilitates a number of other project-related activities. For example, the mind map can be easily converted into the traditional WBS (discussed shortly). Furthermore, the mind map can be used to facilitate risk analysis, setting project team meeting agendas, allocating resources to project activities, and developing the project schedule (see Brown and Hyer, 2002, for additional details on the use of mind mapping for project management).Project Planning in ActionOnce the project activities are identified via the creation of a mind map or some other approach, project planning continues by considering the sequence of these activities required to carry the project from start to completion. Not only is this a natural way to think about a project; it also helps the planner decide the necessary sequence of things—a necessary consideration for determining the project schedule and duration. In a fascinating paper, Aaron and his colleagues (1993) describe the planning process used at a telecommunications firm. Using a planning process oriented around the life-cycle events common for software and hardware product developers, they divide the project into nine segments:• Concept evaluation • Requirements identification • Design • Implementation • Test • Integration • Validation • Customer test and evaluation • Operations and maintenanceEach segment is made up of activities and milestones (significant event points). As the project passes through each segment, it is typically subjected to a series of “stage gates” (also known as “phase gates,” “toll gates,” “quality gates,” etc.) that must be successfully passed before proceeding to the next segment. Note that the planning process must pass through the stage gates as well as the physical output of the project itself. For example, the requirements identification segment must meet the appropriate quality standards before the design segment can be started, just as design must be approved before implementation can begin.6.2 THE WBS: A KEY ELEMENT OF THE PROJECT PLANIn this and the following sections of this chapter, and in Chapters 7 and 8 on budgeting and scheduling, we move into the details of (and some tools for) developing the project plan, essentially an elaboration of the elements of the project charter. As PMBOK points out, the project charter is one of the major inputs to the project plan. We need to know exactly what is to be done, by whom, and when. All activities required to complete the project must be precisely delineated and coordinated. The necessary resources must be available when and where they are needed, and in the correct amounts. Some activities must be done sequentially, but some may be done simultaneously. If a large project is to come in on time and within cost, a great many things must happen when and how they are supposed to happen. Yet each of these details is uncertain and thus each must be subjected to risk management. In this section, we propose a conceptually simple method to assist in sorting out and planning all this detail. It is a hierarchical planning system—a method of constructing a work breakdown structure (WBS).To accomplish any specific project, a number of major activities must be undertaken and completed. Make a list of these activities in the general order in which they would occur. This is Level 1. A reasonable number of activities at this level might be anywhere between 2 and 20. (There is nothing sacred about these limits. Two is the minimum possible breakdown, and 20 is about the largest number of interrelated items that can be comfortably sorted and scheduled at a given level of aggregation.) Now break each of these Level l items into 2 to 20 tasks. This is Level 2. In the same way, break each Level 2 task into 2 to 20 subtasks. This is Level 3. Proceed in this way until the detailed tasks at a level are so well understood that there is no reason to continue with the work breakdown; this will usually be at the individual worker level. As a rule of thumb, the lowest level tasks should have a duration of a few hours to a few days. The more familiar the team is with the work, the longer the durations can be of the lowest level tasks.It is important to be sure that all items in the list are at roughly the same level of task generality. In writing a book, for example, the various chapters tend to be at the same level of generality, but individual chapters are divided into finer detail. Indeed, subdivisions of a chapter may be divided into finer detail still. It is difficult to overstate the significance of this simple dictum. It is central to the preparation of most of the planning documents that will be described in this chapter and those that follow.The logic behind this simple rule is persuasive. We have observed both students and professionals in the process of planning. We noted that people who lack experience in planning tend to write down what they perceive to be the first activity in a sequence of activities, begin to break it down into components, take the first of these, break it further, until they have reached a level of detail they feel is sufficient. They then take the second step and proceed similarly. If they have a good understanding of a basic activity, the breakdown into detail is handled well. If they are not expert, the breakdown lacks detail and tends to be inadequate. Further, we noted that integration of the various basic activities was poor. An artist of our acquaintance explained: When creating a drawing, the artist sketches in the main lines of a scene, and then builds up the detail little by little over the entire drawing. In this way, the drawing has a “unity.” One cannot achieve this unity by drawing one part of the scene in high detail, then moving to another part of the scene and detailing it. He asked a young student to make a pen-and-ink sketch of a fellow student. Her progress at three successive stages of her drawing is shown in Figure 6-3.This illustrates the “hierarchical planning process.” The PM will probably generate the most basic level (Level 1) and possibly the next level as well. Unless the project is quite small, the generation of additional levels will be delegated to the individuals or groups who have responsibility for doing the work. Maintaining the “hierarchical planning” discipline will help keep the plan focused on the project’s deliverables rather than on the work at a subsystem level. It is also worth pointing out that the WBS should reflect all the work that is needed to be done in order to complete the project, including the work of managing the project. At each level the work listed should roll up to the next level such that no extra work is required. This condition is referred to as the 100 percent rule.Some project deliverables may be time sensitive in that they may be subject to alteration at a later date when certain information becomes available. A political campaign is an example of such a project. A speech may be rewritten in whole or in part to deal with recently released data about the national economy, for instance. This describes a planning process that must be reactive to information or demands that change over time. This type of process is sometimes called “rolling wave planning.” Nevertheless, the overall structure of the reactive planning process still should be hierarchical.Sometimes a problem arises because some managers tend to think of outcomes when planning and others think of specific tasks (activities). Many mix the two. The problem is to develop a list of both activities and outcomes that represents an exhaustive, nonredundant set of results to be accomplished (outcomes) and the work to be done (activities) in order to complete the project. In this hierarchical planning system, the objectives are taken from the project charter. This aids the planner in identifying the set of required activities for the objectives to be met, a critical part of the project plan. Each activity has an outcome (event) associated with it, and these activities and events are decomposed into subactivities and subevents, which, in turn, are subdivided again.Assume, for example, that we have a project whose purpose is to acquire and install a large copy machine in a hospital records department. In the hierarchy of work to be accomplished for the installation part of the project, we might find such tasks as “Develop a plan for preparation of the floor site” and “Develop a plan to maintain records during the installation and test period.” These tasks are two of a larger set of jobs to be done. The task “. . . preparation of the floor site” is subdivided into its elemental parts, including such items as “Get specifics on copy machine mounting points,” “Check construction specifications on plant floor,” and “Present final plan for floor preparation for approval.” A form that may help to organize this information is shown in Figure 6-4. (Additional information about each element of the project will be added to the form later when budgeting and scheduling are discussed.)The Work Breakdown Structure (WBS)Using this hierarchical planning process results in a work breakdown structure known as a WBS. The WBS is the main tool for managing the project scope as described in PMBOK. The WBS is not one thing. It can take a wide variety of forms that, in turn, serve a wide variety of purposes. In many ways, the WBS is a simplified form of the project plan focused on the actual tasks of the project. It often shows the organizational elements associated with a project subdivided into hierarchical units of tasks, subtasks, work packages, etc. Figure 6-5 is such a WBS for a conference. The Food group in the Facilities staff has responsibility for meals and drinks, including coffee breaks and water pitchers in the conference rooms. Five different food functions are shown, each presumably broken down into more detailed tasks. In this case, the account numbers for each task are shown so that proper charges can be assigned for each piece of work done on the project.Professor Andrew Vazsonyi has called this type of diagram a Gozinto chart, after the famous Italian mathematician Prof. Zepartzat Gozinto (of Vazsonyi’s invention). Readers will recognize the parallel to the basic organizational chart depicting the formal structure of an organization, or the Bill of Materials in a Materials Requirements Planning (MRP) system. Another form of the WBS is an outline with the top organizational (Level 1) tasks on the left and successive levels appropriately indented. Most current project management software will generate a WBS on command. Microsoft’s Project, for example, links the indented activity levels with a Gantt chart that visually shows the activity durations at any level.In general, the WBS is an important document and can be tailored for use in a number of different ways. It may illustrate how each piece of the project contributes to the whole in terms of performance, responsibility, budget, and schedule. It may, if the PM wishes, list the vendors or subcontractors associated with specific tasks. It may be used to document that all parties have signed off on their various commitments to the project. It may note detailed specifications for any work package, establish account numbers, specify hardware/software to be used, and identify resource needs. It may serve as the basis for making cost estimates or estimates of task duration. Largely, the WBS is a planning tool but it may also be used as an aid in monitoring and controlling projects. Again, it is important to remember that no single WBS contains all of the elements described and any given WBS should be designed with specific uses in mind. Its uses are limited only by the needs of the project and the imagination of the PM. No one version of the WBS will suit all needs, so the WBS is not a document, but any given WBS is simply one of many possible documents.However, in constructing the WBS, all work package information should be reviewed with the individuals or organizations who have responsibility for doing or supporting the work in order to verify the WBS’s accuracy. Resource requirements, schedules, and subtask relationships can now be aggregated to form the next higher level of the WBS, continuing on to each succeeding level of the hierarchy. At the uppermost level, we have a summary of the project, its budget, and an estimate of the duration of each work element. For the moment, we are ignoring uncertainty in estimating the budget and duration of work elements.As we noted, the actual form the WBS takes is not sacrosanct. Figure 6-6 shows a partial WBS for a college “Career Day,” which includes the activities, who is responsible, the time each task is expected to take, which tasks must precede each task, and any external resources needed for that task. However, not all elements of the WBS shown in Figure 6-6 may be needed in other cases. In some cases, for example, the amounts of specific resources required may not be relevant. In others, “due dates” may be substituted for activity durations. The appearance of a WBS will probably differ in different organizations. In some plans, numbers may be used to identify activities; in others, letters. In still others, combinations of letters and numbers may be used. An example of a WBS to acquire a subsidiary is illustrated in Figures 6-7a and 6-7b. A verbal “WBS” was written in the form of a memorandum, Figure 6-7a, and was followed by the more common, tabular plan shown in Figure 6-7b. Only one page of a five-page plan is shown. The individuals and groups mentioned developed similar plans at a greater level of detail. (Names have been changed at the request of the firm.)Occasionally, planners attempt to plan by using “Gantt charts,” a network device commonly used to display project schedules (see Figure 6-8). The Gantt chart was invented as a scheduling aid. In essence, the project’s activities are shown on a horizontal bar chart with the horizontal bar lengths proportional to the activity durations. The activity bars are connected to predecessor and successor activities with arrows. The project schedule integrates the many different schedules relevant to the various parts of the project. It is comprehensive and may include contractual commitments, key interfaces and sequencing, milestone events, and progress reports. In addition, a time contingency reserve for unforeseeable delays might be included. While it is a useful device for displaying project progress, it is somewhat awkward for project planning. Nevertheless, the two most common tools used to manage projects, as reported in the survey by White et al. (2002), were project management software and Gantt charts. As reported by a working professional student in an MBA class, the Gantt chart integrated all the pieces of her project so she could see the entire project and how the pieces fit together. This phenomenon of major PM reliance on the Gantt chart has been reported in many studies.At this point, it might be helpful to sum up this section with a description of how the planning process actually works in many organizations. Assume that you, the PM, have been given responsibility for developing the computer software required to transmit medical X-rays from one location to another over the Internet. There are several problems that must be solved to accomplish this task. First, the X-ray image must be digitized. Second, the digitized image must be transmitted and received. Third, the image must be displayed (or printed) in a way that makes it intelligible to the person who must interpret it. You have a team of four programmers and a couple of assistant programmers assigned to you. You also have a specialist in radiology assigned part-time as a medical advisor.Your first action is to meet with the programmers and medical advisor in order to arrive at the technical requirements for the project. From these requirements, the project mission statement and detailed specifications will be derived. (Note that the original statement of your “responsibility” is too vague to act as an acceptable mission statement.) The basic actions needed to achieve the technical requirements for the project are then developed by the team. For example, one technical requirement would be to develop a method of measuring the density of the image at every point on the X-ray and to represent this measurement as a numerical input for the computer. This is the first level of the project’s WBS.Responsibility for accomplishing the first level tasks is delegated to the project team members who are asked to develop their own WBS for each of the first level tasks. These are the second level WBS. The individual tasks listed in the second level plans are then divided further into third level WBS detailing how each second level task will be accomplished. The process continues until the lowest level tasks are perceived as “units” or “packages” of work appropriate to a single individual.Early in this section, we advised the planner to keep all items in a WBS at the same level of “generality” or detail. One reason for this is now evident. The tasks at any level of the WBS are usually monitored and controlled by the level just above. If senior managers attempt to monitor and control the highly detailed work packages several levels down, we have a classic case of micromanagement. Another reason for keeping all items in a given level of the WBS at the same level of detail is that planners have an unfortunate tendency to plan in great detail all activities they understand well, and to be dreadfully vague in planning activities they do not understand well. The result is that the detailed parts of the plan are apt to be carried out and the vague parts of the plan are apt to be given short shrift.In practice, this process is iterative. Members of the project team who are assigned responsi- bility for working out a second, third, or lower-level WBS generate a tentative list of tasks, resource requirements, task durations, predecessors, etc., and bring it to the delegator for discussion, amendment, and approval. This may require several amendments and take several meetings before agreement is reached. The result is that delegator and delegatee both have the same idea about what is to be done, when, and at what cost. Not uncommonly, the individuals and groups that make commitments during the process of developing the WBS actually sign-off on their commitments. The whole process involves negotiation and, of course, like any managers, delegators can micromanage their delegatees, but micromanagement will not be mistaken for negotiation— especially by the delegatees.6.3 HUMAN RESOURCES: THE RACI MATRIX AND AGILE PROJECTSTo identify the personnel needed for the project, it may be useful to create a table that shows the staff, workers, and others needed to execute each of the WBS tasks. One such approach, called an Organizational Breakdown Structure (OBS), displays the organizational units responsible for each of the various work elements in the WBS, or who must approve or be notified of progress or changes in its scope, since the WBS and OBS may well not be identical. That is, some major section of the WBS may be the responsibility of two or more departments, while for other sections of the WBS, two or more, say, may all be the responsibility of one department. Such a document can be useful for department managers to see their total responsibilities for a particular project.The Responsibility (RACI) MatrixAnother approach to identifying the human resources needed for the project is to use the RACI (Responsible, Accountable, Consult, Inform) matrix. This approach is recommended by PMBOK in its Human Resources Management chapter. This type of chart is also known as a responsibility matrix, a linear responsibility chart, an assignment matrix, a responsibility assignment matrix, and similar such names. Sometimes Approval is used instead of Accountable if the organization is carefully monitoring the project. The PM is typically accountable for the activities of the project but individual department heads or service departments such as Purchasing or Human Resources may be accountable for some specific tasks.The matrix shows critical interfaces between units that may require special managerial coordination. With it, the PM can keep track of who must approve what, who must be notified, and other such relationships. Such a chart is illustrated in Figure 6-9. If the project is not too complex, the responsibility chart can be elaborated with additional roles (see Figure 6-10).Agile Project Planning and ManagementThus far, with the exception of using mind maps, we have been discussing the traditional method for planning projects, commonly known as the “waterfall” approach. Traditional approaches have proven to work well for most projects. There are, however, projects for which the traditional methods do not suffice, mainly because they assume that the scope of the project can be well determined and the technology of developing the scope is well understood. This is not always the case.From time to time we have mentioned the fact that software and IT projects have had a very high failure rate—over budget, over schedule, and delivering less than the desired output. When compared to construction projects, for example, software projects are characterized by a much higher degree of uncertainty about the exact nature of the desired output, and often by a client (user) who does not understand the complexity of the projects and lacks the knowledge to communicate fully with the project team. The result, understandably, has a high probability of client dis- satisfaction with the completed project. (Much of the following description is based on Burba, 2013; Chi-Cheng, 2009; Fewell, 2010 and 2011; Hass, 2007; Hildebrand, 2010; Hunsberger, 2011; and Jackson, 2012.) The major source of the problem appears to be the complexity of modern business organiza- tions. They are involved in complex relationships with each other, with multiple governments and external stakeholders, with customers, with suppliers, and operate in an environment of rapid technological change and intense global competition. Their need for complex information systems is a result of the complexity in which they operate.APM is distinguished by this close and continuing contact between clients (users) and the project team, and an iterative and adaptive planning process. Project requirements are a result of client/team interaction, and the requirements change as the interaction leads to a better understanding on both sides of the project requirements, priorities, and limitations. Another difference from the waterfall approach with its emphasis on schedule first, then the scope, and lastly the team is that in APM the emphasis is on the team first, the client second, and the scope third.Project team membership will, of course, vary with the nature of the project and its deliverables. Agile IT project teams, for example, are typically small, located at a single site, and composed of a PM, the client/end user, an IT architect, two code writers, and a business analyst in the client’s industry. As noted above, the group develops the project requirements and priorities. One requirement is selected, usually the highest value or priority or most complex item, and the team tackles that item. The resulting output is tested by a test case developed during the requirements development phase. The entire team collaborates in dealing with the requirements. The PM’s role is to “facilitate” rather than to “control” the process.Given several requirements, the team deals with them one at a time. Not uncommonly, the solution to a second or third requirement may depend on altering the solution to the first requirement. One consultant notes that if the client changes the requirements, “we just deliver the new requirements” and ignore the previous ones. If the client wants more, they simply expand the engagement. Note however, that within each sprint, agile has to still meet schedule, budget, and scope expectations. Although agile provides flexibility, the trade-off is a loss of efficiency. This iterative process is not only collaborative, it must also be adaptive.It is also obvious that problem-oriented team members who have the interpersonal skills needed for collaboration are a necessity. The willingness of team members to share knowledge is an essential condition for agile projects. Not incidentally, the willingness to share knowledge is also a key to success in traditionally organized projects. A PM who attempts to control an agile project as he might control a traditional project is most certainly the wrong person for the job. The details of conducting an agile project are available through any chapter of the PMI, and the applicability of APM is much broader than just the software/IT area and has recently been expanded in use to extremely large projects. Any project that involves a high-risk technology, varying requirements, unusual complexity, great volatility, high uncertainty, short delivery time, a rapidly changing business environment, and is especially innovative or experimental is a candidate for APM, but success requires personnel who are qualified by personality, knowledge, and a desire for the APM experience.6.4 INTERFACE COORDINATION THROUGH INTEGRATION MANAGEMENTThis section covers the PMBOK knowledge area 1 concerning Project Integration Management. The most difficult aspect of implementing the plan for a complex project is the coordination and integration of the various elements of the project so that they meet their joint goals of scope, schedule, and budget in such a way that the total project meets its goals. As projects become more complex, drawing on knowledge and skills from more areas of expertise—and, thus, more subunits of the parent organization as well as more outsiders—the problem of coordinating multidisciplinary teams (MTs) becomes more troublesome. At the same time, and as a result, uncertainty is increased. As the project proceeds from its initiation through the planning and into the actual process of trying to generate the project’s deliverables, still more problems arise. One hears, “We tried to tell you that this would happen, but you didn’t pay any attention.” This, as well as less-printable remarks, are what one hears when the members of an MT do not work and play well together—in other words, when the various individuals and groups working on the project are not well integrated. Rather than operating as a team, they work as separate and distinct parts, each of which has its own tasks and is not much interested in the other parts.The intricate process of coordinating the work and timing of the different groups is called integration management. The term interface coordination is used to denote the process of managing this work across multiple groups. The RACI matrix discussed earlier is a useful aid to the PM in carrying out this task. It displays the many ways the members of the project team (which, as usual, includes all of the actors involved, not forgetting the client and outside vendors) must interact and what the rights, duties, and responsibilities of each will be.Recent work on managing the interfaces focuses on the use of MTs to plan the project as well as design the products/services the project is intended to produce. There is general agreement that MT has a favorable impact on product/service design and delivery. Work by Hauptman et al. (1996, p. 161) shows that MTs have had a “favorable impact . . . on attainment of project budget goals, but achieves this without any adverse impact on quality, cost or schedule.” The process also was associated with higher levels of team job satisfaction.ociated with higher levels of team job satisfaction. The use of MTs in product development and planning is not without its difficulties. Successfully involving cross-functional teams in project planning requires that some structure be imposed on the planning process. The most common structure is simply to define the task of the group as having the responsibility to generate a plan to accomplish whatever is defined as the project scope. There is considerable evidence that this is not sufficient for complex projects. Using MT creates what might well be considered a “virtual” project. In Chapter 4, we noted the high level of conflict in many virtual projects. It follows that MT tends to involve conflict. Conflict raises uncertainty and thus requires risk management. Obviously, many of the risks associated with MT involve intergroup political issues. The PM’s negotiating skill will be tested in dealing with In addition to mapping the interfaces (a necessary but not sufficient condition for MT peace), the process of using MTs on complex projects must be subject to some more specific kinds of control. One of the ways to control any process is to break the overall objectives of the process into shorter term phases (frequently using natural milestones) and to focus the MT on achieving the milestones, as is done in agile project management. If this is done, and if multidisciplinary cooperation and coordination can be established, the level of conflict will likely fall. At least there is evidence that if team members work cooperatively and accomplish their short-term goals, the project will manage to meet its long-term objectives; moreover, the outcome of any conflict that does arise will be creative work on the project.The project life cycle serves as a readily available way of breaking a project up into component phases, each of which has a unique, identifiable output. Careful reviews should be conducted at the end of each “phase” of the life cycle, with feedback given to the entire project team each time a project review was conducted.Another attack on the same problem was tied to project quality, again, via the life cycle (Aaron et al., 1993). They created 10 phase-gates associated with milestones for a software project. To move between phases, the project had to pass a review. (They even note that in the early stages of the project when there is no “inspectable product,” that “. . . managing quality on a project means managing the quality of the subprocesses that produce the delivered product.” Emphasis in the original.) While feedback is not emphasized in this system, reports on the finding of project reviews are circulated. The quality-gate process here did not allow one phase to begin until the previous phase had been successfully completed, but many of the phase-gate systems allow sequential phases to overlap in an attempt to make sure that the output of one phase is satisfactory as an input to the next. Another approach that also overlaps phases is called “fast tracking,” and here the phases are run in parallel as much as possible to reduce the completion time of the project; of course, this also increases the project risk as well. (The use of the phase-gate process for project control is demonstrated in Chapter 11, Section 11.2.)There are many such interface control systems, but the ones that appear to work have two elements in common. First, they focus on relatively specific, short-term, interim outputs of a project with the reviews including the different disciplines involved with the project. Second, feedback (and feed-forward) between these disciplines is emphasized. No matter what they are called, it must be made clear to all involved that cooperation between the multiple disciplines is required for success, and that all parties to the project are mutually dependent on one another. Finally, it should be stressed that phase-gate management systems were not meant as substitutes for the standard time, cost, and scope controls usually used for project management. Instead, phase-gate and similar systems are intended to create a process by which to measure project progress, to keep projects on track and aligned with the current strategy, and to keep senior management informed about the current state of projects being carried out.6.5 PROJECT RISK MANAGEMENTThere has been a great leap of interest in risk management in the last few years to the point that 71 percent of organizations now practice risk management, according to Brox (2012b). Marcelino- Sadaba et al. (2014) designed and tested a simple but thorough project risk management methodology/guide for small- to medium-sized enterprises that considered a variety of project types in both manufacturing and service organizations. They found that the time required to use the guide averaged 3.77 percent of the total project time for their test projects, which consumed about one person per year of a 40-hour per week effort (or two people for 6 months, four people for 3 months, etc.). They also found that this percentage dropped with larger projects, since setup time tended to take the same amount of time regardless of project size. In addition, the guide was easily understood and used by experienced managers, even if they had no experience in project management. The most difficult task the managers faced was identifying metrics for project success that included non-financial aspects such as customer satisfaction, meeting requirements and objectives, and project value. The main problem encountered was applying the guide to outsourced tasks of the project. Secondary problems related to communicating with external stakeholders and finding the right definition of the project objectives.Although there are many processes that can be used to control risk, the human factor is still probably the major element in risk management. As described in PMBOK, the risk attitudes of both organizations and individual stakeholders can be influenced by their risk appetite (what level of risk they are willing to assume), tolerance (the amount of risk they can withstand), and threshold (the amount of risk they are willing to take on to achieve a specific reward). Their risk attitude can be influenced by their perceptions, biases, and tolerances.Brox (2012b) also points out that communications regarding risk should be tailored to the stakeholder audience being addressed, since they each will have very different concerns about project risks. Specifically, senior managers will want a summarized version of the risk issues such as their severity and likelihood, and what trade-offs are available. On the other hand, team members are best informed through regular team meetings and will want to know the details about how the risks will affect their work, how priorities were decided, and how the risks will be mitigated. The business managers are more interested in the big picture and whether the project will be finished on time and budget; that is, the potential impact on the relationship with the client. If multiple issues exist, it is best to group them by some commonality such as root cause, consequences, or mitigation method. Last, external stakeholders must be handled delicately, and in separate groups depending on their interests in the project. It is best to avoid jargon and give full and detailed explanations, all while emphasizing the benefits of the project to their interests. Some recent books on project risks and ways of handling them are: Hillson et al. (2012), Jordan (2013), Royer (2000), Salkeid (2013), and Ward et al. (2012).This section covers the PMBOK knowledge area 8, concerning Project Risk Management. The Project Management Institute’s (PMI) publication A Guide to the Project Management Body of Knowledge (PMBOK Guide) 5th Edition, 2013, states that “project risk* management includes the processes of conducting risk management planning, identification, analysis, response planning, and controlling,” and as we shall see below, another subprocess needs to be added.1. Risk Management Planning—deciding how to approach and plan the risk management activities for a project. 2. Risk Identification—determining which risks might affect the project and documenting their characteristics.3. Qualitative Risk Analysis—performing a qualitative analysis of risks and conditions to prioritize their impacts on project objectives. 4. QuantitativeRiskAnalysis—estimatingtheprobabilityandconsequencesofrisksandhencethe implications for project objectives.5. RiskResponsePlanning—developingproceduresandtechniquestoenhanceopportunitiesand reduce threats to the project’s objectives. 6. Risk Monitoring and Control—monitoring residual risks, identifying new risks, executing risk reduction plans, and evaluating their effectiveness throughout the project life cycle. We add here a seventh subprocess, based on the discussion concerning the identification of risks in PMBOK.7. The Risk Management Register—creating a permanent register of identified risks, methods used to mitigate or resolve them, and the results of all risk management activities.1. Risk Management PlanningIt is never too early in the life of a project to begin managing risk. A sensible project selection decision cannot be made without knowledge of the risks associated with the project. Therefore, the risk management plan and initial risk identification must be carried out before the project can be formally selected for support. The risk management group must, therefore, be formed as soon as a potential project is identified. At first, project risks are loosely defined—focusing for the most part on externalities such as the state of technology in the fields that are important to the project, business conditions in the relevant industries, and so forth. The response to external risks is usually to track the pertinent environments and estimate the chance that the project can survive various conditions. . Not until the project is in the planning stage will such risks as those associated with project technology, schedule, budget, and resource allocation begin to take shape.Kaplan et al. (2012) have concluded that managing risks depends on which of three types of risks are being faced. First, there are preventable risks from within the organization and are thus controllable through active preventive measures such as mission or value guidelines, strict boundary limits conveyed through the organization’s culture and code of conduct, senior role models, strong internal control systems, and the audit function. Second are strategy risks from the risks the organization takes to conduct profitable or viable activities. Here risks can be controlled through a risk management system to reduce, contain, or control the risks by means such as independent outside experts who challenge management thinking, embedded internal experts, or a risk-management group that collects information and evaluates and prioritizes the risks. With all these approaches, the result is not necessarily to decrease the risks but perhaps to even increase the risks, if that looks feasible to achieve higher rewards. And third are external risks—economic, legal, natural, political, competitive—that are beyond the organization’s control or influence. Here a risk system is needed that will identify these risks and find ways to mitigate their impact. In addition to the approaches used for strategy risks, other techniques have included stress tests, scenario planning, and war-gaming.Because risk management often involves analytic techniques not well understood by PMs not trained in the area, some organizations put risk specialists in a project office, and these specialists staff the project’s risk management activities. For a spectacularly successful use of risk management on a major project, see Christensen et al. (2001), a story of risk management in a Danish bridge construction project. Ward (1999) describes a straightforward method for conducting PMBOK’s six subprocesses that includes a written report on risk management, if not the creation of a risk register. Two major problems in the way that risk management is carried out by the typical organization are that (1) risk identification activities routinely fail to consider risks associated with the project’s external environment; and (2) they focus on misfortune, overlooking the risk of positive things happening.2. Risk IdentificationThe risks faced by a project are dependent on the technological nature of the project, as well as on the many environments (economic, cultural, etc.) in which the project exists. Indeed, the manner in which the process of risk management is conducted depends on how one or more environments impact the project. The corporate culture is one such environment. So consider, for instance, the impact of a strong corporate “cost-cutting” emphasis on how risk managers identify project risks— they will probably focus on the project’s cost elements, such as personnel and resource allocation. (Note that this culture will carry over to the process of risk management as well—carrying out the six or seven subprocesses—not merely to the identification of risks.)The need to consider the many environments of almost any project is clear when one examines the recent articles on risk management (e.g., Champion, 2009; Taleb, 2009). It is typical to consider only the internal environment of the project, for example, the technical and interpersonal risks, and occasionally, negative market risks for the project. Articles on risks in IT and software projects rarely go beyond such matters—Jiang et al. (2001) is an example. This is a thoughtful development of a model for generating numerical measures for IT project risks. The specific user of the IT and the institutional setting of the project are considered, but competitors, the IT market, user industries, the legal environment, and several other relevant environments are ignored.In Chapter 2 we described the use of the Delphi method for finding numeric weights and criteria scores for the important factors in selecting projects for funding. The Delphi method is also useful when identifying project risks and opportunities for risk analysis models. Indeed, one of the first applications was forecasting the time period in which some specific technological capability would become available. The Delphi method is commonly used when a group must develop a consensus concerning such items as the importance of a technological risk, an estimate of cash flows, a forecast of some economic variable, and similar uncertain future conditions or events. Other such methods are “brainstorming,” “nominal group” techniques, checklists, attribute listing, and other such creativity and idea generation methods (see the website of this book for descriptions).Cause-effect (“fishbone”) diagrams (see Figure 6-11), flow charts, influence diagrams, SWOT analysis, and other operations management techniques (Meredith et al., 2013) may also be useful in identifying risk factors. The flexibility of cause-effect diagrams makes them a useful tool in many situations. For example, the outcome of “failure” of the project can be the outcome on the right side of the fishbone and then the major factors that could cause that—bad economy, performance weakness, high pricing, competing products, etc.—can be the stems that feed into this failure, and the reasons for these various factor failures can be added to the stems. Similarly, we could put the failure factor “performance weakness” as the outcome on the right and list the factors that might cause that: weak engineering, poor materials, etc. Alternatively, we might look at the “risk” that the project might be a great success, much better than we had expected, and the factors that might cause that to occur: beat competing products to the market, booming economy, exceptionally low price, and other such positive reasons.Another approach to identifying risks is to watch for early warning signs (EWS) as the project begins and progresses through to completion. Williams et al. (2012) did a study on EWS and responses to them and found that project managers were not good at detecting or acting on EWS because of an optimism bias, excessive faith in more experienced managers, interpersonal effects, group thinking, political pressure, the organizational culture, and limited time for problem- searching. All this was especially true when the project was complex, had high uncertainties, was considered to be unique, and even when a strict stage gate procedure was in place that clearly stated what exactly was to be reviewed—and in these cases required more insight/gut feel to identify risks. Better communication, knowledge, and experience also helped in these situations. In any event, it was found that the risk assessment process itself was much more important in identifying risks than the measures employed.Williams et al. also found that the EWS changed over the course of the project and were able to identify three project stages with the most common EWS. The first was during the setup of the project, and here the primary EWS were unclear goals, tenuous assumptions, and confusion about how the project work fit with the goals and expected benefits of the project. In the early stage, the EWS related more to the stakeholders in the project and included confusion over who was responsible for what, team over-reliance on outside consultants, and vague answers to questions and criticisms. Then in the execution stage, the EWS were lack of documentation, a constant churn of people, continually unfulfilled promises, people greatly over or under- working, frequently changing decisions, and excessive subcontractor claims and requests for time extensions. Overall EWS for the entire project were of two types: measures/assessments, and gut feel. EWS of the former included missing numbers or information, incomplete or missing documents, late/unclear reports, and missed milestones. EWS of the latter were generally poor communication, a strained atmosphere, lack of trust, arguments, and changes in position on issues over time.3. Qualitative Risk AnalysisThe purpose of qualitative risk analysis is to prioritize the risks identified in the previous step so attention can be directed to the most important ones. The qualitative nature of this process makes it quite flexible, useful, and quick to apply; also, it can be used for both threats and opportunities. A subjective (or if available, objective) estimate of the probability of the risk occurring is needed, perhaps from a Delphi approach used with a group of experts in the risk area. The probability values need not be precise, and for that matter could just be a rank on a 1 to 5 scale, or even simply “low,” “medium,” or “high.”A sense of the impact of the threat or opportunity is also needed, and should consider all important objectives of the project, including cost, timing, scope, and ancillary objectives. To attain an overall measure of the impact, each objective should be scaled and weighted in importance. Then the impact of the threat on each objective can be found in a fashion similar to the “Getting Wheels” scoring model described in Chapter 2 with the result being a percentage of 100, a number from 1 to 5, or again just “low, medium, or high.”Once the probability and impact levels are found, a Risk Matrix can be constructed as in Figure 6-12. Here we just show the simplest version with nine cells corresponding to “low, medium, and high” categories, but a 1 to 5 range would have 25 cells to consider and a per- centage of 100 could be divided into as many cells as would be useful. As we see in Figure 6-12, for example, we have identified as “critical” those threats with a high value on one measure and a medium or high value on the other measure: in this case, high probability–medium impact, high on each, and medium probability–high impact. The other cells can be categorized in a similar fashion, and here we used just three categories in a symmetrical manner: “critical,” “monitor,” and “ignore.” However, for some threats it may be appropriate to use four, or perhaps just two, categories, and the cells may be categorized differently for each threat. Conversely, if the Risk Matrix cell categories seem appropriate for all threats, then one matrix can be used to illustrate the distribution of all threats, as we have done in Figure 6-12 by listing the five threats (for example) in their corresponding cells.Finally, the same approach can be used for opportunities, considering the possibility of positive impacts. In this case, the matrix shows which risk opportunities are most important to focus attention on and try to bring about and which to ignore. The responses to both critical threats and critical opportunities will be discussed in Step 5.Another approach was used by Steffey et al. (2011) and is especially relevant for international projects. They formed four risk categories and grouped all the measures/factors under them. One was cultural, which included levels of trust, the economy (interest and inflation rates, exchange rates, etc.), the number of religions, and the number of languages used. Another category was political and included governmental unrest, laws, taxes, labor unions, ties to the government, and environmental activists. The third was regional and included climate/weather, crime rate, housing, safety, infrastructure, the workforce, and geography. The last was virtual, composed of number of countries involved, span of time zones, communication, technology, management experience, and organizational structure. They then scored each factor for the project on a 1to 7 scale and plotted the results on a radial (spider/pie) chart with each category taking up one quadrant of the circle and each of the important factors listed within that category. Connecting the points on the chart results in a star-type of plot that could then be compared to other project charts to see which is the most risky and on what categories and factors.4. Quantitative Risk AnalysisA quantitative risk analysis is sometimes conducted after the qualitative risk analysis has identified the critical (and perhaps some of the “monitor”) risks facing a project. It is more precise (using more precise quantitative data) and typically more accurate, if the data are available. We include here three techniques: (1) Failure Mode and Effect Analysis (FMEA) is a more rigorous approach to the Risk Matrix and includes an additional factor in the process, (2) decision tree analysis using expected monetary values, and (3) simulation.Failure Mode and Effect Analysis (FMEA) FMEA (Stamatis, 2003) is the application of a scoring model such as those used for project selection in Chapter 2. It is straightforward and extensively used, particularly in engineering, and is easily applied to risk by using six steps.Failure Mode and Effect Analysis (FMEA) FMEA (Stamatis, 2003) is the application of a scoring model such as those used for project selection in Chapter 2. It is straightforward and extensively used, particularly in engineering, and is easily applied to risk by using six steps.1. List the possible ways a project might fail. 2. Evaluatetheseverity(S)oftheimpactofeachtypeoffailureona10-pointscalewhere“1”is“no effect” and “10” is “very severe.” 3. Foreachcauseoffailure,estimatethelikelihood(L)ofitsoccurrenceona10-pointscalewhere “1” is “remote” and 10 is “almost certain.”4. Estimate the inability to detect (D) a failure associated with each cause. Using a 10-point scale, “1” means detectability is almost certain using normal monitoring/control systems and “10” means it is practically certain that failure will not be detected in time to avoid or mitigate it.Threat Severity, S Likelihood, L Ability to Detect, D RPN1. Tight schedule 6 7.50 2 902. Can’t acquire tech knowledge 8.50 5 4 1703. Client changes scope 4 8 5 1604. Costs escalate 3 2 6 365. Recession 4 2.5 7 705. Find the Risk Priority Number (RPN) where RPN = S × L × D. 6. ConsiderwaystoreducetheS,L,andDforeachcauseoffailurewithasignificantlyhighRPN. (We discuss this in Step 5: Risk Response Planning.)Table 6-1 illustrates the use of FMEA for the same five threats we considered in Step 4 previously, but here we use more precise data. As we see from the RPN numbers, the biggest threats are: Can’t acquire tech knowledge (2), and Client changes scope (3). Threat 2 has a great severity, should it occur, and threat 3 is quite likely, though the severity is much less damaging. The cost threat (4) and the recession threat (5) can probably be ignored for now since their likelihoods are so low. The tight schedule (1) will have some repercussions and is also quite likely, but we will see it coming early and can probably take steps to avoid or mitigate it. Some extensions of FMEA use additional scoring categories such as Ability to Mitigate (even if the threat cannot be detected).Decision Tree Analysis This tool (Meredith et al., 2002) is simple in concept and especially useful for situations where sequential events happen over time. For example, it would be appropriate for calculating the probability of getting one head and one tail in two tosses of a fair coin, or perhaps the probability of getting a head on the first toss and a tail on the second toss (which would have a different probability), or just the probability of getting a tail on the second toss. If we are only interested in probabilities, we call the tree a probability tree. But if there are some actions we are considering anywhere along the tree—before the first probability event, say, or between events—and we want to evaluate which action(s) would be best, then it is called a decision tree. Figure 6-13 illustrates such a tree (a solved one, here), but a very simple one with only one set of actions to choose from and one set of events; however, it could be extended to multiple actions and/or events, if desired, quite easily.A decision tree is created from the left (but solved from the right, at the end), with either a decision node (a square) or a probability node (a circle) occurring first. In the example shown, an automobile manufacturer is considering whether a new car model development project should consider only a gas model, only a hybrid model, or both gas and hybrid models. In this example there are three options being considered so there are three alternatives emanating from the decision node, each one posing some risk and opportunity depending on what happens to the price of fuel over the coming years. Thus, there is an event that affects the returns the auto manufacturer gets; in this case we have simplified the possible event outcomes into three categories of “gas prices increase,” “gas prices fluctuate up and down,” or “gas prices decrease.” (Note that the probabilit- ies of each outcome are identical for each decision choice because the decision the auto manufacturer makes does not affect the price of gas.) Under each possible outcome of the event (whose probabilities we need to be able to estimate), the auto manufacturer’s decision choice will result in a different payoff, shown on the far right. Note, for example, that if the auto manufacturer chooses to develop only a hybrid model and gas prices decrease, the firm would expect to lose $200 million dollars. To evaluate each of these outcomes and make a decision, the auto manufacturer needs a decision rule. If our rule was to “never pursue any alternative that might lose money,” then this two-outcome policy would rule out the hybrid only decision alternative. Another rule, if the decision makers at the auto manufacturer were optimists, might be to pursue whichever alternative provides the greatest opportunity for maximizing the payoff, in which case the auto manufacturer would choose the hybrid only option with a maximum payoff of $1,500 million from “gas prices increase.” However, we normally use a different rule, called Expected Monetary Value (abbreviated EMV) because this maximizes our return over the indefinite future, that is, the long run average. The process of “solving” the decision tree is to work from the right, with the outcomes (profits, in this case), and multiply each outcome times the probability of the event resulting in that outcome, called the expected value of that outcome, and then adding up all the expected values for that event node- decision choice combination. For example, the EMV for event node 2 would be (0.5 × 1200) + (0.3 × 600) + (0.2 × 300) = 840, which we write on the tree next to its event node. When we have done this with all of the event nodes for that decision, we compare them, double strike the lesser valued decision choices, and can then choose the best alternative choice for that decision node, in this case, developing a “gas only model.”The use of decision trees for risk analysis easily handles both threats and opportunities, as seen in the example. The tool is attractive because it visually lays out everything that may happen in the future (that is, all risks and all decision choices). The tree can be used for individual risks, if they are independent, or joint risks on the same tree. For example, in our earlier use of FMEA, we might have interdependencies between risk 2 (can’t acquire tech knowledge) and risk 3 (client changes scope).Monte Carlo Simulation Like decision trees, simulation (see Meredith et al., 2002) can also handle both threats and opportunities, and sequential events as well. We start with a model; for example, “Estimated Revenues minus Estimated Costs equals Expected Profits.” The advantage of simulation is that we don’t need to divide probabilistic events into a limited number of categories. Instead, we estimate optimistic, typical, and pessimistic values for each probabilistic input, and use standard distributions for these events. We then randomly select inputs from these distributions a thousand or more times to generate a frequency distribution of outcomes. The frequency distributions thereby give us the probabilities of losing more than a certain amount of money, or making at least a certain amount, or taking longer, or shorter, than a certain amount of time to complete the project, and other such important information. We include two examples of this approach. In Chapter 7 we simulate project cash flows and inflation rates that are uncertain and thus subject the project to monetary risk. Then in Chapter 8 we simulate the task times of project activities to determine the effect on the overall project completion time and the risk probability of being late.Sensitivity Analysis Sensitivity analysis, or what-if analysis, can be used for both quantitative models, its most common use, but also with qualitative models. The process is to go back into the model and change one of the parameters or variables, and see what the impact is on the final result. In this way, we can see what will have a major effect on the result, and thus our decision about what to do, and what won’t affect it, or will have a trivial effect on the results so we don’t need to worry about it. For example, with FMEA, we might see what a change in the severity of a threat might do, or in a decision tree, how the change in an outcome will change the result, or in simulation what changing a distribution might do to our profits. We can also consider what adding a new threat might do to our analysis, or adding a new branch in the decision tree, or inflation in our simulation. One weakness of sensitivity analysis is that a single change in the environment doesn’t usually happen, and instead many variables or parameters commonly change at the same time, which is harder to check and determine how it might affect our decision.There is also a form of scenario sensitivity analysis, where the impact of alternative developments or scenarios in the completion of the project are predicted. For example, what would be the impact on the success of the project if the PM left the organization? If a major contractor suffered a strike by a labor union? If an important new technology did not perform as expected? If a competitor beat us to market? Once alternative scenarios are identified, they can be analyzed with the tools discussed earlier, including FMEA, decision trees, and Monte Carlo simulation. Contingency plans should be developed for scenarios where the predicted impact is particularly severe.Dealing with Project Disasters Thus far, we have focused mainly on risks that might be considered normal for any firm undertaking projects. We have dealt with these risks by using an “expected value” approach, as in the PsychoCeramic Sciences example in Chapter 1; that is, the estimated loss (or gain) associated with a risky output times the probability that the loss (or gain) will occur. We might also compare the expected loss associated with a risk to the associated expected cost of mitigating or preventing the loss associated with the risk. If the reduction in expected loss due to risk mitigation or prevention is greater than its cost, we would invest in the risk mitigation/prevention.But what about the case when the loss is catastrophic, even potentially ruinous, though it may have a very low probability of occurring; e.g., a run on a bank; a strike at a critical supplier’s plant; a flood that shuts down a construction project; an attack by a terrorist group on a building; or the discovery that a substance in a complex drug might cause toxic side effects? In many such cases, the cost of the risk may be massive, but the likelihood that it will occur is so small that the expected cost of the disaster is much less than many smaller, more common risks with far higher probabilities of occurring. This is typical of situations for which we purchase insurance, but what if such insurance is unavailable (usually because the pool of purchasers interested in such insurance is too small)? In the Reading: Planning for Crises in Project Management at the end of this chapter, the authors suggest four approaches for project disaster planning: risk analysis, contingency planning, developing logic charts, and tabletop exercises. An excellent book, The Resilient Enterprise (Sheffi, 2005), deals with risk management concerning many different types of disasters. The book details the methods that creative businesses have used to cope with catastrophes that struck their facilities, supply chains, customer bases, and threatened their survival. The subject is more complex than we can deal with here, but we strongly recommend the book.5. Risk Response Planning There are four standard approaches for dealing with risk threats, and somewhat equivalently, for enhancing risk opportunities. For threats, the four are: avoid, transfer, mitigate, and accept. For opportunities, they are: exploit, share, enhance, and accept. We describe the threat responses first.• Avoid Theideahereistoeliminatethethreatentirely.Thismightbeaccomplishedbyusing alternative resources, or adding contingent resources, at some cost of course. If the threat is client scope creep, up-front avoidance by adding scope change procedures to the contract might avoid the threat. If the threat is cost overrun, up-front de-scoping of project objectives in agreement with the client might avoid the threat. If the threat is schedule delay, contingency planning for schedule extensions might be written into the project contract. The extreme solution, of course, is to cancel the project if the threat is too great, such as bankruptcy.• Transfer Although this approach does not eliminate the threat, it does remove the project contractor from the danger of the threat. The classic approach here for monetary risk is insurance, but other approaches are also available: warranties, bonding, cost-plus contract- ing, etc. For nonmonetary threats such as performance, or schedule, one alternative is for the client to contract (not subcontract) with another vendor for the portions of the project that are threatened, responsibility to the client resting with the other contractor, of course. In fact, the safest approach is to let the client perform some of these portions of the project themselves.• Mitigate This is a “softening” of the danger of the threat, either through reducing the likelihood it will occur, or through reducing its impact if it does occur. Ways to reduce the likelihood are to do research or testing to improve our understanding of the probability elements of the threat and then spend some effort (and money) on reducing the more probable threats. Such efforts might involve using better materials, employing more reliable sources, simplifying the processes, shifting task times to more reliable periods, and so on, all of which usually require some investment and increase costs. For reducing the impact, similar approaches can be employed such as providing back-up resources, authorizing parallel efforts, including redundancy in a system, and other such approaches, which can also be expensive.• Accept The risk is accepted, either because no other response is available or because the responses are deemed too costly relative to the risk threat. This might be appropriate for non-critical threats, such as those in the “ignore” category of the risk matrix. For the critical threats, the project contractor should create a “contingency plan” so that if the threat does arise, everyone knows what actions will be taken to handle the threat. This might take the form of additional monetary or human resources, but the conditions for invoking the plan should be decided in advance so there is no confusion about whether the plan should be invoked.We now consider the approaches for opportunities. Our discussion follows that for threat risks and many of the same ideas and examples discussed there can be applied here also. • Exploit The goal here is to try to increase the probability the opportunity will occur. This might be done with higher quality resources, such as equipment, materials, or human skills, again at a cost.
• Share This involves partnering with another party or parties who can better capture the value of the opportunity, or at least reduce the cost of exploiting the opportunity. Joint ventures and risk-sharing partnerships are good examples of this approach.• Enhance Like “mitigate” above, this involves either increasing the probability the opportunity risk will occur, or increasing its impact if it does. Again, additional resources are typically required, such as increasing the quality of the resources or the number of resources to either increase the probability or the impact of the opportunity, or both. • Accept Here the project firm is prepared to capitalize on the opportunity should it occur (a contingency plan), but is not willing to invest the resources to improve the probability or impact of the opportunity occurring.6. Risk Monitoring and Control
Bowles (2011) suggests four risk-oriented measures that organizations should track: (1) How often a risk assessment is conducted/updated; (2) How often a risk assessment is reviewed; (3) The number of risks initially rated as low that later became high; and (4) The percentage of actual risks that developed that had been identified beforehand. The PMBOK lists risk reassessments as a major risk control tool for risk management, and also risk audits that examine and document the effectiveness of various risk responses, as well as the risk management process in general. The topic of monitoring will be covered in detail in Chapter 11 and control in Chapter 12, so we defer our remaining discussion of risk monitoring and control until we reach those chapters.7. The Risk Register If the risk management system has no memory, the task of risk identification will be horrendous. But the system can have a memory—at least the individuals in the system can remember. Relying on the recollections of individuals, however, is itself “risky.” To ensure against this particular risk, the risk management system should maintain an up-to-date risk register that includes, but is not restricted to, the following:• identification of all environments that may impact on the project • identificationofallassumptionsmadeinthepreliminaryprojectplanthatmaybeasourceof risk for the project • a list of all risks identified by the risk management group, complete with their estimated impacts on the project and estimates of their probability of occurring • a complete list of all “categories” and “key words” used to categorize risks, assumptions, and environments so that all risk management groups can access past work done on risk management • the details of all qualitative and quantitative estimates made on risks, on states of the project’s environment, or on project assumptions, complete with a brief description of the methods used to make such estimates• minutes of all group meetings including all actions the group developed to deal with or mitigate each specific risk, including the decision to ignore a risk• the actual outcomes of identified risks and, if a risk came to occur, the results of actions taken to mitigate or transfer the risk or invoke the contingency planIf all this work on data collection is going to be of value to the parent organization beyond its use on the project at hand, the risk register must be available to anyone proposing to perform risk management on a project for the organization. Almost everything a risk management group does for any project should be retained in the risk register. Second, all risks must be categorized, the environments in which projects are conducted must be identified, and the methods used to deal with or mitigate them must be described.The use of multiple key words and categories is critical because risk information must be available to managers of widely varied disciplines and backgrounds. Organizations may be conducting a great many projects at any given time. If each risk management team has to start from scratch, without reference to what has been learned by previous groups, the management of risk will be extremely expensive, take a great deal of time, and will not be particularly effective. Rest assured that even with all the experience of the past readily available, mistakes will occur. If past experience is not available, the mistakes of the past will be added to those of the future.Alderton (2012) reported on two risk registers, one more extensive that included many of the items in the above bulleted list and the other more direct that included just the vulnerability (schedule, budget, specific benefit, security); the level of risk (low, medium, high); a brief description of the threat; and the recommended risk response. Each risk was then plotted on a risk map (matrix) like Figure 6-12, and those risks of most concern in the upper right portion of the matrix were then carefully monitored. In summary, Alderton suggested: (1) that the risk register begin immediately at the project charter stage because the earlier the response to a developing risk, the less disruption incurred; (2) engaging diverse stakeholders in the risk management process because they can often see very different or unexpected risks; (3) re-evaluate the risks regularly; and (4) the best way to minimize scope risk is to engage the most competent people to work on the project.The PMBOK adds another important factor for the risk register—the risk attitudes of the various stakeholders. The risk management context is in reality a combination of not just the strategic risk exposure but also the risk attitudes of the stakeholders. Hence, it is the combination of these two elements, as captured on a strategic risk scoring sheet that identifies the true risks to a project.A final question remains. How well does risk management contribute to project success? Research by Krane et al. (2012) tried to discern how risk focus by the project team and risk focus by the client might differ and thus have an effect on project “success.” The thinking was that the team would be focused on short-term operational survival until turnover to the client, whereas the client would be focused on strategic benefits, both short-term client benefits and long-term societal benefits and sustainability. The results indicated that the major focus of both was on operational risks, but the client also focused somewhat on the short-term benefits. The fact that the owner only focused on the “top-10” of all the risks presented by the team probably led to this result.However, recent research by de Bakker et al. (2011) in the IS/IT industry has revealed that stakeholders deliberately use risk management to influence others to alter their behavior regarding their awareness of the project context and their responsibilities for the success of the project. Risk management activities seem to increase positive feelings and trust, and synchronize the perceptions of stakeholders, which stimulates action and increases its effectiveness, making for more predicta- ble situations and reduced uncertainty, which leads to increased project success. As noted earlier, it isn’t the measures or procedures of risk management which is the key, but the group awareness of threats to the project that seems to improve the chances of success. One final warning is appropriate to users of quantitative risk analysis methods. To quantify risk via simulation or any other scientific method is a reasonable picture of reality only to the extent that the assumptions made about the input data are accurate. Even if they are, such a picture of the future is not the same as managing it. As we have said elsewhere, models do not make decisions, people do. Risks should be understood, and once understood, people must decide what to do about them. Without this last step, risk identification and analysis are useless.This topic completes our discussion of project activity planning. Next, we address the subject of budgeting and look at various budgeting methods. The chapter also addresses the issues of cost estimation and its difficulty, and simulation to handle budgetary risk of both costs and revenues.SUMMARY In this chapter we initiated planning for the project in terms of identifying and addressing the tasks required for project com- pletion. We emphasized the importance of initial coordination of all parties involved and the smooth integration of the various systems required to achieve the project objectives. Then we described some tools such as the Work Breakdown Structure (WBS), the RACI matrix, and the Gozinto chart to aid in the planning process. We also briefly investigated several methods for controlling and reducing conflict in complex projects that use multidisciplinary teams. Last, we covered the process of risk management, for both threats and opportunities. Specific points made in the chapter are these:• The preliminary work plans are important because they serve as the basis for personnel selection, budgeting, scheduling, and control. • Top management should be represented in the initial coordinating meeting where technical objectives are established, participant responsibility is accepted, and preliminary budgets and schedules are defined. • The approval and change processes are complex and should be handled by the project manager.• Common elements of the project charter are the over- view, statement of objectives/scope, general approach, contractual requirements, schedules, resources, stake- holders, personnel, risk management plans, and evalua- tion procedures. • Mind mapping can greatly facilitate the project planning process. • The hierarchical approach to project planning is most appropriate and can be aided by a tree diagram of project subsets, called a Gozinto chart, and a Work Breakdown Structure (WBS). The WBS relates the details of each subtask to its task and provides the final basis for the project budget, schedule, personnel, and control. • A RACI matrix is often helpful to illustrate the relation- ship of personnel to project tasks and to identify where coordination is necessary. • When multifunctional teams are used to plan complex projects, their task interfaces must be integrated and coordinated. The use of milestones and phase-gates throughout the project’s schedule can help with this integration process.• Risk management for both threats and opportunities has become increasingly important as projects become more complex and ill-defined. The seven subprocesses involved in managing the risks include helpful tools such as cause- effectdiagrams,theriskmatrix,FMEA,decisiontrees,simu- lation, a risk register, and a set of standard risk responses.PROBLEMS1. Top administrators in a university hospital have approved a project to improve the efficiency of the pharmaceutical services department by the end of the fiscal year to satisfy new state regulations for the coming year. However, they are concerned about four potential threats: (1) The cost to implement the changes may be excessive, (2) The pharma- cists may resist the changes, (3) The project may run much longer than expected and not be ready for the coming fiscal year, and (4) The changes might reduce the quality of drug care in the hospital. The likelihood and negative impact of each threat have been solicited from the managers by a three- round Delphi process and are as follows, based on a seven- point scale where seven is the most likely and most negative impact: Construct a risk matrix and identify what you would con- sider to be the “critical,” “monitor,” and “ignore” threats. Explain your reasoning. Recommend and justify a risk response for each threat.Threat Probability Impact1 5 32 6 53 3 44 4 72. The project manager for the project in Problem 1 has estima- ted the probabilities of not detecting the risks in time to react to them as follows, again on a seven-point scale: Threat 1: 4, Threat 2: 1, Threat 3: 3, Threat 4: 6. Construct a FMEA table to determine which risks are now the “critical,” “monitor,” and “ignore” threats. How have they changed from Problem 1? Why? Does this new ranking seem more realistic?3. You might not have realized it, but getting a college degree is a project. Assume you are in a degree program in college and are concerned about getting your degree. Create a fishbone (cause–effect) diagram, with “failure to get degree” as the problem outcome. Identify at least four possible threat risks for this problem to occur. Then for each threat list at least three reasons/factors for how that threat could conceiv- ably come to pass. Finally, review your diagram to estimate probabilities and impacts of each threat to getting your degree. Based on this analysis, what threats and factors should you direct your attention to, as the project manager of your project to get your degree. Demand (units) Probability 1,000 .20 2,000 .30 3,000 .40 4,000 .104. The yearly demand for a seasonal, profitable item follows the distribution:A manufacturer is considering launching a project to produce this item and could produce it by one of three methods: a. Use existing tools at a cost of $6 per unit. b. Buy cheap, special equipment for $1,000. The value of the equipment at the end of the year (salvage value) is zero. The cost would be reduced to $3 per unit. c. Buy high-quality, special equipment for $10,000 that can be depreciated over four years (one fourth of the cost each year). The cost with this equipment would be only $2 per unit.Set up this project as a decision tree to find whether the manufacturer should approve this project, and if so, which method of production to use to maximize profit. Hint: Com- pare total annual costs. Assume production must meet all demand; each unit demanded and sold means more profit.5. Given the decision tree below for a two-stage (decision) project to enter a joint venture, find the best alternatives (among a1-a6 in the figure) and their expected values. The outcomes shown are revenues and the investment expenses are in parentheses. Node 4 represents the situation where alternative a1 was chosen, and then the top outcome with a 70 percent probability occurred; note that there is no choice of alternative if the 30 percent probability outcome occurred. Similarly with Node 5.6. 6. MedidataInc.hasidentifiedthreeriskopportunitiesfortheir new medical database project. One is an opportunity to ex- tend the database to include doctors as well as hospitals. This has a probability of a 3 and an impact on their profitability of a 3 on a 1–5 scale, where higher numbers are greater values of probability and profitability. Another is the oppor- tunity to extend the database to other countries, particularly in Europe. For this, the probability is ranked only a 2 but the profitability impact is considered to be 4 due to the higher social interest by European governments. Last, they might be able to interest nonusers such as pharmaceutical firms in using, or perhaps buying, their data. Here the probability is more certain, a 4, but the profitability would be only a 2. Construct an opportunity risk matrix, identify the “critical,” “monitor,” and “ignore” opportunities, and recommend risk responses for each opportunity.7. 7. In addition to your regular responsibilities, your supervisor has just assigned you to be in charge of your organization’s annual golf tournament. It is expected that 100 to 150 employees will enter the tournament. In addition to organiz- ing the event, you are also responsible for promoting it. Your budget for the event is $25,000. Develop a mind map to identify the tasks that need to be completed for the golf tournament project.INCIDENTS FOR DISCUSSIONRingold’s Pool and Patio Supply John Ringold, Jr., just graduated from a local university with a degree in industrial management and joined his father’s company as executive vice-president of operations. Dad wants to break John in slowly and has decided to see how he can do on a project that John Sr. has never had time to investigate. Twenty percent of the company’s sales are derived from the sale of above-ground swimming pool kits. Ringold’s does not install the pools. John Sr. has asked John Jr. to determine whether or not they should get into that business. John Jr. has decided that the easiest way to impress Dad and get the project done is personally to estimate the cost to the company of setting up a pool and then call some competitors and see how much they charge. That will show whether or not it is profitable.John Jr. remembered a method called the work break- down structure (WBS) that he thought might serve as a useful tool to estimate costs. Also, the use of such a tool could be passed along to the site supervisor to help evaluate the performance of work crews. John Jr.’s WBS is shown in Table A. The total cost John Jr. calculated was $185.00, based on 12.33 labor-hours at $15.00/labor-hour. John Jr. found that, on average, Ringold’s competitors charged $229.00 to install a similar pool. John Jr. thought he had a winner. He called his father and made an appointment to present his findings the next morning. Since he had never assembled a pool himself, he decided to increase the budget by 10 percent, “just in case.”Questions: Is John Jr.’s WBS projection reasonable? What aspects of the decision will John Sr. consider?Stacee Laboratories Stacee Labs, the research subsidiary of Stacee Pharmaceuticals, Inc., has a long history of successful research and development of medical drugs. The work is conducted by standalone project teams of scientists that operate with little in the way of schedules, budgets, and precisely predefined objectives. The parent company’s management felt that scientific research teams should not be encumbered with bureaucratic record- keeping chores, and their work should go where their inspira- tion takes them.A Special Committee of Stacee Pharm’s Board of Directors has completed a study of Stacee Labs and has found that its projects required a significantly longer time to complete than the industry average and, as a result, were significantly more expensive. These projects often lasted 10–15 years before the drug could be released to the market. At the same time, Stacee Labs projects had a very high success rate.The board called in a management consultant, Ms. Millie Tasha, and asked her to investigate the research organization briefly and report to the board on ways in which the projects could be completed sooner and at lower expense. The board emphasized that it was not seeking nit-picking, cost-cutting, or time-saving recommendations that might lower the quality of Stacee Labs’s results.Ms. Tasha returned after several weeks of interviews with the lab’s researchers as well as with senior representatives of the parent firm’s Marketing, Finance, Government Relations, and Drug Efficacy Test Divisions, as well as the Toxicity Test Department. Her report to the Board began with the observation that lab scientists avoided contact with Marketing and Govern- mental Relations until they had accomplished most of their work on a specific drug family. When asked why they waited so long to involve marketing, they responded that they did not know what specific products they would recommend for sale until they had completed and tested the results of their work. They added that marketing was always trying to interfere with drug design and wanted them to make exaggerated claims or to design drugs based on sales potential rather than on good science.Ms. Tasha also noted that lab scientists did not contact the toxicity or efficacy testing groups until scientific work was completed and they had a drug to test. This resulted in long delays because the testing groups were usually occupied with other matters and could not handle the tests promptly. It usually took many months to organize and begin both toxicity and efficacy testing.In Ms. Tasha’s opinion, the only way to make significant cuts in the time and cost required for drug research projects was to form an integrated team composed of representatives of all the groups who had a major role to play in each drug project and to have them involved from the beginning of the project. All parties could then follow progress with drug development and be prepared to make timely contributions to the projects. If this were done, long delays and their associated costs would be significantly reduced.Questions: Do you think Millie Tasha is right? If so, how should new drug projects be planned and organized? If Stacee Pharmaceutical goes ahead with a reorganization of lab projects, what are the potential problems? How would you deal with them? Could scope creep become more of a problem with the new integrated teams? If so, how should it be controlled?CONTINUING INTEGRATIVE CLASS PROJECTIt is now time to plan the project tasks and make assignments. First, schedule a team meeting and identify the work that must be done by creating a mind map. Once the initial mind map is created, have one team member clean it up and enter it into a software program (e.g., Word, PowerPoint, Visio, Mindjet MindManager). Distribute the cleaned up mind map until ideas are exhausted and the team believes it has a comprehensive list of the project activities. Next, convert the mind map to a work breakdown structure and a RACI matrix for the project. Identify any milestones and phase-gates. Evaluate the risks using the seven subprocesses and any appropriate tools. Make sure everyone is aware of their role in the project, their specific deadlines, and the available resources.Historian, observe the work processes and note areas where the team did well and areas for improvement. For example, was the project manager effective at including everyone in the planning process or did he or she allow a subset of the team to dominate the process? During the mind mapping, did the team focus on identifying the work that needed to be done or did they drift to discussing tangential topics such as the goals for the project. Based on your observations, what practices would you continue in future projects? What would you recommend doing differently?HEUBLEIN: PLANNING A PROJECT MANAGEMENT AND CONTROL SYSTEMHerbert F. Spirer and A. G. HulveyIntroduction Heublein, Inc., develops, manufactures, and markets con- sumer food and beverage products domestically and inter- nationally. Their Group sales revenues are shown in Figure 1. The four major Groups use different manufac- turing plants, equipment, and processes to produce their products. In the Spirits Group, large, continuous process bottling plants are the rule; in the Food Service and Franchising Group, small fast food restaurants are the “manufacturing plants.” The amount of spending for capital projects and support varies greatly among the Groups, as would be expected from the differences in the magnitude of sales revenues.The engineering departments of the Groups have responsibility for operational planning and control of capital projects, a common feature of the Groups. How- ever, the differences among the Groups are reflected in differences in the sizes of the engineering departments and their support services. Similarly, financial tracking support varies from full external support to self-main- tained records.Prior to the implementation of the Project Manage- ment and Control System (PM&C) described in this paper, the capital project process was chiefly concerned with the financial justification of the projects, as shown in Figure 2. Highlights include:A focus on cost-benefit analysis. • Minimal emphasis on execution of the projects; no mechanism to assure that non-financial results were achieved. • The following factors focused attention on the execution weaknesses of the process: • Some major projects went over budget. • The need for optimal utilization of capital funds intensified since depreciation legislation was not keeping pace with the inflationary rise in costs.Responding to these factors, Heublein’s corporate management called for a program to improve execution of capital projects by implementing PM&C. Responsibil- ity for this program was placed with the Corporate Facili- ties and Manufacturing Planning Department, which, in addition to reviewing all Capital Appropriation Requests, provided technical consulting services to the corporation.Feasibility Study. Lacking specialized expertise in proj- ect management, the Director of Corporate Facilities and Manufacturing Planning decided to use a consultant in the field. Interviewing of three consultants was under- taken to select one who had the requisite knowledge, compatibility with the style and goals of the firm, and the ability to communicate to all levels and types of manag- ers. The latter requirement was important because of the diversity of the engineering department structures and personnel involved. The first author was selected as the consultant.With the consultant selected, an internal program manager for PM&C was selected. The deferral of this choice until after selection of the consultant was deliber- ate, to allow for development of interest and enthusiasm among candidates for this position and so that both the selected individual and the selection committee would have a clear picture of the nature of the program. A program manager was chosen from the corporate staff (the second author). Having the key staff in place, ground rules were estab- lished as follows:• The PM&C program would be developed inter- nally to tailor it to the specific needs of the Groups. A “canned” or packaged system would limit this flexibility, which was deemed essential in this application of project management principles.• The directors of the engineering departments of each of the Groups were to be directly involved in both the design and implementation of the PM&C system in total and for their particular Group. This would assure the commitment to its success that derives from ownership and guarantees that those who know the needs best determine the nature of the system.To meet the above two ground rules, a thorough fundamental education in the basic principles of project management would be given to all involved in the system design.The emphasis was to be project planning as opposed to project control. The purpose of PM&C was to achieve better performance on projects, not catch mistakes after they have occurred. Success was the goal, rather than accountability or identification of responsibility for failureProgram Design. The option of defining a uniform PM&C system, to be imposed on all engineering depart- ments by corporate mandate, was rejected. The diversity of projects put the weight in favor of individual systems, provided planning and control was such that success of the projects was facilitated. The advantage to corporate staff of uniform planning and reporting was given second place to accommodation of the unique needs of each Group and the wholehearted commitment of each engi- neering manager to the effective use of the adopted system. Thus, a phased implementation of PM&C within Heublein was planned in advance. These phases were:Phase I. Educational overview for engineering depart- mentmanagers. Athree-dayseminarwithtwotop-level educational objectives: (1) comprehension by partici- pants of a maximal set of project management principles and (2) explanation of the corporate objectives and recommended approach for any PM&C system.Phase II. PM&C system design. A “gestation period” of three weeks was deliberately introduced between Phases I and II to allow for absorption, discussion, and review of the project management principles and objectives by the engineering department managers. At the end of this period a session was called for the explicit purpose of defining the system. The session was chaired by the consultant, a deliberate choice to achieve the “lightning rod” effect whereby any negative concern was directed to an outsider. Also, the consultant—as an outsider—could criticize and comment in ways that should not be done by the engineering department man- agers who will have long-term working relationships among each other. It was agreed in advance that a consensus would be sought to the greatest possible extent, avoiding any votes on how to handle particular issues which leaves the “nay” votes feeling that their interests have been overridden by the majority. If con- sensus could not be achieved, then the issue would be sidestepped to be deferred for later consideration; if sufficiently important, then a joint solution could be developed outside the session without the pressure of a fixed closing time.Phase III. Project plan development. The output of Phase II (the set of consensus conclusions) represented both guidelines and specific conclusions concerning the nature of a PM&C system. Recognizing that the PM&C program will be viewed as a model project and that it should be used as such, serving as an example of what is desired, the program manager prepared a project plan for the PM&C program. The remainder of this paper is primarily concerned with the discussion of this plan, both as an example of how to introduce a PM&C system and how to make a project plan. The plan discussed in this paper and illustrated in Figures 3 to 11 is the type of plan that is now required before any capital project may be submitted to the approval process at Heublein.Phase IV. Implementation. With the plan developed in Phase III approved, it was possible to move ahead with implementation. Implementation was in accordance with the plan discussed in the balance of this paper. Evaluation of the results was considered a part of this implementation.Project Plan. A feature of the guidelines developed by the engineering managers in Phase II was that a “menu” of component parts of a project plan was to be established in the corporate PM&C system, and that elements of this menu were to be chosen to fit the situational or corporate tracking requirements. The menu is:1. Introduction 2. Project Objectives 3. Project/Program Structure4. Project/Program Costs 5. Network 6. Schedule7. Resource Allocation 8. Organization and Accountability 9. Control System 10. Milestones or Project SubdivisionsIn major or critical projects, the minimal set of choices from the menu is specified by corporate staff (the defini- tion of a “major” or “critical” project is a part of the PM&C procedure). For “routine” projects, the choice from the menu is left to the project manager.In the PM&C plan, items 6 and 7, Schedule and Resource Allocation, were combined into one section for reasons which will be described as part of the detailed discussions of the individual sections which followIntroduction In this PM&C system, the Introduction is an executive summary, with emphasis on the justification of the project. This can be seen from the PM&C Program Introduction shown in Figure 3. It is to the advantage of everyone concerned with a project to be fully aware of the reasons for its existence. It is as important to the technicians as it is to the engineers or the corporate financial department. When the project staff clearly comprehends the reason for the project’s existence, it is much easier to enlist and maintain their support and wholehearted efforts. In the Heublein PM&C system, it is expected that the introduction section of a project plan will include answers to these questions: What type of project is involved? What is the cost-benefit relationship? What are the contingency plans? Why is it being done this way (that is, why were alternatives rejected)? Figure 3 not only illustrates this approach, but is the executive summary for the Heublein PM&C system.Objectives Goals for a project at Heublein must be stated in terms of deliverable items. To so state a project objective forces the definition of a clear, comprehensible, measurable, and tangible objective. Often, deliverable items resulting from a project are documents. In constructing a residence, is the deliverable item “the house” or is it “the certificate of occupancy”? In the planning stages of a project (which can occur during the project as well as at the beginning), asking this question is as important as getting the answer.Project Structure Having a definition of deliverables, the project manager needs explicit structuring of the project to: • Relate the specific objectives to the general. • Define the elements which comprise the deliver- ables. • Define the activities which yield the elements and deliverables as their output. • Show the hierarchical relationship among objec- tives, elements, and activities.The work breakdown structure (WBS) is the tool used to meet these needs. While the WBS may be represented in either indented (textual) or tree (graphical) formats, the graphic tree format has the advantage of easy compre- hension at all levels. The tree version of the WBS also has the considerable advantage that entries may be made in the nodes (“boxes”) to indicate charge account numbers, accountable staff, etc. Figure 5 is a portion of the indented WBS for the PM&C Program, showing the nature of the WBS in general and the structure of the PM&C Program project in particular. At this point we can identify the component elements and the activities necessary to achieve them. A hierarchical numbering system was applied to the ele- ments of the WBS, which is always a convenience. The 22 Design Phase Reports (2100 series in Figure 5) speak for themselves, but it is important to note that this WBS is the original WBS: All of these reports, analyses, and determinations were defined prior to starting the program and there were no requirements for additional items.Project Costs The WBS provides a listing of the tasks to be performed to achieve the project objectives; with only the WBS in hand it is possible to assemble a preliminary project estimate. The estimates based only on the WBS are preliminary because they reflect not only uncertainty (which varies considerably among types of projects), but because the allocation of resources to meet schedule difficulties cannot be determined until both the network and the schedule and resource evaluations have been completed. However, at this time the project planner can begin to hierarchically assemble costs for use at any level. First the lowest level activities of work (sometimes called “work packages”) can be assigned values. These esti- mates can be aggregated in accordance with the WBS tree structure to give higher level totals. At the root of the tree there is only one element—the project— and the total preliminary estimated cost is available.Figure 6 shows the costs as summarized for the PM&C program plan. This example is supplied to give the reader an idea of the nature of the costs to be expected in carrying out such a PM&C program in this type of situation. Since a project-oriented cost accounting system does not exist, out-of-pocket costs are the only incremental charges. Any organization wishing to cost a similar PM&C program will have to do so within the framework of the organiza- tional approach to costing indirect labor. As a guide to such costs, it should be noted that in the Heublein PM&C Program, over 80 percent of the costs—both out-of-pocket and indirect—were in connection with the General Training (WBS code 3000).Seminars were limited to two and two-and-a-half days to assure that the attendees perceived the educational process as efficient, tight, and not unduly interfering with their work; it was felt that it was much better to have them leaving with a feeling that they would have liked more rather than the opposite. Knowing the number of attendees, it is possible to determine the labor-days devoted to travel and seminar attendance; consultant/ lecturer’s fees can be obtained (expect preparation costs) and the incidentals (travel expenses, subsistence, print- ing, etc.) are easily estimated.Network The PM&C system at Heublein requires networks only for major projects, but encourages their use for all projects. Figure 7 shows a segment of the precedence table (used to create the network) for the PM&C Plan. All the usual principles of network creation and analysis (for critical path, for example) may be applied by the project manager to the extent that it facilitates planning, imple- mentation, and control. Considerable emphasis was placed on network creation and analysis techniques in the educational phases of the PM&C Program because the network is the basis of the scheduling methods presented, is potentially of great value, and is one of the hardest concepts to communicate. In the Heublein PM&C system, managerial networks are desired—networks which the individual project managers will use in their own management process and which the staff of the project can use to self-direct where appropriate. For this reason, the view toward the network is that no one network should exceed 50 nodes. The toplevel network represents the highest level of aggrega- tion. Each activity on that network may well represent someone else’s next lower level network consisting of not more than 50 nodes. This is not to say that there are not thousands of activities possible in a Heublein project, but that at the working managerial level, each manager or project staff person responsible for a networked activity is expected to work from a single network of a scope that can be easily comprehended. It is not an easy task to aggregate skillfully to reduce network size, but the exercise of this discipline has value in planning and execution in its own right.The precedence table shown reflects the interdependen- cies of activities for Heublein’s PM&C Program; they are dependent on the design of the Program and the needs of the organization. Each organization must determine them for themselves. But what is important is that institution of a PM&C Program be planned this way. There is a great temptation in such programs to put all activities on one path and not to take advantage of parallel activities and/or not to see just what is the critical path and to focus efforts along it.Schedule and Resource Allocation The network defines the mandatory interdependency relationships among the tasks on a project; the schedule is the realization of the intent of the project manager, as it shows when the manager has determined that tasks are to be done. The schedule is constrained in a way that the Organization and AccountabilityWho is responsible for what? Without clear, unam- biguous responses to this question there can be no assurance that the task will be done. In general, commit- tees do not finish projects and there should be one organizational unit responsible for each element in the work breakdown structure and one person in that orga- nizational unit who holds final responsibility. Thus responsibility implies a single name to be mapped to the task or element of the WBS, and it is good practice to place the name of the responsible entity or person in the appropriate node on the WBS.However, accountability may have multiple levels below the top level of complete responsibility. Some individuals or functions may have approval power, veto power without approval power, others may be needed for information or advice, etc. Often, such multilevel accountability crosses functional and/or geographical boundaries and hence communication becomes of great importance.A tool which has proved of considerable value to Heublein where multilevel accountability and geograph- ical dispersion of project staff is common is the “account- ability matrix,” which is shown in Figure 8.The accountability matrix reflects considerable thought about the strategy of the program. In fact, one of its great advantages is that it forces the originator (usually the project manager) to think through the process of implementation. Some individuals must be involved because their input is essential. For example, all engineer- ing managers were essential inputs to establish the exact nature of their needs. On the other hand, some individuals or departments are formally involved to enlist their support, even though a satisfactory program could be defined without them.Control System The basic loop of feedback for control is shown in Figure 9. This rationale underlies all approaches to controlling projects. Given that a plan (or budget) exists, we then must know what is performance (or actual); a comparison of the two may give a variance. If a variance exists, then the cause of the variance must be sought. Note that any variance is a call for review; as experienced project managers are well aware, underspending or early completions may be as unsatisfactory as overspending and late completions.The PM&C program did not involve large purchases, or for that matter, many purchases. Nor were large numbers of people working on different tasks to be kept track of and coordinated. Thus, it was possible to control the PM&C Program through the use of Gantt conventions, using schedule bars to show plan and filling them in to show performance. Progress was tracked on a periodic basis, once a week. Figure 10 shows the timing of the periodic reviews for control purpose and defines the nature of the reports used.Milestones and Schedule Subdivisions Milestones and Schedule Subdivisions are a part of the control system. Of the set of events which can be, mile- stones form a limited subset of events, in practice rarely exceeding 20 at any given level. The milestones are predetermined times (or performance states) at which the feedback loop of control described above (Figure 9) should be exercised. Other subdivisions of the project are possible, milestones simply being a subdivision by events. Periodic time subdivisions may be made, or divi- sion into phases, one of the most common. Figure 11 shows the milestones for the PM&C Program. Summary The Heublein PM&C Program met the conditions for a successful project in the sense that it was completed on time and within the budgeted funds. As is so often the case, the existence of a formal plan and continuing reference to it made it possible to deal with changes of scope. Initial reaction to the educational package was so favorable that the population of attendees was increased by Group executives and engineering managers.