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 we walked through Tasks 3.1 and 3.2 of the design phase for a meta data repository project. This month we will complete the design phase (see Figure 1).
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 to avoid 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.
Figure 1: Design Phase Tasks
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 a "wear them out" approach (for lack of a better name) for breaking down the 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.
The procedure for instituting this technique is pretty basic. I schedule a design meeting to begin in the afternoon, about 1:00 p.m., 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 that the meeting will not end until all of the requirements are captured. My warning is that if I'm the only one left in the room at 3:00 a.m. making decisions, then that's how the decisions will be made.
The meeting usually begins like all of the others. There are petty discussions and great deal of talk about business processes, but no decisions about requirements. At 5:00 p.m., we have accomplished absolutely nothing. Dinner arrives (no reason to starve anyone to death), and the attendees begin to realize that I am absolutely serious that the meeting will not end until we have defined our requirements. By 6:00 p.m., an amazing metamorphosis occurs; people stop arguing and begin to make decisions 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 p.m., the meeting is concluded, all of the requirements are defined and, as a good warden, I finally set my prisoners free to see their families. This technique has served me well, and I've used it 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 and 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. 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.
Next month I will be walking through the construction phase.
Note: This column is adapted from my book, Building and Managing the Meta Data Repository (Wiley, 2000). The complete project plan is available on the accompanying CD- ROM.
Register or login for access to this item and much more
All Information Management content is archived after seven days.
Community members receive:
- All recent and archived articles
- Conference offers and updates
- A full menu of enewsletter options
- Web seminars, white papers, ebooks
Already have an account? Log In
Don't have an account? Register for Free Unlimited Access