PC Possibilities, Inc.

Tom Satyshur Jr . . . providing PC hardware, software and services since 1987 to the Cleveland Ohio area

The Project Plan

Most of the principles described here are not new. Projects have been organized and executed long before computers arrived. And there are dozens and dozens of books, tapes, classes, and lectures on Project Management. What I have added are specific comments describing what has made our application of these principles successful.

The very first step to the development of a good Project Plan is get a good Project Manager (PM). This person obviously needs to have good organizational and communication skills, but must also be able to have a "vision" of what the end result will be and the discipline to control the project so that the end result is achieved.

"Organizational Skills" does not mean the PM can write Excel spreadsheets or knows the workings of a Project Management Package, although these are highly desirable. As someone once said, "if you cannot describe it manually then you cannot automate it". The PM needs to think in a hierarchical manner and articulate that in writing.

"Communication Skills" include both written and verbal skills. Memos and Minutes require concise yet content rich text. Daily Discussions and Management Presentations require the ability to express ideas and facts simply yet with just the right amount of detail to give the listener the answers they need to do their job. This is best done when the PM has a genuine concern for the welfare of the customer, the humility to "do it their way", and the fortitude and skill to constructively describe and work through disagreements with the customer. This is best accomplished by starting with an attitude that we are out to make the customer successful in their Project.

"Vision" is a tougher quality, especially in software projects. The Vision starts with a written description of the Project Objective. This is a simple one or two sentence statement that describes what the project wants to accomplish, e.g., the "deliverable" and its business function. For example, "to develop a Sales Contact database that facilitates the user's ability to view contact information in a variety of ways specific to the product line of the company". This becomes the goal to which the progress during the project is always measured against, e.g., "are we still developing what we said we would develop?"

"Vision" continues with an idea of how the project is to be conducted.  This becomes the basis of the Project Tasks. It is written and becomes what we call the "Project Conduct". It describes the high level task and starts with the event that begins the project. For example, "this project will begin with the assignment of a Project Manager who will meet with the Customer to review the project Objectives". The Conduct concludes with the description of an event that marks the completion of the project. For example, "this project will be complete when all of the test cases have been successfully run". It is highly important that these two events be part of the Project Plan in order that the end points of the project be clearly defined.

It is surprising how many projects do not have a clearly defined start and, especially, a defined finish event.

Well, what about "scope changes". Everyone who has run a project knows that the biggest danger to the successful completion of a project is the new work that is identified during the execution of the project, often call "Scope Creep". My experience is that you can count on scope creep; it will happen in every software project because of the "discovery process" . . . new requirements are discovered during the development. Scope Creep is handled by the PM through the use of two tools: Work Authorizations and the "Control Group". These are described later.

Another part of the "Vision" is that there must be at least a high level idea of the components needed in the deliverable. For example, the Menus, Input, Processing, and Output Requirements, Usage Environment, etc. Note that these are not detailed descriptions but general ideas. There may be some "rough sketches" or there may be a step to develop a formal Requirements Definition. Small projects usually start with the rough sketches; larger projects need a Requirement Definition.

Yet another part of the Vision is to have some idea of where the risks are in the project, and be prepared to mitigate these risks. The Work Authorizations and Control Group, to be described later, are the tools to be used to identify when a risk becomes a reality.

Finally, the PM must have general ideas of who and how long. This is where the experience of the PM becomes essential. Not that the PM must have experience in every aspect of the development process. That is why the PM enlists the advice, suggestions, and recommendations of the appropriate people with the appropriate knowledge and experience. The "trick" is for the PM to evaluate the advice, suggestions and recommendations against the Project Objective in order to develop the project plan.

So what about PERT charts, Dependency Diagrams, etc. These are important but only as pieces of "The Plan". The "trick" is to develop multiple levels of about a dozen Tasks with their Dependencies. More than that number and the PM begins to loose the Vision of how the project is conducted. I have seen some companies use the "40 Hour Rule" to define Tasks. The Y2K Project Plan at a major company papered the wall 8 feet high down a 30 foot corridor. The PM and his staff became slaves to feeding the Project Management Software and had very little time for actually controlling the project.

My experience has been that top management simply want to know "how much is done" and "when will it be done". Corollaries are "are we on time and budget?" A rollup of detail tasks to a high level task list enables the PM to control at a detailed level and report at a high level.

Finally, it is important the Project Plan be a written document that has been reviewed (and modified, as necessary) and accepted by all parties of the project . . . especially the customer.  This plan can be anything from a few pages for a small project to a manual for a large project . . . the bigger the project the more preparation is needed to mitigate the risks and reduce the number of unknowns as far as possible. For my work the Project Plan typically contains the following sections: a short description of the Background of the project, a statement of the Project Objective, a description of the Project Conduct, a list of Assumptions being made, a list of Client/Customer Responsibilities, a list of Exclusions, the Project Schedule, and the Project Budget.

Home    Back to Project Management

Send mail to webmaster@pcpossibilities.com with questions or comments about this web site. Microsoft Access and VBA © Microsoft Corporation. All contents of this web site © 2003 PC Possibilities, Inc.  Last modified: November 21, 2003.