User:Egclower

=Critical success factors for implementing inspections and technical reviews=

This article describes the critical success factors required for implementing an inspections or reviews process or renovating one currently in existence.

The critical success factors required for implementing inspections and reviews are :


 * Process ownership
 * Management support
 * Training

Process ownership
If we are not already using inspections and reviews or we need to improve the way we are doing them, the process needs a champion. The champion can be anybody who really is interested in it, who cares a lot about it, and who will take ownership for the process and will make it happen. It could be someone in the development organization, who knows inspections are a good thing. It could be a quality assurance person; it could be a process expert, or someone in the process engineering group. It could be a full-time job or it could be a part-time job. When companies get really big they hire people to do nothing but organize formal inspection and review processes. In smaller companies this is neither necessary nor possible. The important thing is that somebody must become the champion of the method and work in the medium and long term to gradually gain support for it.

Management support
Frequently, it is management that initiates the adoption of inspections. Whether or not they are initiating the process, it is important that managers are well briefed on inspections and their benefits. It is unreasonable to expect them to spend resources and support the effort if they don't see the long-term gains. It can be difficult for anyone with different pressures and different immediate problems to solve to understand why it's worth putting resources into these early testing efforts.

Promote support for inspections by getting out early results. If possible, collect data on the errors found by inspections or reviews at the early stages and compare this to the estimated costs if they had been allowed to migrate to the later stages. Get people who aren't so enthusiastic about these methods to a meeting to discuss problems with a particular work product, and then demonstrate with a small, live inspection how effective inspections are in their own organization and on their own material. Show them it's possible to monitor the cost effectiveness of the new process.

Training
Training in reviews and inspections is crucial, including specific training for practitioners on how to perform reviews and inspections, including costs, benefits, and dealing with the human and cultural issues. Training should also include performing inspections in a workshop setting of real work products from the local environment. Everyone who is going to be inspecting documents should be trained. Where this is not possible, an experienced team with a good grasp of the human issues involved can absorb a new member.

Recommendations
Inspections are recommended first and foremost because they have proven to be effective. Inspections are probably the oldest methodology in the history of software development. They have been used successfully for at least 25 years. So while inspection techniques have evolved over this time, you won't be suggesting untried leading edge methods when you suggest implementing inspections in your organization. They work. Getting the right people in a room to look at the right material in a systematic, objective way is simply common sense and good basic communication.

Most testing organizations experience "The Chaos Zone" when they only do functional testing or system testing. At that point, all of the code, of which testing has little or no prior knowledge, is thrown into the testing department. All kinds of defects are found through hasty testing in unfamiliar territory. Shipment dates are missed and pressure is created because testers are operating in an unfamiliar environment where there should be an opportunity to get acquainted with the product and find many defects a lot earlier.

Get started by inspecting some key material. Typically, an organization will have all kinds of projects all at different stages. Some projects may be so far along that it doesn't make sense to implement inspections and reviews on them.

It is usually better not to go for a "big bang" approach and implement formal inspections on all documentation from a certain point in time. It's best to pick some high-risk material with a high pay-off on a number of different projects first. Perhaps start by reviewing all new requirement specifications or all new and changed code on critical projects. Build support while measuring and tracking enthusiasm from peers. Then do inspections on a wider range of documentation and demonstrate the results.