Planning

The Purpose of a Project Plan

The purpose of a project plan is to maintain control of a project.

As a complicated process, a project always threatens to exceed the limit of your control. Some people are better than others at controlling complex problems, but all of us reach our limits at some stage. To maintain control you need help in the form of tools, your best tool is your plan.

The project plan controls the project by:

• Breaking a complex process down into a number of simpler components
• Providing visibility for obscure or ambiguous tasks in the project
• Providing a single point of reference for everyone
• Enforcing scrutiny of the sequence and nature of events
• Providing a baseline against which the actual execution of the project can be compared
• Anticipating likely events and providing pre-planned means of avoiding them
  

A project plan must be as accurate, complete and as specific as possible. How accurate, complete and specific of course depends upon how much time and resource you have available.

The Elements of a Project Plan

Every project planning methodology has its own specific taxonomy and names for its parts. But in a very broad sense the minimum elements a project plan must specify are:

What is to be done – what is desired of the project and what it must deliver to succeed. This is a scope document at a high level and requirements specs. at lower levels

When it needs to be done by – the deadlines by which the objectives must be met

Who is to do it – The people, sometimes unkindly labelled "resources", or the team who are to deliver those objectives. This also usually implies costs since in most projects the application of costs implies the use of skilled labour

How it is to be achieved – This is normally in documents such as a technical specification

Note that you do not need to complete all of these prior to starting your project. Typically one draft of the proposal, schedule and budget are completed before your project commences. Each of the other documents will be completed at some point through the lifecycle. Nor should any of these documents be regarded as static or inert manuscripts. Each is a living breathing expression of the project at a particular point in time and they should evolve as your project evolves.

Finally, none of these documents has a obligatory size, format or length. Although I suggest various forms and styles they are examples rather than as strict templates. Remember, these are tools not doctrine! If it is easier and more efficient to scribble your project schedule on the back of a cocktail napkin then do it! It is the objective that counts, not the form. The only right form is the one that works for you.

Source: Nick Jenkins, https://learn.saylor.org/pluginfile.php/5749275/mod_page/content/2/BUS402-1.5-projectPrimer-CCBYNCSA.pdf
This work is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 2.5 License.