Discussion on:

Consolidate all project management deliverables in the project plan

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?

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.

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.

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

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.

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.

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.

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.