So often quality on an IT project is thought of in technical or process terms. While Agile attempts to improve upon quality issues early through an iterative collaboration between technical and end-users, other system development methods are less likely to have this built-in process.
I recall a project for which I was the quality assurance manager. One of the IT development teams gathered the end-user requirements for a particular functional area. With visions of the solution already dancing in their heads, and assuming they could “steal” a working design from another functional area, they assured the end-users on the business team that they completely understood the functional requirements. Despite their many explanations and confident assurances, however, the business team had a profound sense of unease.
The IT provider was using a traditional waterfall development methodology; therefore, their lack of understanding of the functional area was not uncovered until months later during the User Acceptance Testing process. Their modeling of the functionality for this business area based on the design of another functional area proved to be severely flawed. At the same time, they had never tested their assumptions against what the end-users had described to them.
Here’s the embarrassing part. The IT provider’s quality standards for developing specifications were very loose. In fact, the requirements were written in English narrative, using an inexact format that left much room for interpretation. Although the narrative appeared to be correct on paper, it did not specify the many subtleties that the functionality needed for a complete and accurate implementation.
The end result
Rewriting the requirements using a more exacting structured English format, rework of the entire system design, redesign of the underlying database structure, weeks of lost productivity, and a business team that never regained its confidence in the IT provider team. Not to mention time lost on the project, lost profitability and program code delivered in a rush with many, many defects.
Contrast that with a similar project where the Quality Management Plan called for requirements walkthroughs with the end-user Subject Matter Experts (SMEs) immediately after the requirements definition workshops were completed, and before the final requirements documents were submitted for formal review and approval.
The Quality Management Plan then took it one step further. As the IT design team developed the system design specifications from the approved requirements, they brought the SMEs into the design process alongside the technical staff. Although design is typically a technical activity, the design team tested their understanding of the requirements by walking the SMEs through significant design decisions, both from an accuracy and a usability perspective.
A different end result
Fewer defects, an acceptable number of change requests, on-time implementation and satisfied users. Quality was planned into the process up front, budgeted for, then implemented according to the plan.
Regardless of the system development methodology employed, having a Quality Management Plan from the beginning helps produce more successful projects with better end-user results.
Get Your Free Guidebook
Subscribe and receive your free guidebook,
5 Ways to Master the Art of Managing People, Projects and Profits.