3.4 The Development Review

At this point in Phase 3, IT has created the project; now it s time to review the project. This is another stage that companies frequently overlook. The same IT developers who assisted in the design review should be asked back to the development review. The purpose of the development review is to assure the solution meets the design specifications identified earlier and meets the quality requirements of the company. This includes documentation and assurance that the development was not obtained illegally (unlicensed software) or uses software the company is not prepared to support (freeware or copyleft software). There are horror stories of projects being developed, tested , and released, and then the company is sued because of questions regarding ownership of a particular application. Make sure you know up front who owns the software you are using, and what the legal constraints are on this software. Many times changes are made in development due to the realities of developing applications, availability of hardware, or needs of the market. At the development review, IT should identify the changes along with an annotation detailing the change. For example, a higher-speed connection will be included in all PCs being deployed due to availability and a drop in costs.

Development reviews are similar to design reviews in that guidelines need to be developed in order to have a successful development review. Most developers are as threatened by development reviews as they are by design reviews. IT developers may have spent a year developing a project. They resent an outsider reviewing what they have done. Don t let this resistance stop the company from reviewing the project. Don t let an IT developer s status cause you to wave this requirement. Senior developers can also overlook things. To make development reviews a positive experience consider the following recommendations:

1. Apply development reviews to everyone. Singling out certain developers or a particular IT group creates bad feelings.

2. Provide the developers with a list of what will be looked for up front. This helps the developers on the review panel and the IT developers being reviewed.

3. Review with the developers and the review panel the purpose of this review.

4. Give developers time to make corrections after the development review. Don t schedule the development review the day before the phase review.

5. Provide a neutral facilitator.

6. Make this an enjoyable process. A developer can show his or her seniority by coming in with a nicely executed project.

3.4 in a Nutshell

The development review is similar to a design review. It is a meeting where the project is reviewed to assure it:

• Meets the guidelines identified in the PRD

• Meets corporate guidelines