I made a list of things I have
to remember and a list
of things I want to forget,
but I see they are the same list.
(Pastan)
Whether you are recording items you want to remember or items you'd rather forget, project management forms and logs can be among your most valuable tools as a project manager. This paper describes these useful, but sometimes confusing, tools in the project manager's toolbox and provides recommendations on how to make these work without drowning the project manager and team in paperwork.
First, let's be sure that we are speaking the same language. A “form” is the tool that you use to record a single item—an issue, a change, a problem, an idea, etc. Each item is represented on its own form. Documenting an item on a form gives it “life,” and provides tangible representation of the item for as long as it exists.
A “log” is a list of all of the items. The log lists only a few key pieces of information for each item, including item number, title, status, and one or two other basic fields. Items on the log should be linked back to forms, either logically by numbers and titles or physically, using hyperlinks or database features.
Why Use Forms and Logs?
In addition to the primary benefit of helping the team to remember things, forms and logs also serve other useful purposes for the project manager.
• They provide visible verification that the idea or concern has been heard and will be properly addressed. When sponsors or team members have an idea or concern, documenting their thoughts on the appropriate form helps to focus their thinking, and provides tangible evidence that the item will be seriously considered. Issues or concerns that have been documented and logged will not be easily overlooked or dismissed.
• They promote teamwork. Each person's items are logged and addressed with the same attention to detail.
• They serve as communication tools. Reviewing items on a log, or information on a form, is a simple way to focus a meeting or a conversation. Having the written documentation available keeps the discussion on track.
• They help the project manager monitor the progress of the project. During the planning stage, the project manager should anticipate the number of items to be dealt with and the rate at which the volume will grow or shrink. While the project is underway, the project manager can monitor the progress of the project by comparing his or her estimates for these volumes to the reality of what's happening on the project.
• They shift the project manager's and team's focus from “fire-fighting” to “proactive management.” Rather than dealing with each concern as it comes up, each is logged and scheduled to be addressed at the appropriate time.
• They document resolutions. Decisions and resolutions which are not clearly documented and approved by the participants are subject to “rehash” days, months, or even years later. From simple forgetfulness (“Why did we decide that?”) to second-guessing (“What WERE you thinking?”), many decisions will be revisited over time. If they have been documented, then the revisits can be limited to reopening the item only when new information is received. This alone can be a great timesaver for the project manager.
As always, it is up to the project manager and team to determine what makes sense for the specific project. In some cases, forms are not needed. If the following conditions are true, a log alone may be sufficient:
• Items will more often be addressed in a group than individually.
• The log can contain all of the pertinent information without becoming overly cluttered.
• Long paragraphs of text are not needed.
Exhibit 1
Exhibit 2
On the other hand, in some cases forms are useful but a log is unnecessary. The most common example of this is when the number of expected items is very small—fewer than ten. In this case, dealing with each item on an individual form is sufficient. A word of warning, however…many projects, regardless of size, will have more items to track than originally anticipated, so it's better to plan for the volume from the beginning. When you begin to get more items than you expected, it's difficult at that time to set up a log and process for managing them.
Many things can be managed in a project with forms and logs. Project management examples include ideas, best practices, risks, issues, and changes. Content examples vary depending on your industry, but typical content items that are tracked include requirements, modifications, test cases, and defects. In this paper, three items commonly managed with forms and logs will be discussed—risks, issues, and changes. However, the concepts used in managing these three things can be applied whenever the project manager encounters a list of items to keep up with.
Risks, Issues, and Changes
A risk is something that we are worried about in the future. It may or may not happen. “We may have to change more code than we thought.” “We might lose a resource.” “The test environment may not be ready in time.” “The materials may not be of the quality we need.” There are classes, books, and entire industries built around the concepts of risk management. Risk Management is one of the nine Project Management Knowledge Areas described in A Guide to the Project Management Body of Knowledge. This paper will not attempt to cover risk management other than to say that the project manager should address a risk by developing strategies to mitigate the risk and planning contingent actions to implement in case the risk event occurs.
An issue is something of concern in the present. It's happening now. “We need a decision made on which software version to use.” “We don't know how the employee address should be stored.” “We don't have anyone who knows JAVA.” “The response time is so slow that we can't get our test cases entered.” In contrast to risk management, issue management is rarely addressed with much formality or detail in project management literature. However, responding to issues and questions effectively can be a critical success factor for a project. Typically the response to an issue requires research and analysis followed by decision-making, either by one person or by a group. The effective project manager will quickly identify the person or group with the right level of knowledge and authority to deal with each issue or question.
A change affects something that is in the past. We've already been there, but we have to go back again. “We have to make a design change.” “We had 10 people assigned, but we just lost two of them.” “We designed everything to work with one print package, but now we are using a different print package.” Change Management is often considered to be synonymous with “Scope Management,” but the project manager can benefit by managing any change on the project—not just changes to the scope. Each proposed change should be evaluated to verify that the value of the change justifies its impact to the project's budget, schedule, risk, and quality.
Exhibit 2 depicts the basic differences among issues, risks, and changes.
It is possible to track all three of these items in the same log. In fact, sometimes it's difficult to determine whether a particular item is a risk, issue, or a change. However, the response to each is different, so even if they are maintained together, the project manager must analyze each one to determine whether it is a risk, an issue, or a change so that the team can respond appropriately. In addition, the project manager should analyze each item to determine if it will spin off other items. A risk strategy may result in a change. A change may introduce new risks. An issue may include risks or changes. To keep up with this, it helps to have a way to cross-reference these items against each other.
A Word About Tasks
In the context of this paper, a task is something that needs to be done. “We need to run an ad in a trade magazine.” “Don't forget that the city requires a different permit.” “The lawyer needs to review the document before it's sent out.”
Tasks should not be kept in a log. Instead, they should be made part of the Work Breakdown Structure and the Project Schedule.
The discerning project manager will watch out for tasks that inadvertently creep into the issue, change, or risk log. Often, a task is masking something more serious—a true issue, change, or risk—and the project manager must ask additional questions to ferret out what's really going on. For example, using the task listed above, “The lawyer needs to review the document before it's sent out,” the project manager would want to ask the following: “Does the lawyer review indicate that we missed a role required on a previous task?” If so that's a change. “Are we worried about what might happen when the document is published?” If so, there's a hidden risk, and we may need to explore other strategies and contingent actions.
Once the underlying cause has been determined and accounted for, the task should be added to the schedule so that it can be assigned and tracked with the other project work. Keeping tasks in the issue log instead of in the project schedule gives a distorted view of the remaining project work.
Management Process
Plan for managing the various items as part of developing the project plan. Determine which items will be logged—issues? risks? changes? lessons learned? defects? requirements? other?—What is the appropriate response for each, who is responsible for managing them, when they will do it, and how. Create templates, forms, and logs. Document the approach. Estimate how many items are expected over the life of the project, the timing for them, and how long each will take. Include tasks in the project schedule for managing and addressing items.
If your company provides a standard methodology plan for managing issues, risks, and changes, review the corporate standard to be sure that you understand it and agree to follow it. This is the time to resolve any disagreements about how items will be managed.
Execute the management plan. Follow the plan as outlined for recording and managing items.
Control the items. Include counts in status reporting. Compare the actual counts and timing against the plan. Determine the impact to the project of any variances. Compare the estimated time per item against the plan and adjust the plan if necessary based on the variances. Review the actual management process. What's working and what isn't? What changes should be made? What are we learning as we go?
I understand, But I'm Still Drowning
Wow, this is enough to swamp even the most experienced project manager! Here are a few tips to make it work:
• Use automation when available. There are packages on the market specifically designed for managing issues, requirements, risks, changes, and other items that need to be logged and tracked. If you have one of these packages available, learn to use it and use it fully. If you don't have one of these specialty packages, your spreadsheet software has many features to make your life easier. Don't settle for a basic knowledge. Learn to make the software work for you by using its functions and graphing capabilities.
• Keep it simple. Don't use two forms if one will do. Don't add handoffs, reviews, signoffs, and approvals to your management process where they are not absolutely required. While designing your process, think, “What is going to make this difficult?” and work that out of the plan. If you use codes, use as few as possible. For example, “New,” “Open,” “Closed,” and “Postponed” are usually sufficient to describe status.
• Identify what's what. Clearly differentiate risks from issues from changes from tasks from requirements, etc. If it isn't easy to see exactly what you are dealing with when you look at an item, you will not be able to quickly know the response needed. One simple solution is to keep one workbook file with separate worksheets for each type of item. That way everything is in one place, but you can still work with them separately.
• Do it yourself. In the absence of an administrative assistant, the person who “owns” the log should be responsible for recording and managing items on the log. If the items to be managed are test defects, it makes sense for the test manager to maintain the log. But, when the items are issues, risks, and changes, these ultimately belong to the project manager and therefore the project manager should record and manage them. This is one service that the project manager can provide for the team. Time that the team members would spend recording and logging items would be better spent doing the work of the project—designing, building, testing, etc. Doing it yourself also assures that it's done correctly without the time expended in nagging and follow-up.
• Avoid duplicate work—Design the forms and logs so that a minimum amount of information is required in both places. Use the form to record lengthy text details, and the log to record the control information that will change often, primarily status codes.
• Keep it handy—Unless you are keeping your log on paper, perhaps on a flipchart or whiteboard, learn to work from the electronic file without printing it onto paper. Paper copies of printed logs quickly become obsolete and it's difficult to tell which is the current version. If you are using electronic files, encourage team members to place a shortcut to the log on their desktops, so that items are readily available for discussion and resolution.
• Update regularly—Updates to the items and logs should be recorded promptly, but at least weekly as part of the status management and reporting process, and be sure to show the revision date and time. The logs are as valuable as the project schedule and should be maintained with equal care and attention.
• Use it often—By frequently referring to the log and by using the forms as the basis of discussions, team members will become accustomed to them and soon begin to expect that all of their ideas, concerns, and questions be formally logged and managed.
In Closing
If you are a project manager who has not consistently used forms and logs, I encourage you to include them in your next project plan. Because a form represents an idea, concern, or thought of a project participant, each one has value. The care with which you handle the written representation of a person's thoughts is a visible expression of your care for that person. Through attention to detail in the management of risks, issues, and changes, the project manager can build trust, earn respect, and keep the lines of communication open.
Exhibit 3
If, on the other hand, you are a frequent user of various types of logs, by applying the principles in this paper you can take control of them and make them work for you. Through careful planning and management, you will find that instead of drowning you in paper-work, well-designed and well-managed forms and logs will become your life raft as you navigate the rough waters of your project.
