In Part 1 of this six-part series on issue management we discussed understanding our users and project types in terms of how we go about managing project issues. In Part 2, we discussed the practice of identifying and understanding the business processes that are part of the customer’s organization on the projects we manage.
Now, in this third part of the series, I’d like to discuss the how we determine the data requirements for our issue management and our change control needs on the projects we manage. We capture issues, but what else do we need to capture? What data is needed to fully understand the issues, track them, assign them, and ultimately resolve them? What data do we need to capture and track for change requests and change orders on the projects we manage? All of these are key questions and all highlight the fact that the data we capture is critical to the ongoing nature of the work we do and report on for these engagements. Without the right data, what are we tracking? How can we know that we’re working on the right stuff and resolving the right issues?
What issue info do we need?
What is critical to capture when we’re performing issue tracking, management and resolution? First, we need to know the normal who, what, and why information. Who is reporting, who and what is affected, what the issue is at a high level and why it has been reported…meaning basically what are the symptoms or problems that brought it to someone’s attention. We need to know if it’s a showstopper, top priority issue or if it’s a small bug that can be taken care of with the next release or the next batch of work that gets performed.
What else do we need? As we perform further analysis of the issue, we certainly need to capture additional detail – much more than the initial high-level detail we captured when the issue was first reported. We need to capture dates as well. When was it reported, when does it need to be resolved, when do we think it will be resolved…realistically. Next, we need assignment and accountability information. Who is the issue assigned to – which individual or group? And finally, we need to understand how we’re going to test this issue upon resolution to know that it’s resolved and ready for implementation. Along with that, we need to capture customer signoff and approval including dates for these.
What change request info do we need?
Does the change request info differ from the issue information we must capture, track and report on? Well, yes and no. Basically, it’s the same. However, since change requests concern work that is to be performed beyond the original scope of the project, there is definitely a financial aspect to them. Estimates may be gathered for issues – and likely they will be. But they MUST be for change requests because they’ll be affecting the bottom line on the project. The budget will change as a result of change requests and often the customer must pay additional funds so there’s documentation, accountability and customer approval of any effort and cost estimation that goes into the change request. Beyond the cost info, most other key data will remain about the same – we still need to track the who, what, why, and when. It still must be assigned, tested and implemented. That’s why issues and change requests are generally very closely related and are often tracked together and reported together on project engagements.
If you’re looking for a solid enterprise issue management tool, check out Gemini. Gemini gives maximum flexibility with minimal effort to manage real world problems efficiently and quickly.
RSS Feed
