A bad, bad, bad project. (Training).

HYPOTHETICAL MORTGAGE COMPANY (HMC) was a major player with a 25-year history of growth and profitability Out of the company's January executive meeting emerged an idea: Overlay the existing computer systems with a blanket system that would allow production, operations and servicing to view each other's data. This would allow information to flow seamlessly and quickly among the divisions. Also, it would allow data mining by marketing, secondary marketing and advertising, creating millions of dollars in opportunities by enabling faster creation times for new products, better fit of products to market segments, better profiling of customers, better customer retention and huge cross-selling opportunities.

In February, a task force was formed to implement this idea. The task force represented all areas impacted by the project--37 people. The task force was headed by a project manager hired specifically for the job. Since it was patently impossible to free all 37 people for regular meetings at the same time, task force members selected alternates, and much of the communication was handled by keeping and distributing minutes from the meetings. At the first task force meeting, subcommittees were formed to create a project timeline, estimate costs and benefits, and begin vendor selection.

By the end of April, a timeline of eight months to implementation had been submitted to top management, along with a cost estimate of $300,000 and a five-year-out estimate of $2.2 million in benefits. Eight potential vendors had been identified. Top management gave the project a final go-ahead.

Vendor interviews and demonstrations were held throughout August and a contract was signed in September. Vendor costs were higher than anticipated, because it was discovered that some retail branches were taking applications on a nonstandard system that they had been using before HMC acquired them. Also, there were legal and compliance issues with the vendor's system accessing data from HMC's automated underwriting system suppliers and credit-reporting suppliers. This delayed the vendor from beginning "real" programming work until February.

In April, a disaster occurred. The servicing division received its annual, automatic upgrade from the servicing system vendor. When this upgrade was loaded, it wiped out random chunks of the new vendor's programming. Accusations flew. A month was lost rebuilding the program. At this point the budget was exceeded.

During this period some difficult, new questions were raised:

* What happens when the next servicing upgrade is loaded?

* What happens if we change or upgrade our production system?

* Will this blanket system also "read" data on the system used by the wholesale division, which is different from the retail system?

* In a parallel project, the postclosing, file audit and compliance departments had been working on a new imaging system. Would this new imaging system be compatible with the blanket system?

Evaluation of these and similar questions took until July. In brief, it was decided to build a "mirror system" of all the company's systems to test upgrades on, and exclude the wholesale, imaging, human resources and loan officer customer database systems from the blanket. These decisions reduced the scope of the project drastically, and raised the question of whether the proposed benefits would now be obtained. Creating the mirror system exceeded the storage capacity of the company's computer, and required a new "box."

The project was now far past its deadline, and far over budget. Programming slogged on. In September, system testing and departmental pilots began. A training vendor was brought on board. This was not a budgeted expense, but turned out to be necessary.

The testing and pilot use of the system turned up only the usual, minor bugs. The project was ready for full-scale user training and implementation in December.

Training was delayed until January to accommodate the holidays, and was scheduled to be completed in March. It actually ran through April to include make-up sessions and some new branches acquired by HMC. Training turned up a number of system enhancements that could be made fairly simply The enhancements were studied quickly and programmed "on the fly." This caused some serious problems, because the system was brought down whenever programming was in process--which conflicted with the training schedule. Also, the training material became incorrect with each system modification. Nevertheless, almost all users were trained and the system was pronounced complete in May.

Two problems immediately became apparent.

The first problem was that no provision had been made to train new users after the initial rollout. An extended contract with the training vendor had to be negotiated, and new users (particularly branch managers) had to be flown to a central location for training periodically. This was a significant expense, and a rather sore subject after so many prior cost overruns.

The second problem was much worse. Usage of the system was a fraction of what it had been estimated to be. The system was stable, the training had been reasonably thorough and user support was available, but still usage remained extremely poor--especially among branch managers, who were supposed to be using the new capability to profile their market, assess product success and needs, and analyze their current and future customers.

What happened? Were the nightmarish difficulties with this project avoidable? I suggest that they were not entirely avoidable, but that there were some telltale red flags along the way that could have cued management to question the project--or at least expect it to run about the way that it did.

The following is a quick rundown of the red flags. (Readers may have others, too, from their own experience.)

* A project requiring a team of 37 people is suspect. It is very difficult for a group this large to communicate accurately or move effectively.

* A project requiring integration of incompatible, embedded systems is scary.

* The benefits were nebulous, difficult to quantify and far in the future.

* Effective implementation of the system required that it be used by a large number of managers who did not have to use the system to perform the core functions of their job.

* The timeline and costs were suspiciously optimistic. Admittedly, this is more easily seen in hindsight.

* Vendor usage expanded to include subvendors as the project progressed, and vendor responsibilities were not fully clarified.

[Note: Test readers of this column have tried to identify the company and project I describe here. However, the situation presented is not any single project, nor is it drawn from a particular company. It is an amalgam of multiple projects from multiple companies.]

Andrew Hubbard is national training director for Irwin Mortgage Corporation in Indianapolis. He can be reached at [e-mail].