In-Depth
Improving Quality without Six Sigma
Here's one low-cost technique that's easily implemented and can substantially improve the quality of both systems and services.
While Six Sigma is a fine program for improving quality in your organization, it requires a large commitment in time and resources. Not everyone is willing to make such a large up-front commitment. This doesn't mean that your IT department must abandon any attempt to improve quality. Peer review is a quality-improvement technique that is easily implemented, has minimal costs, and can substantially improve the quality of both systems and services.
Peer reviews work on the principles that multiple sets of eyes are better then one, and that the earlier an error is found in the development process the cheaper it is to fix. A peer review is the review of a piece of work (design document, process flow, business procedure, etc.) by a peer group. The key here is "peer"—management is excluded from the proceedings to prevent the review from being perceived as a performance appraisal.
The peer review group includes a presenter—this person is not the originator of the work. The presenter introduces and explains the work to the group; this separates the originator’s personality from the work and from the review.
The group should include at least two, but not more than four, reviewers in addition to the originator and presenter. Too large a review group and you'll experience the laws of diminishing returns.
The purpose of the review is to suggest ways the work can be improved. The results of the review do not have to be shared with management but can be reviewed with management if changes must be prioritized or if the group cannot reach a consensus.
Preparing for the review requires the originator to document his work and review it with the presenter. This first step has two benefits. First, the originator is forced to document his work, for without a document to review there can be no peer review. The act of putting thoughts on paper can help the originator identify errors. Second, the originator is forced to explain the work to someone else (the presenter). This step requires the originator verify that the document makes sense to someone else.
The presenter then is the spokesperson for the work to the review group. The review group suggests areas where the work can be improved. The review process comes with a side benefit: a greater understanding in the organization about what each group is doing. To maximize this effect, pull members of your review group from as broad an audience as possible.
This may appear counter-intuitive. After all, don’t you want your experts in the field to review the work? No, you don't. Your field expert is most likely the originator; the point of a peer review is to explain what you are doing to someone from “out side the box.” Expanding your review group offers different perspectives on the work under review and can prevent “group think.”
Keeping It Small, Keeping It Positive
Having one's work reviewed can be stressful, particularly when the originator is heavily invested in the project. To mitigate some of that stress, peer review sessions are scheduled along "inch pebbles" instead of milestones. An inch pebble is a smaller, more manageable piece of work. In keeping with that focus, a peer review should only take half an hour so the amount of work presented should be consistent with a half hour review. The idea here is that the smaller the amount of work under review, the less vested the originator is in the work and the more open he/she will be to the suggestions of the review group.
The concept of inch pebbles also ties back into the idea of finding flaws early. More-frequent reviews ensure that problems are corrected as early as possible and at the lowest possible cost.
Still, peer reviews can devolve into faultfinding missions. To keep a positive atmosphere, management must continue to reinforce the fact that peer reviews are not about assigning blame but about improving product and process. To that end, sometimes the best approach is to have an outsider conduct the initial peer-review training.
Peer reviews do not have to be limited to large projects. For example, for quick program fixes, I implemented a “second set of eyes” rule. Under this rule, no changes could be turned over to production without the originator explaining the change to a peer and having that peer sign off on the change.
This process did several things. First, it ensured that the originator had thought through the change sufficiently to explain it to someone else. Sometimes just the act of having to explain something to someone else can reveal a flaw. Second, it provided the originator with a different point of view on the problem and solution. Third, it ensured that a second person knew what was being done. If the change created a problem in production and the originator was not available, there was at least one other person who knew what had been done and why.
This “second set of eyes rule” greatly reduced follow-on problems from program fixes. Of course, the point of peer reviews is to eliminate problems before they reach production, and as the group used the peer review process, we also noticed a marked reduction in production problems.
The simple framework of peer reviews can have a substantial effect on a department’s quality with out having to implement a full Six Sigma program. If you look at quality improvement as a journey, implementing peer reviews can be a first step. Once you have realized some success with peer reviews, it should become easer to sell the organization on a larger quality program such as Six Sigma.
About the Author
Vincent J. Ferravanti (www.ferravanti.com) is an Information Technology Executive with global experience, aligning IT departments to creating competitive advantages.