Quality in-house
Software quality isn’t a process or a department, it’s a job requirement for everyone in IT
NO MATTER WHAT your job title is, if you’re involved in IT, you are responsible for software quality. Your right to complain about unstable, insecure, underperforming, inefficient, or inaccessible programs correlates with your willingness to get involved in tracking and fixing software problems.
Software quality is one of IT’s more-passed bucks. If your organization doesn’t engage in large, in-house development projects, you might lack quality policies and practices. Commercial and open-source software is rarely subject to specification, much less validation. Companies that outsource development to contractors or consultants may check software against specs, but then take quality for granted or let outsourcers define their own quality metrics.
An effective software quality strategy uses technology to support accountability, persistence, and pervasive involvement. Accountability requires individual ownership of each reported problem and missed metric. Any open issue that is said to be “on a list” or “in the system” is likely to be ignored because it’s no one person’s job to follow the problem to resolution.
Flawed quality strategies have accountability gaps, black holes in which open issues languish until some clean-up person calls the problem-reporter, usually some weeks after the original report. The clean-up person’s job is to convince the reporter that the issue doesn’t matter anymore. To me, just having someone in this role is a symptom of a busted quality strategy.
Persistence means sticking with a problem until it’s resolved to the satisfaction of the reporter or a responsible, accountable individual. Except for the initial triage call, contact with the reporter should be limited to purposeful calls from people close to the problem. Invest in tools that let the reporter or customer check issue status online.
Of course, not every report is valid. Suspicious reports should be investigated and disposed of. It’s better to level with a time-waster than to coddle him or her, even if honesty imposes real or political costs. The quality system can’t be a back channel for people who want to bypass technical support. It’s reasonable to resolve a bogus report by transferring it to support, the help desk, or customer relations — just make sure the reporter knows what’s happening and why.
Pervasive involvement engages everyone in quality; no one should be exempt from participation. Opting out of the quality system used to be a perk for senior developers and technical managers, and those involved in design and architecture rarely became involved. A supporting myth was spun that people in higher salary classes are too expensive to waste on problem resolution.
Writing your smartest people out of the quality chain greatly increases costs and makes lasting resolutions less likely. Organizations should erase the stigma associated with quality efforts by educating participants about the value of software quality and the costs associated with the lack of it.
