Meta Data Repository Project Plan: The Design Phase, Part 2 of 2

By David Marco

This column is the fourth installment in a walk through of the key tasks in each of the five fundamental phases of a project plan to build a meta data repository: Orientation, Feasibility, Design, Construction, and Rollout. In last month’s column (March, 2001) we walked through Tasks 3.1 and 3.2 (see Table 1) of the Design phase for a meta data repository project. This month we will complete the Design phase.

Table 1: Design Phase Tasks

Design Phase

Create Detailed Design Documents

The back-end program specifications, and the repository’s front-end report specifications are also constructed during the Design phase. While the process for capturing detailed designs has been around for a long time and is well understood, I want to share a couple of techniques to reduce the likelihood of extending this process longer than necessary and for avoiding scope creep. Always bring a copy of the project scope document to each design session with the end users to ensure that all design work relates directly to the business and technical drivers listed in the project scope document.

When the design documents are complete, obtain signature approval from the end-users who have attended the design sessions. All too often, users suffer from “analysis paralysis” during the design sessions as they are unwilling or unable to commit to firm requirements that are necessary for good design. Try to overcome their reluctance to make hard decisions by citing executive level support and through judicious scheduling. On occasion I get a group of users that have a particularly difficult time in making decisions. When this problem becomes so severe that it is likely to impact the project’s timelines I use my “wear them out” technique.

The “Wear Them Out” Technique

All too often when users get together to define the specific system requirements many of them do not want to make decisions and “analysis paralysis” occurs. After spending too many hours in unproductive design meetings where the users were unable to reach decisions regarding their reporting requirements I developed this “wear them out” approach (for lack of a better name) for breaking down these barriers. I remember a particular client whose end users were extremely reluctant to make decisions and wasted a great deal of time just talking endlessly about the business during our detailed design meetings rather than discussing and making decision about their requirements. After leading numerous, lengthy meetings (i.e., three to four hours each) with less than favorable results, I instituted the “wear them out” technique for capturing their requirements.

When I resort to this approach, I schedule a design meeting to begin in the afternoon, usually about 1:00 PM or later, and make sure that all attendees understand that the goal of the meeting is to capture all of the end user reporting requirements. I also inform all attendees, up front, that the meeting won’t end until all of the requirements are captured. My standard warning is that if I’m the only one left in the room at 3:00 AM making decisions, then that’s how the decisions will be made. Well this meeting began like all of the others. There were petty discussions and great deal of talk about business processes, but no decisions about requirements. At 5:00pm we had accomplished absolutely nothing, which is right according to schedule. At 5:00pm dinner arrives (no reason to starve anyone to death) and the attendees begin to realize that I am absolutely serious that this meeting will not end until we have defined our requirements. By 6:00 PM, an amazing metamorphosis occurs; people stop arguing and begin to make decision on their requirements. In the next two or three hours, we can generally reach consensus regarding the user reporting requirements and make the design decisions. Usually by 10:00 PM, the meeting is concluded, all of the requirements are defined, and as a good warden I finally let my prisoners free to see their families. This technique has served me well and I’ve used many times over the years with wonderful results.

Create Detailed Data Delivery Specifications

The detailed data delivery specifications document all of the particular, field-level needs of the repository’s users. These specifications are then given to the data delivery developers to build the actual report/query programs. Most of us have a great deal of experience in constructing detailed data delivery specifications. The major sections of these specifications are:

  • Defining Input Tables/Files Layouts
  • Defining Output Tables/Files Layouts
  • Detailed Processing Summary
  • Report Prototypes
  • Issues

Prepare Training Plan for Development Staff

If the meta data repository is going to use data access or integration tools, the development staff is likely to need at least two weeks of intensive training on the tool(s) before they can use them effectively. And, a word of warning: if the tool vendor tells you that they have a three-day boot camp style course that teaches the developers everything they need to know, don’t believe it! I’ve attended many of these courses and every one of them was more like summer camp than boot camp. The vendor should, however, be willing to create a really useful course for your developers. Just be sure that the course instructor is an on-site implementer with real “hands-on experience, rather than a full-time trainer who is familiar with the tool, but knows little or nothing about your particular repository project. Full-time trainers often lack the necessary expertise to make the tools function effectively in a real-world situation.

Tune in next month, as I will be walking through the Construction phase.

 
Free Expert Consultation