Having determined our goal of zero defects, and determined what a defect is, the $10,000 question is what do you do with them. After all, it’s one thing to identify what a problem is, it’s entirely another thing to solve for it.
The easiest approach
Every company will accumulate defects as time goes on (or at least I hope they do… if you know someone who’s proactively solved every possible problem please let me know!). The type and quantity will differ, and may change over time, but at the end of the day there’s always a pile of things that need solving. The important thing is what is done with those defects.
The simplest approach is to collect them, which at its most minimal approach tends to be some kind of shared email inbox. This is a very common approach for smaller groups, or groups bootstrapping the process with no previous experience or resources. After all, it’s really easy to spin up a new email inbox and share out the alias with everyone.
This approach, however, gets out of hand incredibly quickly. The inbox will either get flooded by all the incoming requests, or trying to keep track of everything becomes incredibly complicated and convoluted. Having more than one agent (someone who responds to the emails) makes this even more challenging to keep track of (imagine 10 people monitoring a single inbox that gets 100’s of emails per day… how do you control who gets which email? How about metrics tracking? Followups?).
The next step
Another more advanced, but still very common approach is to collect these requests in some form of a ticketing system. Having a ticketing system adds some level of complexity to the process (it needs to be setup, administered, paid for, etc.), but this complexity provides a better foundation to provide support to customers. Equally importantly it provides a framework to draw data and insights from (e.g. when tickets were created, who made them, what they’re about, etc). These data dimensions make the more advanced work much easier.
Requests can come into the system directly, or be piped in from an email alias, but regardless of entry point those requests are monitored by a support team. This team is (hopefully) focused entirely on answering those requests. While it is possible to have part-time teams, breaking their focus onto other responsibilities will reduce both the number of requests responded to, and the quality of those responses. You are also preventing yourself from learning more about patterns in your requests since any given agent won’t have complete exposure to everything. It is also incredibly important to support these agents with whatever training or knowledge base information is necessary to handle the majority of those challenges. This is an ongoing goal, but something that must be started sooner rather than later.
A shared inbox or ticketing system is a necessary step, but it doesn’t do much, if anything, to prevent the defects from occurring in the first place (our actual goal). While the challenges/pain the defects cause must be addressed, simply collecting them doesn’t help stop the next defect from occurring.
Reactive analysis
To actually help reduce the number of defects, someone (or a team of someones) is needed to and analyze the incoming defects. Their goal is to better understand the defects that come in, and look for ways to help plug the leaks. What this team can learn from the defects is largely dependent on the quality of the incoming defects. This is partially reliant on the collection method (e.g. email vs. a sophisticated ticketing solution), but is also impacted by the teams ability to understand what the defects are and routing them appropriately.
By critically examining known defects, this team can then make recommendations to the business on how to prevent future defects. These recommendations may be the result of identifying patterns in defects (e.g. every tuesday we get a lot of tickets about entering time), or observations about improvements (e.g. update a button placement so users see it more easily). Since every business and group is different, the recommendations will vary, but the end goal is to provide guidance on how to stop the defects from recurring. This team should be formally and informally connected to the business units they advise.
Proactive avoidance
Reactively examining defects can provide guidance for changes to stop future defects, it would be much better to prevent those defects from ever occurring. To me, this goes beyond standard QA since some things cannot be easily QAed (for instance an onboarding program or policy). This is where proactive assessments come in. Think of these as pen-tests for other areas of the business; a complex examination of existing systems or processes that attempts to uncover faults before your customers (or fellow employees) find them for you.
This is further complicated since the business is constantly changing. It requires the totality of the process being examined any time a change is made to a process, a new policy is rolled out, or a new patch is released. This is no small ask, and requires a team that is equipped to go in and try to break everything in any way they can imagine. Say a payroll system is updated to provide more employee self-service (a recommendation from your defect analysis team). Your proactive team would need to think through a number of things, including:
What readily available documentation is available to employees?
Can it be easily found?
Are managers aware of the change?
What formal communications are going out to employees to let them know?
What information is made available during onboarding and retraining?
What other information sources should be updated (bulletin boards, etc)?
What downstream systems might be impacted? (change management)
The specific questions would differ depending on the changes and environment. This team may also opt to only focus on specific areas (e.g. payroll related items) to provide a more focused impact in higher-risk areas.
At the end of it all, it’s not a question of will there be defects, just when they will occur and where. While handling defects after they occur is necessary, groups need to better understand the weaknesses of their current processes and proactively plug them up. While it does take energy and time, it results in significantly happier customers.