itmWEB Research

An itmWEB Classic Whitepaper

Design Reviews: Iterate to Excellence

Focus Area: Project Management for Systems Development

Author: Russ Finney

Year: 2003

Once the business design has started to gel into a complete vision of the either the new or enhanced system, several stages of review should have been conducted. Hopefully, the business clients have had the opportunity to participate and provide input throughout the screen and report prototyping sessions (which are in essence a review and enhancement exercise). In addition, each team member probably will have been through several reviews and revisions of his or her individual design assignments.

Throughout this effort, each of the analysts should be striving toward the design of a system which ultimately blends into a cohesive whole. Checks should be conducted frequently to access the level of consistency, commonalty, and standardization the team is achieving. Some suggested review points (within the total review cycle) which can assist in increasing the quality of the business design are listed below:

Initial Design Team Reviews

These give the functional design teams a chance to review their own first cuts of the screen/form and report layouts. The initial screen/form and report layouts should be individually produced from the business requirements with only a minimal amount of direction. These initial reviews give the various team members a chance to see each other's ideas and to discuss common standards and approaches. In addition, any glaring database omissions can be identified for resolution, and any existing data element changes can be requested.

Design Team Revision Meetings

During these meetings, the teams should conduct follow-up reviews of the revised screen and report layouts. Each layout should be compared to the project's common functionality and consistency standards, and any final changes should be identified. These meetings should be conducted as often as necessary, until the team feels it has produced a high enough quality product to use as a baseline in the prototyping sessions. The meetings should again provide a forum for the discussion of enhancements to the evolving database design.

Prototyping Sessions

These give the business clients the opportunity to review the baseline screen prototypes in a structured, focused setting. Additional business requirements, information omissions, new screen functionality, and operational enhancements can all be identified and put into both the system design as well as the evolving prototypes.

Cross Team Reviews

If multiple teams are working on individual sub-systems which must either work from a common database or pass information back and forth, it becomes critical that review and issue resolution meetings are scheduled on either a regular or on an as-needed basis. The existence of this open communication can't be stressed enough! If invalid assumptions about any of the other system's data requirements, functionality, or timing are not uncovered until the last minute, all of the teams share equal risk of unpleasant surprises surfacing, potentially impacting the relevance of their current design work.

Final Walk-Thrus and Approvals

When a final draft of the completed Business Design is ready, one last review with everyone (business clients as well as the design team members) is in order. This may be accomplished by making one last pass through the screens and reports, or by just determining resolutions for all of the outstanding issues and reviewing the final decisions on all of the others. Whatever method is chosen, it is important to conduct some type of activity to get everyone paging through the these final results in order to stimulate feedback and closure.

The key point to remember about this process is that it is iterative and ongoing. Different parts of the system, or even just different screens and reports may be at different points in the review cycle at any one time. This is fine as long as the overall design process is headed toward that all-important common, unified, cohesive whole!

The Issues get Intense

During the requirements gathering stage, the issues tended to be high level, and simply writing them down on a list for resolution was adequate. At this stage, however, an even greater level of discipline is required. Ths issues collected during the prototyping sessions, team review meetings, and walk-thrus must be categorized, recorded, and tracked. In many cases, these issues represent genuine requirements which can't be lost on a scrap of paper buried in someone's briefcase. Now is the time to formalize these issues into an easily maintainable database to which the whole team has access.

Listed below are some of the items which should be recorded for each individual issue:

  • Issue Number
  • Status
  • Date Recorded
  • Date Resolved
  • Classification
  • Text Description
  • Text Resolution
  • List of Responsible Team Members

Some of the types of issues which are generally recorded at this point include:

  • New Processing Requirements
  • High Level Business Issues
  • Technical Processing Considerations
  • Potential Screen/Form/Report Layout Changes
  • Potential Database Changes