First a disclaimer: I don’t claim to be the world’s expert on project management, and I urge anyone who is involved in or interested in project management to seek good sources of information and study, as this is a profession requiring a lot of skill and knowledge to do well. That said, I believe my decades of experience (planning projects up to 4 years in length and over $1 billion in cost) gives me some basis to write this. You may notice that I tend to focus more on the timing aspects of large scale plans. I am not ignoring the financial side of the discipline, but not stressing it either, because I have usually had a parallel financial planning effort, run by accountants and financial experts, to lean on. You may also notice that I am trying to address the realities, the impact of human nature, on the work. That said, be aware that good planning requires a focus on all three major components of business processes and projects: time, cost, and quality. I have summarized with a list of suggestions at the end, and hope you find this entry helpful.
A good plan both models the project and communicates it to the stakeholders. In business there is always a need to plan, and it takes project management skills and savvy to develop effective plans with manageable amounts of detail. The basic purpose of the plan, besides modeling the process in time and guiding execution, is to communicate the plan to the stakeholders, a group that goes beyond those who must execute it. The plan also gives a traceability to the project, documenting its history as it helps the project team react to problems and delays that will crop up. If your plan becomes too detailed you may not be able to keep up with the status of the many events. As you read on, I will include descriptions (in italics) of a plan I recently received that violates a lot of the guidelines I describe here, and I will describe some of the problems it imposes on the planner, the readers, and the organization as a result.
A good software tool can provide some powerful advantages, but present its own challenges. If you have the plan logically structured in a good software tool it will recalculate the schedule when you add actual dates or change planned dates, and let you easily assess risks to the project. Unfortunately, some people will expect to see the dates of their events unchanged, and may not understand when someone else’s earlier event, that was delayed, creates a delay in their schedule. To offset this you will need to understand the details behind the change, which will require time and effort, and you should communicate the details to the stakeholders in advance of releasing the updated plan. This will potentially get you better input, avoid unpleasant surprises, and ensure the plan remains feasible. Also, senior management may not be able to follow developments closely, and may not expect dates to change without their express approval. It could be embarrassing if you show your plan before you have a consensus among the stakeholders. As a result, you may need a second copy of the plan to use to gain consensus, try out “what-if” scenarios, and develop the final changes before you release the official plan.
It is not uncommon to have two or more copies of a plan. Whether you use a software tool or manage your plan in a graphics tool, a spreadsheet program, on a whiteboard (I have done this successfully), or on paper, you may need to maintain more than one copy. You may well wind up with a working plan copy you keep to yourself and use for analysis and prediction of schedule changes, and a presentation copy you make visible to the project team and only change when you have received the appropriate approvals from the stakeholders. As in accounting, one “set of books” may not be sufficient. (If you not familiar with business accounting, it is common to keep a standard set of financial books for reporting to investors and owners as required by law, a second set of books for tracking cost and managing business activities, a third set of books to track the business from a tax perspective, and some businesses even keep a fourth set of financial books structured for potential investors.)
You have to have plans, but to be effective they must achieve a happy medium as far as detail and readability. Certainly, “failing to plan is planning to fail”, as they say, but finding a happy medium – a plan that gives easy-to-understand and comprehensive direction to the organization, and is easy to communicate and maintain – is essential. This may not be easy to achieve, however. A plan should have enough content to paint a clear picture of what must be done and when, but no more events and dates in it than are needed to effectively direct its execution. It may be necessary to run the plan in two parts – a model of the project in time and possibly money, and a chart you use to communicate to the project team. The only limit to complexity in the model is how much you can manage, but the complexity of the chart you present should be minimized to only what is needed to keep people on time. You may find, however, that you, a busy project manager, will have so many meetings to attend and other work involved in the job that you are lucky to be able to develop and maintain a single plan document, and must use it both to model AND communicate the plan. This presents the problem of how to have enough detail in the plan to manage the project without presenting so much that nobody can read or use it. Skilled use of software may keep this from being too severe a problem. From here on I will assume this case – that you only have time to manage a single plan document.
Putting too much detail in a plan may make limit its usefulness. I have seen some great plans in my time, and I’ve seen some doozies, and I’m looking at a real doozie right now. This overstuffed plan has so much detail in it (over four hundred events, each with detailed labels) that, when printed out on 11 x 17 inch paper, it looks like a blur, a smear of toner across the paper. I would need a plotter to create hard copy output of this plan that could actually be read. Even on the screen the plan must be magnified so much that you can’t see the timescale at the top or bottom to tell you when the events are supposed to occur, though this could be remedied by adding the year digits to the dates shown – more clutter.
A too-detailed plan can become nearly impossible to maintain. For a number of reasons you will need to limit plan complexity, often in the face of managers who will want their events included in ridiculous detail. When you have hundreds of events in a plan, you have a lot (and possibly too much) to track. You will need to quickly and efficiently find the right events and change the dates to reflect delays, changes in the program scope and timing, or events that actually occurred. That means the plan will require a lot of careful attention, and if it is huge you may not be able keep up with it all by yourself.
Errors happen. Since humans tend to have roughly a 1% error rate, you can expect to have errors in any case, but the opportunities for error increase at an increasing rate as the plan becomes more complex. Worse yet, you can expect errors to be caught in high level reviews, which may be the only time anyone will look at a really complex plan. (This will, however, give other attendees relief from their own issues, as they can direct everyone’s attention to your mistakes and keep management’s attention off of their issues – hopefully they will show you some gratitude.) The best way to reduce the error rate is by periodically reviewing the plan with stakeholders.
One of the most common pitfalls in planning is when management demands the addition of too much detail. All too often I see higher-level managers with too little understanding of the practicalities of project management driving more and more detail into a plan in an effort to establish better control over the project. Unfortunately, this often results in a plan with more detail than can possibly be absorbed, managed, or kept up to date, and the difficulty of reading the plan can drive people away from using it. An important point to make as you try to keep your plan manageable is that, if people are so put off by the amount of detail that they stop using the plan, the manager’s control is effectively reduced rather than enhanced. When requests come in to add more detail, the planner must screen the request, asking, for example, if the requested detail is useful to most of the plan’s stakeholders, or only to a single functional area. The planner must argue against inclusion in the latter case, or wind up with a badly overstuffed plan. Tasks of interest only to a single function should be included in a subordinate plan, not in the master plan.
Develop supporting plans for specific activities to control the details, with shared integration points to tie them to the master plan. A single plan can rarely contain all the details behind the process, especially in large and complex organizations, without becoming an “eye chart” that nobody can read. Also, the more detailed the plan the greater the risk that dates will have changed again before the current round of updates can be finished. I have seen plans so detailed they could never practically be kept up-to-date. Supporting, or subordinate, plans enable you to keep track of the details (better yet, find someone else to do that) while you maintain the master plan in a highly readable, maintainable, and effective form. The integration points that tie a subordinate plan to the master should be limited to inputs, outputs, key events, and status reports to management, thus keeping master plan content to a highly-effective minimum. Some software tools allow dynamic linking between plan files, which allows the sharing of dependencies between plans. Be aware, however, that this introduces additional complexity that may not be manageable.
Include reference information to explain symbols and acronyms. Symbols can make a plan document more interesting and easier to read, and acronyms can be good for saving space on the document, but these aren’t helpful if the reader doesn’t know what they mean. Tables of reference information should be separate from the “meat” of the plan to avoid confusing the reader’s eye, but logically placed to make it easy for the reader to find them when needed.
In my overstuffed plan, each milestone diamond has up to ten dates strung out below it, with an acronym next to each one to indicate a specific review meeting involved in achieving that milestone. Unfortunately, only those who have the “secret decoder ring” of acronyms know what each one means. The “secret decoder ring” is not part of the document in this case, however, so the usefulness of the lists of dates will be limited, and some readers will be confused about exactly when the milestones are scheduled to occur. In the end, the information, and perhaps the entire plan, will be ignored by many, possibly until it’s too late for it to be helpful to them.
Proper organization can make the plan a better reference. Divide the plan into areas that represent different functional groups’ activities, or into work streams representing specific sub-chains of dependent tasks. This will make it easier for people to refer to, and allow them to see quickly what they need to do and when, or what will happen if a task is delayed.
The overstuffed plan is divided into separate row-areas for various activities, a good idea, but within each one there are 20 to 60 different dates, many with bars to indicate activities with start and end points, and the rest mostly attached to symbols. Unfortunately, the events and labels are crammed so close to each other it becomes difficult to figure out which symbol is associated with which date. In many of the sections there are boxes of notes and lists of dates that apparently wouldn’t fit into the chart. The result is a cluttered and confusing document that fails to guide the eye through the flow of the process. Most of this detail should be placed in subordinate plans to make the master plan simpler, easier to follow, and more useful.
Design the plan to show the flow of information and goods from their origins to the delivery of the final product. Graphically speaking, the plan should guide the eye and mind through the process in a logical way. Depending on the presentation, this can very clearly illustrate the dependencies and handoffs required to complete the project and quickly illustrate which paths are “critical” and set the duration for the entire project. Establishing a visible flow of events is also helpful in illustrating the effects of delays or changes in the schedule.
Choosing effective planning software and a system for communication and presentation of the plan yields both effectiveness and efficiency. A good project management software tool greatly streamlines the planning effort because it allows the planner to change dates as the process and its constraints change, and as events unfold, and shows the effects of those changes immediately. Planning software also enables the projection of scenarios so management can quickly see the potential effects of decisions before setting them in stone. In addition, good project management software enables a variety of presentation formats and the ability to quickly pull out sections of the plan, or “snapshots”, for review.
I have often had the experience of company management requiring plans to be rendered in a software tool that is of marginal value for planning, or perhaps not intended for project management at all. Sometimes this may be because a manager feels more comfortable when they can change the working copy themselves, or because they want everyone to be able to access the file with the company’s standard software package, and sometimes it may just be that the company won’t pay for everyone to have a real project management tool on their computer. Putting out finished plans in a common readable format such as Acrobat (pdf) files can allow you to use project management software, and can be a major help to the communication process.
Drawing programs and simple graphics tools can make nice looking plans, but with drawbacks. All too often, plans must be created using a graphics (drawing) program, or drawn using the graphics tools available in a spreadsheet tool like Microsoft Excel. This results in a plan that has no logical ties between tasks. Without this logical structure, projections are much harder to create, and when an actual date is added or a process change is made, the logical relationships between the events in the plan must be updated solely by the expertise and process knowledge of the planner and reviewers. This increases a potential for errors to creep into the plan that may not be apparent until too late. In a circumstance like this, an excellent process reference (or a lot of experience with the process) is even more essential than usual for the planner and reviewers. Appropriate reviews with stakeholders also become more important. Interestingly, a spreadsheet does have the advantage of being able to freeze rows and columns so that the reader can scroll through the document without losing sight of the timescale or area labels at the top and/or side of the document, but this is of less value than predictive capability.
A good plan can be printed out for reference, review, and marking up changes. Keep this need in mind as you design your plan. Consider the printing facilities available to your audience, and what the plan will look like when printed. Not everyone has access to a large scale plotter or a color printer.
I printed the overstuffed plan out on 11 inch by 17 inch paper in an effort to have a copy I could mark up, but even the largest text was reduced to something approaching a 4 point typeface – a magnifier makes it readable, but only barely. I would have plotted it onto E-sized paper (34 x 44 inches, or 864 x 1118 mm), but the company removed almost all the plotters from the engineering areas last year to save cost. Even if it could be plotted in a much larger size, you couldn’t read it at your desk without folding and unfolding it frequently, and it would be very impractical. On occasion I have seen plans like this plotted and hung semi-permanently on a conference room wall, but recently-intensified security rules where I work now forbid this.
A well-designed plan can be followed on the computer screen. Design your plan to be readable on a computer screen and test it out, possibly on a relative computer novice, to ensure your readers can easily use your plan. If the timescale is not easily visible in most views, and the timescale of the program is longer than a year or two, consider including the year in your dates.
Eventually I had to face the fact that it was necessary to refer to the overstuffed plan on my computer screen, but this brought additional issues. To read it, it must be magnified to the point where the timescales at the top and bottom are rarely on the screen. The dates are given as “date-month”, but, since you can’t see the timescale most of the time, you have to keep scrolling up or down to figure out what year the event occurs in. Not only does it sometimes become hard to find your way back to the part of the process you were reading, but the file is so huge from all of the details that the viewing software freezes your system for up to ten seconds every time you move the image as it slowly repaints the newly-revealed parts of the image. This is enough to discourage almost anyone from trying to read it.
A change log is a very helpful accessory document, and should be provided with the plan. With many of the plans I receive, I get a change log that makes it quick and easy to see what changed between the last revision and the current one. This can be a real time-saver. Unfortunately, since maintaining a change log can add perhaps 40% to the time required to update the plan, it is often omitted on plans of the size and complexity of the overstuffed one in my hands. Unfortunately, these are the plans that need it most.
I have considered finding a light table to help me identify changes in the overstuffed plan (I think there is still one in the building somewhere). I could overlay two successive versions of the overstuffed plan with the light shining through them to try to identify what changed, but the plan is unreadable on the largest paper size I have anyway, so that’s a lost cause.
In the end, few people are going to try to read a poorly designed or overstuffed plan, and a plan nobody reads is not going to be of much help to the organization. Most people will glance at it, put it away, and go on “flying by the seats of their pants”, working as they have in the past. Often a “Key Dates List” must be prepared to give people the basic event dates they need, but this will not help them understand their place in the overall plan, the information handoffs involved, or the importance of their work to project activities downstream from them. Frequently the planner must prepare a “Snapshot” document to show a specific subset of the plan’s events. Hopefully this isn’t too difficult in the format you are using, as it is a normal requirement from time to time. Also, much planning time can be eaten up developing “Look-Ahead” documents – basically rolling key date lists – for periodic review meetings. Key date lists, snapshots, and look-ahead documents are sometimes just band-aids to address the problems presented by a too-detailed plan, a poorly designed plan, or a plan developed using a poor choice of software. I use them only when absolutely necessary.
Know your audience, your organization, when reviews take place, and what makes sense to include in the plan. This could have been the first paragraph, but I think it will work as well here. There is no substitute for knowing who will be using and reading your plan, what they need in the way of both direction and presentation, and when they need it. Knowing this, you can (1) choose the appropriate timing granularity, as you don’t need to plan something day-by-day when the activities you’ll show all take weeks or months. Also, (2) know when the plan and project will be reviewed, and when changes are most likely to occur. If the plan is only going to be reviewed in detail at the end of each month, perhaps you can wait to update it until a few days before the review, update it again after the review (with the inevitable changes), and spend the rest of the month tracking progress and helping people understand what they have to do and when. (3) Identify the functional groups that could benefit from more detailed subordinate plans, and include the work to produce and maintain them in your estimates of time needed for the planning effort. (4) Understand what information will be available to substantiate the plan. I think it is a key point that there is little use in including details in the plan which you won’t be able to follow, as they will inevitably end up being wrong and adding to clutter. My colleagues and I have often joked about including in the plans how often the engineers are expected to go to the bathroom or answer the phone, as higher level managers sometimes seem to want this level of detail.
With the right knowledge and a bit of project management savvy, you can create a plan, or set of plans, that will be effective, easy to communicate and maintain, and which will guide your project to successful completion.
To summarize the suggestions above:
- Consider the audience(s) and design the plan to track and communicate only what is necessary to successfully execute the project.
- Establish an understanding, based on the general pace of business (which may change during different phases of the project), of how often updates will be needed or new information will be available. Also identify and document where to get information on task completion, delays, and process changes.
- Design your plan(s) with a timing granularity that matches the length and complexity of your project, and enhances clarity.
- Seek a happy medium between being comprehensive and effective – too much detail is as bad as too little.
- Organize the plan into functional areas, and, where possible, show the interactions between those areas.
- Avoid excessive detail in the master plan by providing subordinate plans to functional groups participating in the project, and include only their inputs, outputs, major reviews, and status checks as integration points in the master plan.
- Use symbols and acronyms only as necessary, and include reference information (the “secret decoder ring”) to explain them. Terms well known to all stakeholders may be omitted from references, but check to be sure of this.
- Avoid including tasks and events that can’t be tracked and assessed, but include those that will provide critical evidence of project status and be relatively easy to find out.
- Structure the plan so it can be easily followed on screen, and can be printed out for reference, review, and the marking-up of changes.
- Prepare a key date list only when the master plan is too unwieldy for easy reference, or when plan dates must be communicated to a recipient such as a supplier who should not see the master plan for security reasons.
- Prepare snapshot and look-ahead documents only when the master plan is too unwieldy to be used directly, or when there is a need to focus attention on a small part of the process or timeline.
I hope you’ve found this article helpful. Please feel free to submit your comments and questions, and I will either answer them or revise this article as needed. Thanks for reading, and good luck with your projects. – Tim
Postnote: I am pleased to say that this article was broken up and syndicated in July 2008 at a top notch project management website, http://www.pmhut.com. I appreciate the recognition, and suggest that if you are interested in project management there are many more informative articles to be found there.