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
