Project Management

Consolidate all project management deliverables in the project plan

A project plan is the name given to all of the project management documents used during the project. Find out the specifics of what the project plan entails.
Editor's note: This article was originally published January 16, 2007.

Many people use the term "project plan" to mean the project schedule (or workplan). However, the project plan is the name given to all of the project management documents used during the project. This term made more sense in years past when you could envision a physical binder that contained hard copies of the project management deliverables. The term has less meaning today when all of your documents are stored online, and many of them may never be actually printed. The project plan could be the name of the online folder that houses all of these documents.

The project plan specifically includes the following:

  • Project Charter (Project Scope Statement): This document describes the project objectives, scope, estimated costs, estimated duration, deliverables, risks, assumptions, project organization, etc.
  • Project Management Procedures: This document contains the specific procedures for managing your schedule, issues, scope changes, risks, quality, etc. You should have organization-wide guidelines for these procedures that you customize as needed.
  • Roles and responsibilities: Each stakeholder should understand their role and responsibilities on the project. This includes the project manager, sponsor, steering committee, project team members, control board, etc. These should be created at the organization level and customized as needed for your specific project.
  • Schedule and Work Breakdown Structure (WBS): Your schedule is definitely a project management deliverable. If you create a formal WBS to help create your schedule, you should save it in the project plan as well.
  • Staffing Management Plan: This describes the staffing resources you need for your project, the skills you need, where the resources are coming from, etc.
  • Communications Plan: This is a list of all stakeholders, their communication needs, how you will deliver the information, how you will manage their expectations, etc. You may also have a Stakeholder Analysis Plan, which is similar but created at a little broader level than a Communications Plan.
  • Risk Management Plan: This is where you describe the project risks, how you rank the risks, how you will respond to all major risks, contingency plans, risk management tools, risk management specialists on the project, etc.
  • Project Balanced Scorecard: This document describes the measures that you will use to validate that your project was successful. It includes the project success criteria, metrics that indicate success, targets for each metric, how you will collect the metrics, how you will report the metrics, etc.
  • Project approvals: These approvals can be saved with each document, or you can save all document approvals in one central location.

There may be other project management documents that are also included in the project plan, but these are the major ones that might be applicable to your project. Instead of keeping these documents scattered all over the place, it is a good idea to store them in the same area. If you do, you can now give this entire group of documents a name: the project plan.

-------------------------------------------------------------------------------------------------------------------

Get weekly PM tips in your inbox TechRepublic's IT Project Management newsletter, delivered on Wednesday, offers tips to help keep project managers and their teams on track. Automatically sign up today!
18 comments
LightVelocity
LightVelocity

Pretty Good list. I might add an item on Configuration Management to projects that involve multiple or incremental changes to artifacts whose versions would need to be retrieved for later use.

anilchiplunkar
anilchiplunkar

Tom this is a short and sweet list, covering all the major components. I believe there are few documents which remain more or less static and others could be dynanic e.g. Charter could be a static document created at the begining of the project where as the balanced score card could be a dynamic document. It is a good idea to 'mark' the documents in that way, and it will help to ensure the 'modifications are going to proper documents', the static are not modified by mistake. Also it is most important to maintain the 'versioning' of the document so that the project team always referes to the 'latest version'. Collating and archiving the complete set with correct versioning at the 'project closure' will also become slightly easier task by having all documents at one place / single repository.

barryfaith
barryfaith

Tom's list is excellent, however I disgree with the naming. This list is best called the project MANAGEMENT Plan (caps for emphasis - I'm not shouting - - -)- in other words it contains all the stuff (plans etc) that are needed to MANAGE the project. It is the equivalent of the Project initiation Document (PID) in the PRINCE2 Method.

ray.derkacz
ray.derkacz

This is a good list. Personally, I would specifically include here: Resource Plan - planned/actual budget expenditure over time for all resouces (staff, hardware, software, services etc). Quality Plan - how the deliverables will be assessed for completeness and approved.

mrios
mrios

Me parece excelente el planteamiento. Solo que yo usar?? el Balance Score Card como el organizador de los entregables. Me explico: la herramienta plantea cuatro areas de trabajo y cada una de ellas tiene sus propios entregables, desde la cual se puede documentar si se catalogan los entregables de acuerdo con los propositos de informacion/ conocimiento que aportan. Saludos, Mayra Rios Coordinadora Unidad de Gestion Integral de Informacion Costa Rica

davidshotton
davidshotton

Interesting article, however I think the list of documents is less important than the objectives here, it's the sentiment that???s implied. How many 'planning experts' constantly face the dilemma of their paymasters (Project Managers) who fail to recognise the relevance of documents that are not their responsibility to deliver. These types prefer to ignore inter-project dependencies on major programme and prefer to stick with a work break down structure only to identify tasks and activities for the purpose of time recording rather than the production of artifacts, as defined by RUP (Rational) or Harmony (Telelogic) to reduce Risk and ensure Project Assurance. Documentation is a Programme Management initiative rather than a Workstream Project Management issue and requires effective 'policing' to ensure Project Assurance, otherwise it gets retrospectively produced to demonstrate compliance but adds no real-time value to the project in terms of planning.

poparosa
poparosa

This is a great list, Tom. However, one of the challenges I have is when some of these documents are organic and change over time. In particular, in an agile (or scrum) environment, the schedule and deliverables are a moving target. The issue then gets down to when to post the changes, and how to update the stakeholders.

maryclaire.salander
maryclaire.salander

Thanks, Tom, for drawing the distinction between the project PLAN and the project SCHEDULE. So many people use those terms interchangeably. I would be curious to hear about the real-life usage of the WBS. I read about it in every book and yet, most shops I've worked in have never adopted its usage. Comments or feedback?

pmaina2000
pmaina2000

This article makes me MAD! Ok - it's good article and I honestly hope many vendors/contractors/consultants will read it. But it reminds me of just how "project managers" from reputed consulting/contracting companies think that the words "project plan" mean "a regurgitated MS project gannt chart"! To make it worse, you get an MPP with illogical assumptions (e.g. on dependencies). AAAAAAAARRRRRRGGGGGGGGGG!!!!

lee_s_young
lee_s_young

I'd recommend adding a couple of extra deliverables into that Project Plan: 1. Scope Statement. Put simply, if you can't measure it, you can't manage it. So, it's always best to state for the record what's going to be done; and what's not going to be in scope. If scope has to change, it should be a simple matter to agree the changes and release a new version of the Scope Statement, but at least you all have something to refer to, rather than sitting around having one of those "I thought you had agreed that we were going to deliver...?" conversations. 2. Quality Plan. Every Project needs one, as every Business must have a Quality Plan, enough said.

carmela.martinez
carmela.martinez

Hola Mayra. Al fin una respuesta en Espa?ol. De acuerdo con tu planteamiento. Coincido con lo que alguien coment? sobre que el autor llama a los documentos subsidiarios del Plan de Proyecto como entregables. Mi concepto de entregables es otro. Bueno, este es el punto de vista del autor, para mi no existe ninguna confusi?n en este tema. Saludos, Carmela Mart?nez Panam?

Lef2000
Lef2000

In a situation frequently the varying environment of the project the best way is splitting Project Management Plan into two parts - a constant which varies seldom and a variable. For example the Constant part can contain scope, management procedures. The variable contains the schedule (baseline), roles and the responsibility, Risks list, Communication plan, other usefull plans .

khaled
khaled

I think you meant PMP (Project Management Professional) is not it? I would also like to add that the above points are not all compulsory. It depends on the size and length of the project also.

visionman
visionman

Scome of the documents listed are actually deliverables. In the case of a Software project one should consider the Project methodology document carefully. It requires input of the above stated documents plus a host more.Therefore my opinion is let the plan be referred to as the plan and the project documents as the project documents.

jon
jon

How about combining all of the artifacts produced during the project lifecycle into one management system? A Plan is a measuring stick, but we all know that plans often time are more like guidelines. The real trick is actually managing .... are more plans the answer? Like you said if you can't measure it, you can't manage it. I was very frustrated about trying to manage the plans I produced for my projects because like many shops I was only getting half of the picture with my current mgmt tools, and because of common batch spreadsheet reporting practices its often too late to do anything with the picture I did get. I recently switched to using an SDM system called Lighthouse. Its one of those new freemium software services, www.artifactsoftware.com/free. It combines all of my project artifacts into one system and provides real time project health stats through a dashboard on quality, schedule variance, cost variance, requirements traceability, and more. Very handy for managing my teams in the Ukraine and Hyderabad. It even retains historical stats so I can create better plans moving forward.

JamesRL
JamesRL

The challenge often is that some deliverables can be combined. The OP does refer to a scope statement - but whether its useful or not is another question. I always like to clarify scope by stating what is in scope, and trying to identify what is NOT in scope that someone might assume is in scope. Quality plan. The balanced scorecard may or may not contain quality metrics. The value of these is often in the execution not the metrics themselves. Choosing the wrong metrics to measure is not helpful and can be counterproductive. A quality plan without metrics is hot air. James

jon
jon

MPP's are often the bane of every project manager. They are more like guidelines really. No one likes the things. Execs always want to know, how are we doing according to the plan? Developers, hate plans because they are often shackles that constrain their brilliant development minds? Project managers hate them because they are just another bit of busy data collection work we have to do. AND THEY ARE NEVER KEPT UP TO DATE IN REAL TIME! AHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHHH!

harrycapper
harrycapper

The project plan, irrespective of what software is involved, is the glue that binds the complete project. If it not regarded as so, then there are some serious cultural issues with the projects you have been involved with. The plan should drive the direction of the project and team members need to be accountable to it...