Project Activity and Risk Planning
This 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 Failure
As 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 uncertainties
Questions: 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.