Issues are more than just common problems. They are problems that meet specific criteria. An issue is a formally-defined problem that willimpede the progress of the project and cannot be totally resolved by the project manager and project team without outside help. The processes used to manage issues can be simpler or more rigorous depending on the size of the project. Use the following process to manage issues on large projects.

1. Identify the problem and document on the Issues FormSolicit potential issues from any project stakeholders, including the project team, clients, sponsors, etc. The issue can be surfaced through verbal or written means, but it must be formally documented using an Issues Form.
2. Determine if the problem is really an issueThe project manager determines whether the problem can be resolved or whether it should be classified as an issue.
3. Enter the issue into the Issues LogIf it is an issue, the project manager enters the issue into the Issues Log.
4. Determine who needs to be involved in resolving the issueThe project manager determines who needs to be involved in resolving the issue. The sponsor may be involved, or the sponsor may not have the expertise to assist in the resolution process. For instance, the problem may be contractual and require resolution from the Purchasing Department. However, at some point the alternatives will be discussed and a resolution will be made. It is important to understand up-front who needs to be involved in making this final issue resolution.
5. Assign to team member for analysis and alternativesThe project manager assigns the issue to a project team member for investigation (the project manager could assign it to himself or herself). The team member will investigate options that are available to resolve the issue. For each option, the team member should also estimate the impact to the project in terms of budget, schedule and scope.
6. Gain agreement on resolutionThe various alternatives and impact on schedule and budget are documented on the Issues Form. The project manager should take the issue, alternatives and project impact to the appropriate stakeholders (from step 6 above) for discussion and resolution. The project manager may want to make a recommendation from among the alternatives as well.
7. Close the Issues LogThe project manager documents the resolution or course of action on the Issues Log.
8. Close the Issues FormThe project manager documents the issue resolution on the Issues Form and then closes and files this document.
9. Add action plan to the scheduleOnce a resolution is agreed upon, the appropriate corrective activities are added to the schedule to ensure the issue is resolved.
10. Communicate through the Status ReportThe project manager communicates issue status and resolutions to project team members and other appropriate stakeholders through the methods established in the Communication Management Plan, including the project Status Report.

Smaller projects do not need all of these steps. For instance, the issue can be documented directly in the Issues Log without the need for the separate Issues Form.

When you create a schedule you generally don’t know enough to enter all of the detailed activities the first time though. Instead, you identify large chunks of work first, and then break the larger chunks into smaller pieces. These smaller pieces are, in turn, broken down into still smaller and more discrete activities. This technique is referred to as creating a Work Breakdown Structure (WBS).

A question people ask is how small the activities should be before they do not need to be broken down further. This is referred to as your “estimating threshold”. Work can be broken down into smaller activities than the estimating threshold, but normally no work would be left at a higher level. The threshold can be different based on the size of your project and how well the work is understood.

You can use the following criteria as a guide. For a typical large project (say 5000 effort hours or more) the activities should be no longer than two weeks. Medium and small projects (say 1000 effort hours or less) should have activities no larger than one week. Remember that this threshold is an upper limit. You can break the activities down further if you want.

Assigning work that is smaller than your threshold allows the work to be more manageable. Think about it. When you assign work to a team member you don’t know for sure how he is progressing until the due date (or the completion date if it comes first). (Yes, you can track progress if the work proceeds linearly – like painting a wall. But many of us work in the knowledge business (IT, Sales, Finance) and it is not easy to know exactly how the work is progressing.)

Let’s look at an example. If you assign a team member work that is due in four weeks, you are not going to know for sure whether the work is on time until the four-week deadline. The worker may tell you things are on track, but you don’t really know for sure until the due date. If the work is completed you will know you are on track. If the work is late you will know it then as well. However, four weeks (or longer) is too long to wait to know if the work is on track. A better approach is to break the four-week activity into four one-week activities. Then you will know after the first week if the work is on time or not.

If at all possible you want to try to have schedule work completed within two weeks. If you give someone work that takes four weeks or longer there is just too much time before you really know if things are on-track or not. It is much better for you if you can keep the schedule feedback loop to no more than two weeks.