Document Your Projects

Documentation from the Initiation to Project Close is one key to successfully managing the tasks, activities, and acceptance of outcomes. This is true of any project, large or small.  Will documentation prevent disaster? Realistically, no it won’t.  Nevertheless, a well-documented project has a significantly greater chance of success than one that ignores or skips procedural documentation during the project life-cycle.

Every standardized Project Management methodology focuses on documenting key functional components, decision points, critical inputs and outputs and ultimately acceptance of the final product.  Both Project Management Institute (PMI)[i] and Prince2 have common approaches to documenting specific entry and exit points as a means of signaling acceptance of all work products and deliverables contained within a phase or even the project.  Whether a project is to implement new software, undertake process improvement, or deploy new desktops to an organization; the requirement to document what, when, how, and even why is a common theme within project management methodologies and one, when done right, has proven to reduce risk.

The real key to successful projects and thus successful project managers is knowing how to choose the right level of documentation for any given project. All projects are not created equal and thus do not require the same number of trees be killed in the name of documentation.  Oh yes, I know I am often not in line with my fellow project managers in my approach to this issue.  Nevertheless, it is vital that methodologies and supporting PMO’s be agile and flexible, allowing project managers to pick from range of supporting documentation based on project scope, size and even duration.  Documentation purely for its own sake will not prevent disaster and may in fact create its own set of issues for the project manager and the project customer.  Methodologies and supporting PMO’s must enable projects and project managers to meet the specific requirements of organizations and projects in both size and complexity without generating administrative traffic jams due to documentation rules that do not serve any purpose except to check a box.

The crux of the documentation issue, what are the absolute must haves of any project that will mitigate the risk of a less than desirable outcome?  How does a project manager know which of the hundreds of possible documents available should be “absolute” within a project?  These are really at the heart of the issue of how to prevent disaster.  For any person who has worked in a consulting world as a project manager in IT, Organizational Change, or Business Transformation there are many others beyond the PMI standard.  In other industries there are standards based upon either government or other external forces that may or may not be negotiable.  The following though are what should be consider the bare minimum for a standard project of any complexity.

  1. Project Charter – Simple statement of why the project is being undertaken, who the sponsors are, a formal authorization to proceed with the project.  This is the WHY.
  2. Project Scope Statement – Formal confirmation of scope written in clear terms provides details of all components of scope including business units, IT, geography, and people.  Another one of those documents that is frequently overlooked.   This can be combined with the Charter although it is better as a separate document.  If there will be a RFP process this is the document that is key to that process.  This is the WHAT.
  3. Project Management Plan (PMP) – This is the key to project management excellence and the one that is most often overlooked by project managers and even PMO’s.  So many of the individual plans within the PMP should be considered the backbone of projects that they are often also ignored as project managers build the “how to” of project execution, these plans in truth can stave off disaster in many cases.  Many of these plans should be simple templates that are reused for each project undertaken by an organization with minimal adjustment or localization for individual project requirements.  The PMP is the HOW.

3.1      Scope Management Plan
3.2      Schedule Management Plan
3.3      Cost Management Plan
3.4      Quality Management Plan, this plan should always include: Document Development, Naming Conventions, Technology Conventions if applicable to the project.
3.5      Resource / Staffing Management Plan
3.6      Communications Management Plan
3.7      Risk Management Plan
3.8      Procurement Management Plan
3.9      Issues Management Plan

Assuming that the project has been kicked off properly and there is a Charter, a Scope Statement, and a PMP in place, the goal of the project manager is to insure all project members clearly understand what is expected and how the project will be executed. Now of course comes the hard part, in fact executing according to plan, as we all know even the most well document and best planned projects do not always go off as expected.

What are the three decisive documents that the project manager produces during project execution that will, if not entirely prevent disaster, at least identify problems before they produce disastrous results, and thus provide opportunity to address them appropriately.

  1. Risk Management & Mitigation Plan & Log – The management of project risks is an on-going activity that begins at project initiation and continues throughout the project life cycle.  The Risk Management Plan & Log includes identification of Risks, as well as, mitigation plans and tracking mechanisms for project reporting.
  2. Project Schedule – The detailed schedule, including tasks, milestones, and resources assignments is truly the core of the Status management for projects.  This is the single most critical document, allowing the project manager to extract budget, resource, and schedule tracking information for evaluating key performance indicators (KPI) of the project.
  3. Status Report – This single document consolidates the outcomes of activities of the past reporting period, as well as, performance of project against KPI’s.  Another primary purpose of the Status Report is to escalate Issues, inform management of Risk Management activities underway, and finally to report financial performance.  The size and complexity of the project will generally dictate the frequency of the formal Status Report.

There are many other documents produced during the life of a project as validation of actions taken, decisions points, and even product acceptance.  Some of these are formal project artifacts while others would be consider informal.  Each project should maintain its own project file folder for the purposes of audit traceability.  Some of the documents that may be included in this grouping are not considered mandatory and will be decided at the beginning of the project, they are as follows.

  1. Meeting minutes – Formal Mandatory
  2. Product / Phase Approval also sometimes called a Phase Exit – Formal and Mandatory
  3. Change Control Approval / Rejection – Formal Mandatory
  4. E-Mail discussions – Informal and Discretionary

There is no documentation that will guarantee that the outcome of a project will be as expected or will not end in disaster.  However, by implementing appropriate documentation combined with a well-defined set of KPI’s and a proactive Risk Management program disaster is a less likely outcome.  Project Management will always be in part an art form and in part a science those that can combine both sides will have greater success.

Linda


[i] A Guide to Project Management Body of Knowledge (PMBOK Guide) Third Edition 2004 Project Management Institute, Four Campus Boulevard, Newtown Square, PA 19073-3299 USA

________________________________________________________________

(c) Linda Valentine-Dean 2012
Re-Blogging of this or any other post on Passion for Excellence is expressly forbidden. Copyright and Privacy Policy available in The Office.

About lvalentinedean

Twenty years in the trenches hasn't stopped me from being passionate about the profession of project management.
This entry was posted in Methodologies, Project Management Office and tagged , , , , , , , , , , , . Bookmark the permalink.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s