Building an Effective Issue Triage Process
With more and more software implementation being COTS (Commercial Off The Shelf) styled solutions, the centerpiece of a lot of projects these days is the testing and acceptance phases of the project rather than the design and development, since the customer is buying something that is already (or hopefully mostly) designed built. With an increased focus on testing, one of the most critical activities to complete in advance of this phase is defining an effective issue triage process. This post will describe the key elements of setting up a process for your teams (and your customer) to manage the reporting and remediation of issues during your project.
Define Customer Ownership
It’s vital that the customer have some “skin in the game” when it comes to reporting and re-testing issues (for the sake of this post, please consider an “issue” to be a perceived product defect, not a project issue). Work with your customer team to define who is going to be the gatekeeper of all issues reported by the customer team and make sure that individual (or group of a small number of individuals) has the knowledge and the authority to understand, classify or even remediate issues that come from the customer team. This may seem like a bottleneck to the process but it’s actually quite effective when considering that issues are triaged at the customer level on a consistent basis (what is one person’s P1 may be another person’s P3). This way, by the time that an issue reaches the project team, it’s been vetted by a consistent customer representative and therefore will add more predictability and consistency to the overall approach of diagnosing and ultimately fixing the issue.
Set Strict Assessment Criteria
At the outset of the testing phase (or even the project) it’s a very good idea to set forward defined criteria for assessing issues as they are reported, specifically to the priority of them since contracts often have language in them regarding the resolution of issues of a specific priority (ex. acceptance hinges on the resolution of all P1 and P2 issues). By putting language forward to your customer (even in the contract itself) that defines each severity level in very clear, unambiguous terms you are ensuring that both yourself and the customer team are adhering to the same classification schedule of issues and therefore will allow for a fair and level playing field when it comes to the triaging of issues for your testing phase.
Exercise Disciplined Focus
No process works well without adhering to disciplined execution but it’s worth mentioning again. Often times as testing proceeds, if there are special cases where the rules are not adhered to, this tends to build and grow into more and more issues by-passing the entire process until you have a mess of incorrectly assessed issues on your hands and now have a true project issue of possibly not being able to close out a phase or gating point of your project because you’ve let go of the process and allowed for outliers to corrupt the process. Stick to the process, enforce your team and the customer team to do the same and you will make it easier on yourself (and the project) in the long run.