The Secret Life of Issue Lists (Part1)
By asparks on Apr 21, 2009
Sometimes little things can make a big difference, and sometimes those little things are right there in front of you, waiting for you to notice them.
Take project issue lists for example
As a key project document I first started getting interested in them about 10 years go when I was doing a lot of Critical Accounts & remediation work. It was impossible to go into a project and have an agreed issue list waiting there, ready for you to work on.
Nothing has changed. Getting agreement on what the key issues are and their status still feels like getting blood out of a stone.
Recently I decided to have another look at issue lists in projects in the light of some of the latest thinking in the fields of personal productivity and sociology. I wanted to see if that led to any new insights on how those concepts could be applied in the context of project teams.
Obviously the underlying question is "If we manage issues better, will that improve our project outcomes?”
I was pleasantly surprised with the results.
I wanted to better understand why issues were such slippery things to manage.
I had the feeling that issue lists tended to generate a feeling of antipathy or resistance on the part of the PM or the team, especially on the part of the customer. There seems to be a fundamental disconnect in expectations.
The common expectation seems to be that projects should be like a straight race.
The reality is that they more often resemble a cross country or steeplechase event.
Issues are like a bunch of inconvenient truths standing between you and your project goals.
“Ugh! I'll do "something" with them "sometime" because the methodology says so." is often the unspoken thought of many PMs.
I decided to discuss this phenomenon with some colleagues to get other perspectives.
Perspectives – Critical Accounts
I talked to Sharon Smith, a Director in Critical Accounts. Critical Accounts is all about issue management - so they might know a thing or two on the subject
Her key points were about discipline, capture, technology and ownership
Not everyone understands that you need to be a bit disciplined about issue management in projects. Issue management needs to be a formal process in projects. Unfortunately it is an informal one just about everywhere else.
The customer may feel that it is OK to mention something vague about a problem when they meet an Oracle employee at the coffee machine. That does not mean that Oracle, or the project team, has formally registered that issue.
Another example is where the customer has logged a software issue in their internal IT system, but it’s not logged as a project issue (or vice versa) and not logged with Oracle Support (or Development if it is a bug or an enhancement request).
To manage issues you need to capture them. Issues “in the wild” just tend to get bigger.
Technology does not always help you get to grips with capturing and managing issues. Sometimes it can make it worse. Any system for collecting issues needs to be simple and accessible if people (project team members and users) are going to actually use it.
Ownership. Not just each issue, but also the issue process as a whole needs an owner. Hint: the customer needs to at least be part owner so the process can continue when the consultants have left the site. No owner(ship) equals no progress.
Perspectives – Risk Management
A conversation with Risk Management (Suzi Weinmann-Jaffe and Bernadette Uesbeck) brought other aspects to light particularly in the areas of organizing and review and reporting.
In complex or escalated projects (where we typically assign more experienced PMs) the issue lists are a key focus area and tend to be well organized, thoroughly maintained and frequently reviewed. In Risk Management’s view there is a clear correlation between PM experience and quality of issue management.
In organizing the issues we looked at the idea of supersetting & subsetting.
Mature PMs (either on the customer side or on the consulting supplier side) realize that both parties will have issues related to the project that are not necessarily for public consumption. Oracle (for example) may have resourcing or other internal issues to deal with in the same way the customer PM has. A project issue list may just a part of a superset of issues that add Oracle and Customer-specific issues that may need to be kept separate from the public issue list. The key here is to accept this and to manage them appropriately in both parties best interests.
Conversely you need to recognize subsets.
The project issue list needs to be a snapshot of all of issues that have a substantive effect on project scope or effort. This is not to say that this is the only detailed list that everyone works to. We need to recognize that the list itself is not the only place where the issues are worked (and we should not try to make it so). It does have to have placeholders to track progress on key issues that are being worked on elsewhere (e.g. SR/TAR's Bugs CEMLIs). The trick is
Reporting Is Not Equal To Managing/Reviewing
Suzi made the point that reporting on issues in the project progress reporting often seems to suffer the same resistance problems as actually capturing and managing issues in the project. People often just go through the motions of issue reporting to satisfy “external” processes.
Risk management or IT Audit or other departments are not the true customer for the issues reporting in projects. You and your project’s stakeholders are. It's all about stakeholder management and consistent reporting of the issues - even the difficult ones so you can change gear and escalate when needed and it is no surprise to anyone.
A common theme in less well-managed projects or customers is a pattern of no No News, No News, Panic!!
Certainly it is the consistent reporting of issues from early in the project that is a hallmark of experienced PMs and in-control projects. So the pattern there looks more like
News, News, Escalate, News
Perspectives – Program Manager
I continued the discussion with one of the PM's in my team - Thomas Elwers.
We followed on from the Supersetting/Subsetting discussion. Can we unify issue lists?
We talked about the wide variety of issue lists (logs) in Oracle’s Methodology OUM (I counted 6!) and whether that helps or hinders good issue management.
It’s difficult. The main thing is that you get a complete overview. Use as many different lists as you need – but no more than that.
All of the "stuff" that emerges in a project can be reduced an issue. An open loop - something is not where it is supposed to be, but can have a substantive impact on scope or effort.
What is substantive? Depends on the size of the project and the phase.
There are different flavors of "issue" - like (software) problems or risks (risks = issues that have not happened yet) Some things we track are not issues - but resolutions to issues. For example:
- Scope change
- Resource load change
- Business process change
- TARs/SR//Bugs/Enhancement Request/Patch
It is also interesting to note that the concept of issue lists does not appear in the PMBOK. PMI prefer to stick to management "risks". OK by me – though I tend to think of risks as issues that have not yet happened.
Thomas confirmed that he really uses the issue list as a core element in managing project execution. It echoes the point made by Risk Management.
Managing the scope deliverables& tasks per the contract is about managing the known’s.
So here we could say that issue management is about managing the unknowns of a project as they emerge.
For me this was a key insight into the secret life of issues lists. They are central to the good running of a your project, not just a list in inconvenient things standing between you and your project goals.
In part two of this post I will look at issue lists using some of the latest thinking from the fields of personal productivity and sociology.