The Project Management "Famous Five"

From the Easy in theory, difficult in practice Blog
My musings on project management, project portfolio management and change management. I'm a firm believer that a pragmatic approach to organizational change that addresses process & technology, but primarily, people will maximize chances for success. This blog contains articles which I've previously written and published as well as new content.

About this Blog


Recent Posts

Justify yourself!

Projects are like springs…

How effective are your agile ceremonies?

“Medium” is another way of saying “Don’t make me choose”

Improving organizational culture through retrospective recognition

Categories: Project Management

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.


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

Posted on: March 08, 2018 06:59 AM | Permalink

Comments (15)

Please login or join to subscribe to this item
Kiron, I am happy with the famous five but I would add Requirements Document to the list.

Thanks Eduin!

Najam, on a very small or straightforward project is that required? A charter might cover the needs in such cases...


Agreed, there should certainly be a minimum. Helpful is creating a matrix based on a specified criteria/threshold to identify other necessary artifacts.

Well not really, but you mentioned in article " regardless of the size, nature or complexity of a project". Keeping that in mind I added it.

I agree, Kiron ans thanks for sharing.

It's amazing how many projects don't have a charter, seriously. Thanks Kiron.

Thanks Andrew, Anish, Rami & Sante!


Fantastic list, Kiron.

I would recommend adding a project roster (appended with role definitions) as a critical artefact for projects, as well.

Especially when a project's scope of activities extend over several organisations, organisation units, teams, and phases.

Hi Kiron, thanks for this nice read. What about management reporting? Usually organization do have a specific template or format for reporting all projects. This could be another artifact where the main project data are filled in.

Thanks Karan - it comes down to the size of the team. With a small self-managing, long-lived team, a RAM or role definitions are less critical.

Thanks Urban - face-to-face communication is the most effective means of sharing knowledge. As complexity (or bureaucracy :-) ) increases, the need for formal reporting emerges.


A must have list! Thank you!

Good knowledge and valuable insight on a few standard artifacts for a project management methodology.
Thanks, Kiron!

I fully agree with this list as a minimum to communicate properly. How to convince stakeholders of it?

Please Login/Register to leave a comment.


"One morning I shot an elephant in my pajamas. How he got into my pajamas I'll never know."

- Groucho Marx



Vendor Events

See all Vendor Events