March 06, 2019
The Business Case for the Chief Quality Officer
Share This Post
republished from LinkedIn, originally posted here: https://www.linkedin.com/pulse/business-case-chief-quality-officer-damon-young/
During his interactions with the Soviet Union, Ronald Reagan popularized an old Russian proverb "
Of course, when the stakes are mutually assured destruction on a planetary scale, no one questions the need to run a test to verify that the results of our collective assumptions are true. But, in the business world, results can be just as catastrophic when the key assumptions of major programs are not tested and proven at every stage. My experience is primarily in the realm of software, so I'll focus this there. But, I also believe Marc Andressen's mantra that software is "eating the world". That means that if your business is increasingly dependent on technology for its daily operations and market differentiation, a large scale project that has not undergone proper quality assurance is the equivalent of a loose nuke at large in your corporate countryside. Catastrophic IT project failures can result in wholesale customer abandonment, brand devastation and direct revenue impact, all of which can come back to haunt a chief executive when he or she is forced to announce that they'll miss their numbers during an earnings call.
Now, when most speak of quality within the context of software and IT, they think in terms of the team of testers who're brought in at the end of the development process to ensure the resulting project performs to specifications. Unfortunately, if the scope of quality assurance is limited to the software development life cycle, you're often missing the opportunity to add the most value. Far too often, those specifications that act as the guidelines for this intrepid QA team have been created by the engineering team itself, based on its interpretation of the requirements received. In essence, QA becomes the stamp of approval from engineering to validate that it has done its own job.
What's often missing is the application of QA principles to the larger business context of the project itself. For instance, would the software QA team or anyone in engineering have the capacity to determine that the investment of time and resources the company has made in this particular project is worth the expected business value the company expects to gain from it? Would they have the capacity to apply those same business specifications to determine the ongoing success and value of the project once launched?
In a pure software company, this responsibility would fall into the realm of product management, but, as more corporations bet more of their business on software, they historically do not have the roles and organizations defined to provide this kind of oversight. For a small business, adding these elements to a corporate structure would seem to be very straight forward. But for a large enterprise, where the budget for a single project in a larger IT portfolio could start in the hundreds of millions of dollars before overruns, the path is less clear.
In examining the standard executive roles, there are reasons why many of the traditional candidates like the CTO, CIO, COO, or even CFO may have conflicting concerns when it comes to ensuring the business quality of both internal and public-facing software projects. While the CEO bears the ultimate responsibility, the potential risk to the business balance sheet of these investments should warrant someone accountable full time at the executive level who both understands the technology enough to support IT's efforts while still possessing the firm grasp of the business case and the underlying numbers to ensure that the project is proceeding in the overall best interest of the company.
"Trust, but verify" can't just be a mantra of the troops on the ground, but it must have a dedicated voice in the C-suite as well to better ensure success.
Share This Post