The Project Planning Process – overview

A great deal has been written about planning. Some of the literature focuses on the stra­tegic aspect of planning—(e.g., Webster, Reif, and Bracker, 1989) choosing and planning projects that contribute to the organization’s goals (cf., the introduction to Section 1.5). Another body of writing is directed at the techniques of how to plan rather than what to plan (e.g., Pells, 1993; Prentis, 1989). These techniques, if we are to believe what we read, differ from industry to industry, from subject to subject. Architecture has a planning process; so does software development, as does construction, as well as pharmaceutical R&D projects, and campaigns for raising funds for charity.

As far as we can determine, the way that planning techniques vary in these different cases has more to do with nomenclature than substance. Consider, for example, the fol­lowing planning process that has been divided into eight distinct steps.

1. Develop and evaluate the concept of the project. Describe what it is you wish to develop, including its basic performance characteristics, and decide if getting such a deliverable is worthwhile. If so, continue.
2. Carefully identify and spell out the actual capabilities that the project’s deliverable must have to be successful. Design a system (product or service) that will have the requisite capabilities.
3. Create such a system (product or service), which is to say, build a prototype deliverable.
4. Test the prototype to see if it does, in fact, have the desired capabilities. If necessary, cycle back to step 3 to modify the prototype and retest it. Continue until the deliver­able meets the preset requirements.
5. Integrate the deliverable into the system for which it was designed. In other words, install the deliverable in its required setting.
6. Validate the deliverable—which answers the question, “Now that we have installed the deliverable, does it still work properly?”
7. If the deliverable has been validated, let the client test it. Can the client operate the system? If not, instruct the client.
8. If the client can operate (and accepts) the deliverable, make sure that the client understands all standard operating and maintenance requirements. Then shake the client’s hand, present the client with a written copy of maintenance and operating instructions, give the client the bill, and leave.

Reread the eight steps. Are they not an adequate description of the planning process for the design of a new pick-up truck, of a high-end hotel room, of a restaurant kitchen, of a machine tool, of a line of toys, etc.? They would need a bit of tweaking for some projects. An R&D project would need a more extensive risk analysis. If the project is a new pharmaceutical, for example, it would need toxicity and efficacy testing, and clear­ance from the FDA, but the general structure of the planning process is still adequate.

The eight steps above were originally written to describe the planning process for computer software (Aaron, Bratta, and Smith, 1993). There seem to be as many different planning sequences and steps as there are authors writing about planning. Almost all of them, regardless of the number of steps, meet the same criteria if they are meant to guide a project to a successful conclusion. The final plan must have the elements described in the previous section of this chapter.

There are many techniques for developing a project plan and Project Charter. They are fundamentally similar. All of them use a systematic analysis to identify and list the things that must be undertaken in order to achieve the project’s objectives, to test and validate the plan, and to deliver it to the user.

Source: Meredith Jack R., Mantel Jr. Samuel J., Shafer Scott M., Sutton Margaret M. (2017), Project Management in Practice, John Wiley & Sons, Inc. 3th Edition.