Delivering High Quality
“Quality is not what happens when what you do matches your intentions. It is what happens when what you do matches your customers' expectations.” ~ John Guaspari
“Quality is the result of a carefully constructed cultural environment. It has to be the fabric of the organization, not part of the fabric.” ~ Phillip Crosby
Quality
In a traditional office environment, quality and productivity are often judged by the number of hours a worker spends in the office. Someone producing lower quality deliverables can improve their standing by simply increasing their time in the office (e.g., first to arrive, last to leave).
In a remote environment, however, your teammates, managers, and clients care about one thing only: the quality of the output you deliver. Low-quality output - wherever it occurs in the network - negatively impacts subsequent team rooms and ultimately the customer.
When a quality failure is discovered by one team (e.g., by the Quality Assessment team), it is promptly sent back to the previous team room to resolve.
The later this occurs within the overall workflow, the more rework is required, and the more teams are impacted. Of course, the worst case scenario is that a defect passes every team, undetected, and eventually reaches the customer.
Perfection is the goal
The idea of 100% quality can be intimidating. Yet, the success of our entire enterprise is built upon clear and objective, content-focused Quality Bars - the list of checks the Quality Assessment teams apply.
By embracing these principles and measures, they will ultimately guide your own success, too. The first step is to familiarize yourself with (then internalize) your own team’s quality bar.
Quality bars are formulated primarily through the identification of customer needs, but also by analyzing recurring defects within a team, or teams.
In this way, the Quality Bar represents not only a checklist of clear requirements (i.e., the recipe for success), but also an opportunity for your own growth and development.
Before ever submitting a unit (e.g., bug-fix, test-case, report, or other deliverable), you should fully utilize your Quality Bar checklist to ensure your deliverable passes every quality requirement.
By doing so, the team that receives your output (i.e., as their input) is far less likely to reject the unit, eliminating rework and ensuring customer requirements are met.
Accountability is required
“Failure is only an opportunity to begin again, this time more wisely.” - Henry Ford
By any standard, 100% quality is a lofty goal.
Obviously, there will be times when your deliverable fails to meet the Quality Bar and is rejected, either by your own team, or by the team receiving your output. When this happens, a natural response is to place the blame on anyone but yourself.
For example, it’s easy to blame the Quality Assessment team who discovered your defect. However, in most cases, based on the strength of our processes, the QA team’s findings are usually correct.
But what if you fail on the same quality bar item twice? Or, even three times?
In this case, it’s obviously not enough (because you keep missing it) to simply double-check the Quality Bar prior to delivering your output. Instead, you need to reach out to your manager and ask for help.
Your manager will give you some best practices and common solutions in order to help resolve your quality issue. With their help, you may even arrive at new solutions which will help other team rooms avoid similar problems.
In rare instances when your argument against the QE team is correct, it’s usually because a particular Quality Bar item is subjective in nature and leaves room for misinterpretation. In these cases, it’s worth debating the quality bar.
Deep Dives & Root Cause Analysis
To identify the root cause of the quality bar failure, you should look at a specific unit that failed and ask ‘Why?’
It’s easy to identify the surface reason why the unit failed but this does not provide any value. The key to a good deep dive is getting all the way down to the root cause.
Once you have your first answer to ‘Why did this unit fail?’ ask ‘Why?’ Keep asking ‘Why?’ to your answers until you are at the root.
Most managers fail Deep Dives because they get stuck in abstract layers before getting to the root cause - they don’t go deep enough.
How do you know when you are deep enough? You know you are deep enough when you come up with the specific reason why that individual unit failed.
If you’re in the source code or the tactical weeds of your team's core function, you’re probably in the right spot.
When it comes to creating an action plan to fix the issue, there is not too much to say besides: apply your expertise to craft a solution that would have prevented this exact unit failure.
Debating the Quality Bars
Of course, it is possible for a quality bar to be outdated, subjective, unclear, or just plain wrong. However, if you discover a Quality Bar to be wrong, the worst thing you can do is to simply not apply it.
This would cause a major disruption to the structure and the processes all teams follow, and makes the impact analysis of change far more difficult.
This means that if you discover an outdated Quality Bar, you still have to apply it to your units. But you should reach out to your manager as soon as possible to discuss your findings, and to determine a course of action.
If, with your manager’s guidance, you determine that the Quality Bar is correct, then you’ve learned a valuable lesson, personally. However, if your findings turn out to be true, then the whole organization can learn something in the process.
Conclusion
Your goal should always be 100% for every team, and for the final output to the customer.
Perfection (100% quality) can be an intimidating goal, but it is achievable most of the time by utilizing Quality Bars. Along the way, defects are sure to occur. It’s your response to those mistakes which will determine your eventual success.
Assessment
Make sure you use your company account for taking the quiz.
Last updated
Was this helpful?