The Project Management "Famous Five"

 

Assuming your organization or department has a published project management methodology, chances are that it specifies that at least a few standard artifacts are created and maintained on every project. These artifacts might be standalone documents, or they might exist as a data set within a project management information system.

One of the most valuable pieces of advice in the PMBOK Guide is “good practice” does not mean that the knowledge described should always be applied uniformly to all projects; the organization and/or project management team is responsible for determining what is appropriate for any given project. As such, competent project managers arm themselves with a toolkit of practices to draw upon, and apply them based on the specific needs of a given project, the maturity of the team and organization, and regulatory or compliance requirements.

For example, on projects possessing a significant degree of requirements uncertainty, using iterative and interactive requirements techniques and artifacts which might help to elicit true needs would be beneficial whereas for those projects in which scope and requirements are very clear, traditional methods of requirements gathering would suffice.

Is there such a thing as a minimal list of project artifacts which should be created and maintained regardless of the size, nature or complexity of a project?

The benefits in defining such a list is that it would help to eliminate or at least reduce some of the contention which occurs when a project manager has to justify the need for specific practices with a sponsor or other key stakeholder who views such practices as being unnecessary overhead.

Here are five “must have” project management tools along with rationale for selecting these artifacts and the risks in not using them.

Charter

Whether this is a single page document or something closer to a high-level plan, the charter is the one tool which a project manager can wield to demonstrate that their project has been formally authorized and, when it is well written, it will help to align key stakeholders and the team towards the project’s expected outcomes.

Without an approved charter, it may be challenging for the project manager to engage the resources required to plan and deliver the scope of the project, and there is a greater likelihood of stakeholder misalignment.

Approved Plan

Agile fanatics might cringe at the necessity for this, but it goes back to the basic criteria which define a project - it is a temporary endeavor consuming resources to deliver unique outputs which will generate business value. In the absence of documentation which clearly states what will be delivered, by when, how, with what resources and for how much, it is likely that the project will either be cancelled prematurely when funding or time runs out, or branded a failure upon completion if customer expectations have not been set and met.

Two critical components of this approved plan are objective project completion and project success criteria – without those, the project may turn into a shuffling zombie from the set of the Walking Dead.

Current Forecast

It does no good to have an approved plan if you have no idea as to how you are tracking to it. The forecast will cover the same knowledge areas as defined within the approved plan and should be used as the basis for communicating project status. Without this, stakeholders are left to guess how a project is doing, and it will be difficult to detect negative variance trends in a timely fashion.

RAID log

This artifact provides a consistent, centralized method for managing the uncertainty native to project work. Without it, risks may go unmanaged, issues might not be resolved in a timely manner, actions may linger resulting in schedule and cost impacts and key decisions might be delayed or worse, made without appropriate governance oversight and subsequently reversed.

The accuracy, currency and completeness of this artifact provides good insights into the overall discipline and competency of a project manager as it is their ultimate shield. If a project manager is not concerned about self-preservation, how much would you trust them to manage your project?

Closeout Report

At a minimum, this formalizes the acceptance of a project’s outputs, identify exceptions and the owners for those, and provides the necessary authority to shut down the project and to release resources. While we have all worked on projects where all concerned want to run away as soon as the work has been completed, the absence of this artifact might result in post-project headaches if expectation gaps have not been addressed.

There is an elegant symmetry to this list – the charter and closeout report bookend the project, the approved plan and current forecast are ideally identical twins, and the RAID log acts as the main monitor and control tool.

Have I missed any artifacts which you feel are mandatory? Do you feel any of these Famous Five are unnecessary?

(Note: this article was originally written and published by me in February 2014 on Projecttimes.com)