Making parallels between corporate IT work products and those of other fields is adventurous. Nevertheless, I need to find a way to explain what quality control means for corporate IT without getting technical.
Imagine for a moment that your corporate IT team was not delivering technology solutions to your business, but rather automobiles. Also assume, for the sake of the parallel, that your usual corporate IT quality controls would be applied to these cars.
The car would be put on a tarmac track and a test driver would start the car, accelerate, turn right, turn left, and brake. She would also open all doors and windows, check the fuel gauge, engage the lights, turn on the radio, open windows, tilt seats – everything. In short, all features would be tested for their practical effectiveness. The car would then be handed off to its owner. That’s it.
Are you tempted to say that it’s enough? If all features and functions are operational, then the quality is where it should be? Of course not.
Fortunately for car makers and owners, some important points are missing from the quality control plan I’ve outlined above; especially determining how well the car is built and assess its ability to handle sustained use over a period of time – long after its sale to a customer. In the automotive industry, these procedures will address a world of additional concerns such as: will the car be plagued with rust holes in 12 months? Will the brakes require changing every 1000 miles? Will the corner garage mechanic need to drill a hole in the engine pan to make an oil change?
Carmakers have understood long ago that features are not enough if the product does not show many other qualities like longevity, safety, maintainability or reliability. But corporate IT is a strange beast whose behaviors often defy common sense.
So strange that the IT equivalent of drilling a hole in the oil pan is not that farfetched.
Project-Oriented IT and Quality Control
The scope of quality control on technology solutions can be qualified as business requirements centric. Far be it from me to downplay the extent of the tests required to ensure that all requirements are fulfilled, but that’s far from enough. The resulting output can only suffer from inferior levels of excellence when certain areas aren’t duly inspected. It’s true for cars and applies universally to any situation where there’s a mix of human beings and tight schedules.
How simple will it be to expand the solution? How much effort will it take to retire that solution? Will future generations of IT staff have crystal clear technical documentation at their finger tips? Can this solution easily integrate with other systems or technologies? These questions cannot be answered by controlling the correctness of features and functions.
To understand the dynamics responsible for deficient quality control of corporate IT output, one must first recognize that any change to existing assets or new asset creations are made within the context of a project. This makes sense, since nobody wants multi-million endeavors governed by anything less than good project management practices.
The issue doesn’t lie with the use of project management wisdom. The problem is that corporate IT decision-making processes are heavily skewed toward the use of project management logic, even in cases where different rationales should be applied. I call this ubiquitous pattern Project-Oriented IT.
Remember that a project is, by definition, a temporary endeavor; it must have a start date and an end date, or else it’s not a project. This also means that anything happening before the project start or after its finish will not be considered part of the project.
So, within our carmaker analogy, the project end date will be when the automobile is delivered to the customer with all promised features functional. An IT project will be deemed complete when the solution and all of its components are successfully tested to make sure that every feature works properly.
These tests do not acknowledge issues that may (or may not) arise months or years later. A few moons after the IT solution is delivered, the project will have been closed for a long time. Long-term quality does not fit easily into a project. In project-oriented IT, considerations equivalent of car maintenance costs, body rust, or the premature wearing of parts are rarely a concern.
QA Skills and Independence
“Aren’t corporate IT quality control processes intended to check all these things?” You might be tempted to ask. The sad but true answer is: not really. For all aspects of quality to be checked systematically and consistently, there needs to be a certain degree of separation between those that build quality and those that control its presence. In most cases, the independent quality controls cover only business features and are being carried out by the only unconnected parties in the equation: non-IT folks working for the business sponsor.
These individuals will conduct checks according to their skill sets, which don’t include the technical knowledge required for looking under the hood. Those that have the skills to inspect the engine and the cabling are probably busy welding another car (working on another project). Even when the internals of the solution are checked, the reviewers are rarely independent enough because they are working under the auspices of project-oriented IT where many quality concerns are of a lesser importance.
In an upcoming article, I show that conflicting roles lead stakeholders to quickly pushback against any quality criterion that doesn’t directly help a project within its immediate lifecycle. You will also discover that these same accountability issues are killing the independence required to perform quality controls covering all aspects of the value of what is delivered.
Your takeaway from this article is simple: when it comes to controlling the quality of what you get from your IT investment, you hardly get anything better than a test drive.
To change this, the distribution of measured accountabilities must change in such a way that all aspects of quality are evaluated, not just those that directly impact a project’s delivery. In this book, I dive in all aspects of IT that impede the creation of quality assets, all of them being rooted in the roles distribution, the accountability given to these roles, and the associated measures of performance.