The Issues List is one of the most simple and most effective tools you’ll ever use as a business analyst. The list itself is simple. The ability to maximize its impact is the sign of a great business analyst. It has power when you use it proactively and effectively.
We’ll briefly talk about what the issues list is, then look at how to track issues in the list, and finally spend most of our time going through practices that ensure it’s effective at managing issues.
In a nutshell, this document or repository contains a list of all issues relating in any way to the requirements for a project.
Issues List Template
Here’s why my Issues List Template looks like:
(While you can recreate this yourself in Excel, you might like to know it’s included ready-to-go in our Business Analyst Template Toolkit.)
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.
How to Track Issues Using the List
There are a few basic guidelines for submitting issues to be added to the issue tracking 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.
How to Ensure the Issues List Results in the Effective Management of Requirements Issues
A list or tracking mechanism alone does not get your requirements issues resolved. You have to manage the list. Here are the guidelines I employ when managing an issues list.
- 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 creates 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.
>>Get Your Issues List Template
My issues list template, including embedded guidelines for managing the list effectively, is included in the Business Analyst Template Toolkit. The Toolkit also includes my requirements specification templates and business analyst planning and work aids. All of the templates in the Toolkit are fully editable and annotated, giving you a great starting point for your next project. And all come with accompanying work samples so you can see what a filled in template would look like.
Click here to learn more about Business Analyst Template Toolkit
6 thoughts on “An Issue Tracking Template for Requirements Issues”
Pingback: 10 consejos para involucrar a las partes interesadas – krakken
Pingback: 53 Tips For Discovering All the Requirements | Learn Project Management
Pingback: EFFECTIVE COMMUNICATION –A MUST FOR A BUSINESS ANALYST | Anisan Technologies
Is a issue list different than a list of questions?
Yes, it is specifically issues. Some of them may be questions but others not.
Pingback: Requirements walk-thoughs, just do it! « Bridging the gap between business and IT