Many project management methodologies and some project management tool suites include processes to assist the project manager in recording and tracking open project issues. Issue Management is not specifically addressed in the PMBOK as a core project management process. An issue may just be something upon which a decision is needed. The decision may not necessarily change the scope, schedule or cost of the project... but the lack of a decision would affect the schedule. For those who are familiar with the PMBOK, what is your perspective as to how the issue management process integrates with, or does not integrate with, the PMBOK defined processes. Saving Changes...
I always saw this as part of communications management. True, it is not explicitly called out. However, when talking about performance reports and project records, I saw issues management and issues lists as part of this. Saving Changes...
Kenneth KatzRelease Train Engineer/IT Project Manager| UnitedHealth GroupEnfield, Ct, United States
Issue management is a key task for PM's that gets slighted in both the PMBOK and many PM software applications. Issues can arise in any phase of the project life cycle. Some are tied to a specific task or resource. Others are more global. Issues can also spawn changes in scope, resources or schedule. Saving Changes...
Bill BiglerProject Scheduler| Booz Allen HamiltonCentreville, Va, United States
I agree that the issue is withing the communication knowledge area and shoud be addressed in the communication plan.
In addition I like to use the project schedule as a communication tool of the issue, especially when the issue schedule meets the project schedule. For example, without a decision on this issue, the project will stop. One of the issues that we face here in my work is that we get funding for a lot of projects on a quarterly basis. if that funding does not start on 1 Apr, then the contractors are at risk or we stop work. This becomes a milestone in many project schedules.
I also add issues to my project plan as milestones and list current issues in a section of the status report. If an issue has not been adequately resolved and I'm waiting for input, the issue stays in the report from week to week with the date it originally appeared in the report noted.
However, neither of these methods is adequate for keeping track of all issues, particularly early in the project while defining requirements and design. I add an "open issues" table to the front of each articfact to keep track of issues related to that artifact. The issues that effect schedule in the short term make it into the status report. The others can be saved for reviews, working meetings, or conversations with relevant stakeholders. Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
I have often seen that people confuse and overlap issues with risks. Depending upon what your personal definition of an "issue" is, the Project Risk Management knowledge area of the PMBOK may be relevant.
I developed a one day training class on the Communications Management section of the PMBOK, in which I did not go into issue management in detail. As far as status reporting is concerned, I steered clear of issues, focusing more on progress and risks. As far as incorporation into a Communications PLan is concerned, I prefer to keep that focused on "This describes who needs what information, when they will need it, and how they will get it". This being the case, where would I plan how a project handles issues? I would plan it, put it in the Project PLan, and put it in a supporting processes section.
I have some free templates for project plans (that includes a brief communication plan) and a status report on www.westfordconsulting.com to show you how I view this subject with regard to these parts of project management.
Not a complete answer, but then as you say, it is not defined as a core process, and I believe is open to some interpretation. Saving Changes...
Why don't you put issues in your status report? Generally, the issues I put in there are directed at the recievers of the status report, e.g. it's something they have to do but haven't done. I'll also list issues that are causing delays. Although you might consider those "risk", I tend to use Risk lists and status more for projection and managing the future rather than the present. Make sense? I'd rather do it that way because it puts all the things that currently need to be dealt with in a status meeting in one place. Saving Changes...
Mike Cooper PMPPrincipal Project Manager (retired, sort of)| New England Project ServicesWestford, Ma, United States
There are many variations on a theme for a status report, so we would need to go into more detail to see if my and your report format / assumptions meets the needs of the reader.
I do note in my template I expect information on "what you need from your management and the client in the short term to make the project successful". This seems to cover your main use of issues.
In my time I have seen far too many voluminous status reports that actually rarely tell you the actual status of the project - they focus on the work that was done since the last report. This is why I promote short reports that focus on a brief summary, milestone status, progress and deviations from plan, risks, metrics (very small set), financial status and change control. Saving Changes...
Issues Management permeates all the PMBoK processes and Knowledge areas. Because issues can be uncovered anywhere and relate to any aspect of a project.
I don't think that the PMBoK not calling out Issue Management as a key knowledge area is very important. For one, the PMBoK is not a Best Practice, but a Common Practice. I also think that there is no one common way of managing issues across various industries.
Yes, issues should be managed and communicated. But the method will depend on your environment and your customer needs and expectations.
Most organizations have an accepted way of dealing with issues. We have our own Issue Management process, which I think is a bit of overkill considering some of our issues.
The high points are: make sure your issues are written, traked to completion and closed. Some issues aren't worth any more than that, some need to be escalated, or planned around. Just use common sense. Saving Changes...
I do post the open issues list to our project web site and always assign resources to deal with it.Actually ,each resource will see their own assigned milestones and assigned open issues.Updating the status for an open issues has the same priority like updating the work status. Saving Changes...
We utilize a web-based interface (Project Mgt Interface) for our customers to post issues, requests for application enhancements, and other detials the customer deems necessary.
Often the customer feels like their 'issues' are not being heard - this gives them a venue to contribute to the enhancements of their application. Our company builds composite applications and we have found this to be a great approach and is part of our implementation service delivery framework. It is actually critical for the customer to ensure the technology accomodates their business processes.
The issues entered by the customer are reviewed with our technical team and if approved based on a variety of considersations, are trasnferred to our our Project Tracking System - where our technical managers assigns to the apporiate developer. Saving Changes...
"You can make more friends in two months by becoming interested in other people than you can in two years by trying to get other people interested in you."
