Meta Data Repository Project Plan: The Construction Phase

By David Marco

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. This month we will complete the Construction phase.

Table 1: Construction Phase Tasks

Construction Phase

After the design phase is complete, and the detailed design documents are approved and signed off, 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 that all of the programs which are built, are maintainable and run efficiently. Table 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 right before the beginning of user acceptance testing. The purpose of this training is to make sure 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 and break the project.

Management and User Support is Critical to Success

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 initially roll out to one of the conglomerate’s smaller U.S. companies (we’ll call it subsidiary A for convenience). Subsidiary A was relatively large, with annual revenues of about $1 billion, but it’s 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 it’s 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 increasing 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 about $7 billion. A month before we began rolling the system out at subsidiary B, the conglomerate initiated a major reorganization of all it’s U.S. holdings.

Unfortunately this had a large negative impact on our system and its internal hierarchies so we experienced a large number of problems during user acceptance testing. Fortunately for us the end users for 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 for Subsidiary A, they never implemented the new system and since 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.

I will be concluding this project planning series next month as we go through the Rollout phase.

Free Expert Consultation