This column is the fifth installment in a walk-through of the five fundamental phases of a project plan to build a meta data repository: orientation, feasibility, design, construction and rollout. The focus this month is the construction phase.

When the design phase is complete and the detailed design documents are approved and signed, it is time to begin constructing the back-end programs that will populate the meta data repository and the front-end programs that will present this information to the end users. The construction phase is a classic programming phase. During this phase, the project manager must ensure that the developers adhere to the repository implementation schedule. On the other hand, the repository architect will work with the developers to ensure all of the programs built are maintainable and run efficiently. Figure 1 summarizes the major endeavors in the construction phase.

User Acceptance Testing

The purpose of user acceptance testing is to gain end-user approval for the meta data repository. During this activity, it is important to conduct training for the end users immediately preceding user acceptance testing. The purpose of this training is to ensure that the end users understand the meta data repository and know how to use it. It is critical to not skip or gloss over this step. Always remember that the users make or break the project.

Task ID Task Name Duration Dependency
4 Construction Phase 77 days
4.1 Physically Implement Meta Model 10 days 3.3
4.2 Design Meta Data Security Process 6 days 3.3
4.3 Develop Meta Data Integration Processes 12 days 3, 3.4, 4.5.3
4.4 Develop Meta Data Reports/Access Method 10 days 3, 3.4, 4.5.3
4.5 Meta Data Infrastracture 9 days 4.1
4.6 User Acceptance Testing (UAT) 11 days 4.3, 4.4
4.6.1 Business User Training 6 days
4.6.2 Technical User Training 6 days
4.6.3 Conduct User Acceptance Testing 5 days 4.6.1, 4.6.2

Figure 1: Construction Phase Tasks

Management and User Support

At one time, I was part of a team hired to implement a new, enterprise-wide, order entry system for a large, global conglomerate with multiple, wholly owned subsidiaries throughout the United States. The implementation team spent two years building the system, which we planned to roll out initially to one of the conglomerate's smaller U.S. companies (we'll call it Subsidiary A). Subsidiary A was relatively large, with annual revenues of approximately $1 billion, but its management and end users were reluctant to institute any change and viewed the new system as a threat to their jobs. Management and users joined forces to oppose the implementation effort and eventually convinced the conglomerate not to implement the system. This decision was highly unfortunate because the system was designed to help Subsidiary A overcome one of its major problems ­ a lack of customer service. Features such as automated product pricing would have helped to compensate for this shortcoming and increased Subsidiary A's revenues.

The order entry system was designed to calculate price when the clerk keyed in the customer, product code and quantity. Although this sounds pretty basic, it was a significant improvement over the way Subsidiary A was providing price quotes to its customers and would have saved considerable time and effort on the part of the users as well as increased the reliability of the quotes.

Having failed in our implementation effort at Subsidiary A, the team moved on to Subsidiary B, the largest of the conglomerate's U.S. companies with annual revenues of approximately $7 billion. A month before we began rolling out the system at Subsidiary B, the conglomerate initiated a major reorganization of all its U.S. holdings.

Unfortunately, this had a large negative impact on our system and its internal hierarchies. We experienced a large number of problems during user acceptance testing. Fortunately for us, the end users at Subsidiary B were absolutely the best I have ever worked with. They spent little to no time looking to assign blame. Instead, they stayed focused on the problem and worked as a true partner. The result was a highly successful systems implementation for Subsidiary B. Sadly, Subsidiary A never implemented the new system and because they were experiencing poor financial performance they had to undergo major employee layoffs. I firmly believe that if they would have been more amenable to change those layoffs may have been avoidable.

Remember, the success of the repository implementation project depends as heavily on user support as it does on the technical design and construction of the system. In all cases, the repository project manager needs to work closely with the business users before and during acceptance testing. Implementation team members need to keep their fingers on the pulse of the users and their ears to the ground to understand how well the repository is satisfying the users' needs and how the users are perceiving the system's success.

Next month, I will conclude this project planning series with a walk-through of the rollout phase.

Note: This column is adapted from my book "Building and Managing the Meta Data Repository." 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

Don't have an account? Register for Free Unlimited Access