Does every project need a big project plan document?

Is every project supposed to create a big project plan document, even a small project with a small team?
Everyone probably has a different definition of "big." More than two pages? More than 25? The underlying concern is this: what constitutes a project plan that is meaningful and also useful and usable, as opposed to being just so much overhead that someone had to spend time creating and maintaining? The plan document for any project needs to be long enough to contain the information needed to define and communicate the major parameters of the project: the objectives, deliverables, tasks, schedule, and other elements required to achieve the desired outcomes, as defined during the planning process. Thus, the length of each section will be determined by the amount of information and depth of detail needed to convey this for the particular project. And the length of a monolithic project plan document will be the sum of those parts.

Which raises a very important point: It doesn't have to be in one document. Here are a few notes on how project plan documents may differ. The base goals are the same, though—to have a document that is meaningful and useful (it imparts information people need to know), and is usable (it's formatted in such a way that people can and will refer to it rather than ignoring it).

A large project typically would have a traditional Project Plan document. There are lots of groups in the company involved, a larger size team, lots of moving parts, a number of different stakeholders interested in what's going on. So it makes sense to have a way to communicate major project parameters to all those people.

Does that mean a 30-page monolithic document is in order? Using the "meaningful and useful" and "usable" tests, the project manager might decide that the info gets handled this way: All the summary info in the Project Plan document, and all the details of each area outside it. For example, the Project Plan document gives a short list of key major milestones, but the more detailed full milestone table the team tracks to is held separately as a single file. The Project Plan summarizes major risk items, but the full risk list or risk register is a separate working document used by the team.

The acid test is this: If you put it into the big project plan document, is anyone going to use it to help the project on a day-to-day basis? If a risk list is buried in a 30-page document, is anyone going to look at it regularly, and is the project manager even going to want to update it in that format?

Thus, a large project may often have a Project Plan document at a higher level as a communication tool, and detailed working files for all the various aspects like risks and milestones.

A small project may easily fit its plan information into one document that is less than 10 pages. Does that still sound too long for a smaller project? The key is to focus on meaningful and usable. Even a small project needs to communicate the goals, scope, dates, etc. in a way that tells the team and stakeholders what the plan is. Yes, for a two-week project a 10-page document sounds like big-time overkill. One page in a Word document or a long email might be good enough for a one-week project.

For a three-month project, if we do a thorough job of everything, there may be ten pages worth of stuff, especially if individual items like the risk list are included in this plan document. Some teams on smaller projects like to do that—they'd rather just pass around and update one 10-page document than update a bunch of little ones.

The subjects or topics to be addressed in the Project Plan can be found in our guideline Planning and Scheduling: Create Project Plan Document and the related Generic Project Plan Document provides an example of a basic plan. These templates provide guidelines and outlines for Project Plan documents and information about how to tailor the document to your project. Other resources in our Planning and Scope Resource Index provide examples of various project plans.

Just keep in mind what really matters: beyond making sure all of the project plan subjects are covered somehow, just make sure that whatever you produce is meaningful and useful for communicating about the project, and usable by those who are supposed to get that benefit!

©Copyright 2000-2018 Emprend, Inc. All Rights Reserved.
About us   Site Map   View current sponsorship opportunities (PDF)
Contact us for more information or e-mail
Terms of Service and Privacy Policy

Get Our Newsletter
Get our latest content delivered to your inbox, every other week. New case studies, articles, templates, online courses, and more. Check out our Newsletter Archive for past issues.

Follow Us!
Linked In Facebook Twitter RSS Feeds

Got a Question?
Drop us an email or call us toll free:
Learn more about ProjectConnections, our contributors, and our membership levels and product options.