Why use an issues list?
The Issues List is one of the most simple and most effective tools you’ll ever use as a business analyst. It has power when you use it proactively and effectively. The list itself is simple. The ability to maximize its impact is the sign of a great business analyst. We’ll briefly talk about what the list is and then spend most of our time talking about how to use it effectively.
In a nutshell, this document or repository contains a list of all issues relating in any way to the requirements for a project.
Sample issues list template:
The point of this list is to describe the issues as succinctly as possible, identify an owner, and capture decisions to refer back to later. Priorities should be dictated by an issue’s impact to the progress of requirements or the project as a whole. The format doesn’t really matter. Microsoft ExcelTM works perfectly fine. If you have access to a web-based tool that you can easily customize to suit your needs, even better. Just don’t make the mistake of thinking that because the issues are on the web you don’t have to manage them-you do.
Core principles of the Issues List
- Anyone can submit an issue.
- The BA owns the list itself, but not every issue on the list. You’ll go insane if you try to own everything and no one will pay attention to the list.
- The owner is accountable for resolving the issue.
- The entire team is made aware when an issues is resolved. This is best when it happens in a face-to-face setting, such as a regular requirements meeting. Since not everyone is involved in the resolution of an issue, often the decision one subset of the team makes impacts other aspects of the project. Often resolving one issue opens another.
- Most importantly: Putting an issue on the list does not table the issue. I have seen way to make teams say “take this offline” or “we’ll discuss that later” only to have the issue surface weeks later as a show-stopper for some aspect of the project. The issues list must be living and breathing. It’s how people interact with the project requirements.
- Don’t box your list. Issues don’t have to be just about requirements. Often a developer can’t sign off on the requirements until some aspect of the design is complete and he knows the requirements are feasible. If this is the case, by all means include the design issue in your list.
- Own the list. Add to the list and publish it often. I find that actually bringing up the list in a meeting and adding the item while everyone can see it on the projector breeds consensus around the list itself and also the description and priority and ownership of the issue.
- Capture decisions. You are failing if you allow the team to rehash old issues unless there is an extremely valid reason. Just forgetting the decision was made is not a good excuse.
- Prioritize issues based on project dependencies. You should have a plan for your requirements and know when this issue is going to keep you from moving forward. Prioritize accordingly.
- Understand every issue on the list and its potential impact. If you don’t understand it, clarify it with the team. Resolving ambiguous issues is a waste of everyone’s time.
It seems too simple. Does an issues list really work?
This tool is powerful because it breeds accountability. High priority issues should be looked at in every meeting…keeping these issues in the forefront of everyone’s mind ensures they get resolved. I’ve seen issues get resolved simply because someone had a great middle-of-the-night idea, most likely spawned by that issue getting pushed into their consciousness often. The tool also enables decisions to be made in small groups but published to larger ones and provides an avenue to get people outside the core team involved in the issue without having to involve them in the team as a whole, saving their valuable time.
This tool is part of your requirements management strategy and can often be a powerful meeting management tool. When you are conducting requirements reviews, you can’t stop to discuss every issue in detail because people begin to lose the forest for the trees. But you also don’t want to lose important project insights. Active management of these issues on a list like this contributes to successfully managed requirements and projects.
|
By Laura (Brandau) Brandenburg. Laura Brandenburg is an independent business analyst consultant. She is passionate about the BA profession and is committed to contributing by supporting this blog as a forum for business analysts to build on each other's experiences. View more blog posts by Laura (Brandau) Brandenburg |
Related posts:
Loading ...
.jpg)
{ 1 trackback }
{ 0 comments… add one now }