Messages on Issue Management and the PMBOK

Email Notifications OFF

Original Post:  Issue Management and the PMBOK Rich Eaton Sr. Project Manager, Blue Cross Blue Shield of Nebraska Omaha, NE, USA 89 posts Posted Dec 17, 2001 8:21 AM 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.

Replies Sort:   Newest First    Chronological     Post a Reply Page: 1 2 next>   Andrew Sparks Senior Practice Director, Oracle Eindhoven, Netherlands 6 posts Posted Apr 14, 2008 5:03 AM Coming across this thread 6 years later... I was also surprised that it issue mgt is not explicitly address in PMBOK - but their tack indeed is more focussed on risk management. It is all about your use of nomenclature. Main thing for me is that issues/risks need to be captured and documented in order to be managed, and that the technology used needs to be simple and accessible enough to encourage use. I did like the article by Ikeda here in Gantthead on issue mgt - look it up Rich Eaton Sr. Project Manager, Blue Cross Blue Shield of Nebraska Omaha, NE, USA 89 posts Posted Dec 19, 2005 6:48 PM We are using both Issues and Risks in Project Server for all projects under our PMO's direction... for about a year now. We also made several changes to the Risk template. We made a few tweaks to the Issues template.. mostly cosmetics. We created a process that allows the project teams to escalate a risk/issue to PMO visibility.. otherwise the risk/issue is only visible to the project team. If an issue/risk gets escalated, it goes on our PMO agenda for that week for discussion and/or resolution and/or assistance. It has been effective for us. Dana Welch San Francisco, CA, USA 1 posts Posted Dec 19, 2005 6:39 PM Is anyone using Issues on PWA/Project Server for all their projects Program wide?. Our team, based on PMBOK and some best-practices, modifed the Risk template, but I'm looking for similar reasons to either go with PWA "Issues" as-is, or dig deeper and look to see if there is a "there" there Mark Perry Orlando, FL, USA 674 posts Posted Feb 13, 2005 1:08 PM Dear Rich, I share your perspective and agree with the excellent replies to your post. I would only add that many people view the PMBOK as a body of knowledge, a great foundation, but not exactly a complete methodology or process for project management. Using the PMBOK as a foundation, one can extend upon it to provide very useful and usable processes for project management. In addition to the points you raised, others have raised pre-initiating activities (project selection), gating, post closing activities (continuous improvement) as areas vital to any PM methodology or process. Thanks for a great post! Cheers. -- Mark Perry, VP of Customer Care, BOT International Mark Tinsley Melbourne, Vic, Australia 16 posts Posted Feb 6, 2002 7:12 PM I have a tendancy to agree with Roger Reinsmith (25th Jan)... I see issues as things that can affect the core Functions(Scope, Time, $ and Quality) and are managed using the supporting Functiuons (Risk, Communications, HR and Procurement. .....Risk is about avoiding and preparing for issues. .....Communincations is about letting people know and make decisions bout issues. .....HR is about managing the people (often a key cause of issues) .....Procurement is likewise Third Parties are a common cause of issues. Perhaps I simplfy it a bit too much, but it is my summary. George Cookman Wakefield, MA, USA 1 posts Posted Feb 6, 2002 12:58 PM I agree with inclusion in the Communication Management Plan! We have an issue/bug tracker we have developed for use on projects which allows us to track issues from day one of the project. It has a way to include all of the WBS with associated documentation where,in the future, I will be storing up to date Functional specfications. Since these can be linked into an issue, we will be able to see all places where a requirement(s) has been linked to an issue. As we get into testing (QA and User), we continue to use the same database giving the bugs different attributes. There are some hooks that allow it to become a (rudimentary) knowledgebase, but it has been a real life saver when someone say, "I thought we discussed that and we had decided to ..." It has a capability for logging sequential progress notes (Internal notes cannot be seen by our clients, but Public notes can) so one can follow an entire thread. I tried using MS Outlook for this, but it was not robust enough. The tool is browser based with a SQL Server Back end so it is useable on the web (for customers with a login) as well as internally (We have several offices in the USA). I used it for the first time on my last project and it will definately be included in my Communications Management Plan on all future projects! There are a lot of free BBS software offerings out there which could provide the same sort of chat capability. They lack a true database and indexing, but they could be an interim solution. Tammy Sheffield Oakland Park, FL, USA 8 posts Posted Feb 3, 2002 10:54 AM 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. Robert Knight Boston, MA, USA 3 posts Posted Jan 29, 2002 8:49 AM 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. Roger Reinsmith Southfield, MI, USA 19 posts Posted Jan 25, 2002 10:04 AM Hi all, 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. Mike Cooper PMP Westford, MA, USA 51 posts Posted Jan 14, 2002 7:48 AM 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. Page: 1 2 next>