risk mitigation

It’s the sordid little secret of many IT development organizations: With tight schedules, tighter budgets, and projects increasing both in scope and complexity, the deadline too often becomes the all-important goal. From the boardroom executives on down to the line managers in the development cubicles, little if any forethought is being given to project quality. The mission is clear: Get to the market first and fast. Fix it later. Catch the bugs in testing after the coding is mostly done.

“We’re too busy for process improvement” is a frequent refrain. Occasionally, well-meaning management might resort to a slogan like “Quality Is Job One.” The reality, though, is that quality becomes Job 1.1.

Not only is management lacking insight into the process, in the trenches, at the developer level, there is no clear focus on quality assurance. Certainly testing may be carried out, usually at the end of the development work, but testing does nothing to ensure quality of the software product.

Disturbing study results and statistics supporting my observations abound. The central problem is apparent that all too often, according to Carnegie Mellon University’s Software Engineering Institute, software gets delivered on time by way of overtime and individual heroics. While defined processes may well exist, when faced with a tight deadline or when any sort of crisis evolves, even ambiguity, those processes often are forgotten or foregone under the weight of the overwhelming pressure to deliver on that all-important deadline.

When teaching and mentoring clients on how to improve their development process, I shift a large extent of the focus from the development processes to the quality processes. Whether a shop is using a traditional waterfall development process or “extreme” or “agile” development approaches is largely irrelevant, both at the theoretical and at the hands-on practical levels. A core practice of quality assurance is examining and analyzing the entire process of how a product is conceived, defined, built, and delivered to the customer. Again, the development life cycle in use is not a key factor. Quality assurance practices can be built into any development approach. Quality assurance practices must be matched carefully to your organization’s approach, regardless of any formal framework, be it CMMI, Six Sigma, best practice analysis, and so on. The approach that I teach and mentor clients in utilizing is what I call identifying and exploiting “Quality Checkpoints.”