The Right and Wrong Uses of a Plan on a Page

There is a common tendency in business nowadays for project managers to produce a “plan on a page”. This document is often created as one PowerPoint slide. It provides, at a glance, an overview of the key activities of the project, the overall timescale, and sometimes a very high level view of the dependency between key activities. In this article I would like to share my view on how this kind of plan should be used. I hope you will all agree with me.

Across my writings and comments on project management, I very frequently stress the need for good communications, developing relationships with stakeholders, and tailoring communications to your audience. One of the challenges for project managers is to communicate a complex plan. Showing a detailed Microsoft Project plan with several hundred lines spreading over months of effort, to key stakeholders, is generally is not helpful.

One good way to explain the project to senior stakeholders and sponsors is to produce a plan on a page which gives them a view of the key chunks of work on the project, and usually has a timeline which is only shows months or even quarters of time. The plan on a page can be tailored to different audiences to stress the elements of the project they are most interested in.

Unfortunately, I increasingly see project managers using the plan on a page as the only project plan. There is a real difference between the plan on a page as a communication device, and the plan on a page being used as the project plan.

As a communication device the plan on a page can be excellent. But that is about all. You cannot estimate resources, assess the impact of dependencies or work out critical paths with a plan on a page. More fundamentally for me, the biggest problem with the plan on a page is that it indicates that the project manager really has not thought through the project.

Developing a project plan is essential in estimating resources, timelines, risks and so on. But it is not just the output from planning that is important, it is the process itself. Developing a detailed project plan forces the project manager to think about and understand the project. If you have not developed your own detailed plan, I do not think you really understand your project.

Of course, there are sometimes small projects of limited complexity that can fit a fully detailed plan on a page. But using a plan on a page as the only project plan, for an initiative of any complexity, is either laziness or incompetence.

Do you agree? Interested in your comments on this one!

Related content:

Basic Principles in Project Scheduling
Examples of Poor Project Management - Planning Without Creating a Work Breakdown Structure
Stripping Project Management to Its Core: Time Management Planning Simplified


Only so much can fit on a page, no argument there. However, I believe you cannot produce plan on a page of any consequence without having spent considerable time on the details. My thesis adviser badgered me about brevity and illustrated his point by recounting a story (claimed to be true, I forget the details) about a person ending a letter to a friend this way: "Sorry for the many pages, I did not have time to make it shorter."

The moral of that story is that you cannot make something shorter if you don't start with the longer and that it takes time to clarify your thinking.

Rushing it or not being smart about it can still produce a weak plan on a page.

On a side note, I am a fan of mini charters for the simple reason that if a PM cannot fill in a one page mini-charter in a flash, he or she does not know what s/he is on the hook for.

One-pagers like the above can also assist communication by presenting a message as simply as possible.

Hi Preben

Thanks for the comment, which I agree with completely.

I don't deny that when you know something well you can explain it in simple and short terms. The plan on the page is a good example of this - if you understand your project and your understand what is relevant to your stakeholders you can concentrate the critical information into one page to communicate whatever is required to them. However, it is, as you say, only because you have done the real thinking that you are able to provide a good summarisation. The summarisation is a presentation of some of the information - it is not all the information.

A project plan is not simply a communication device - it is a management tool as well, and as such it needs sufficient detail to be able to do the management.

As for the quote, I could be wrong, but I've heard similar words attributed to Winston Churchill.


Actually, it was Blaise Pascal, a famous philosopher and mathematician. Otherwise, I very much liked this blog entry. I would extend the discussion to models in general. As an EA that has done a fair amount PM, I find there is much confusion as to the role and utility of models whether they be for a schedule (plan on apge) or a system (UML).

Communicating salient points in a simple and succinct way is useful, but one also needs to be explicite.

Anyhow, we agree and in the interst of brevity I shall leave it at that ;-)

Thanks Bazzim for sharing your thoughts, and correcting me on the quote.

It's a quote I often use and have never been able to place correctly. Now, I not only know the right source, but can get the actual wording right. Cheers!gre

I like the blog and totally agree Richard that the ‘plan on page’ is a very valuable communication tool, however only if it is aligned to a project plan, and not as a replacement for a project plan.

To use an analogy the project plan is the engine, the 1 page plan is the dashboard. The dashboard is a very useful summary of what’s going on in the engine that can be used to effectively communicate to an audience that simply doesn’t care about the workings and details of the engine. However without the underlying engine the dashboard is cosmetic & thus worthless.

I have come across the 1 page plan as the only plan; the moment something changes on the project e.g. a task on the critical path is delayed, it's immediately inaccurate and the timelines are all out of date, and without a project plan there is no means to update it. For me the alarm bells start to ring as it shows that little thought has gone into planning the project and that the timelines are very questionable.

Hi Matthew

Thanks for the comments - and I like your analogy. You are right that the plan on the page is a dashboard whilst the project plan is the engine.

I'd like to build on your points. Because, unlike most dashboards, as you know the plan on a page does not update itself automatically! It's normally a PowerPoint presentation and the only way to create it is manually. I have a feeling the only way to create plans on a page will always be manually - as it is not just a rolling up of tasks, it is created with a specific audience in mind.