This is a true story. The company names
have been changed.
The schedule
Acme Corporation, a European
manufacturer, was implementing a new billing and accounts receivable system. Acme
engaged their implementation partner, Standard Consulting, to develop the data conversion
programs.
Acme’s legacy billing and accounts
receivable system was more than twenty years old. It was running on hardware
and an operating system that were no longer sold. In addition, it was custom
software, developed by a person who was no longer available to support it or
explain how it worked.
The client team made high-level
decisions about what data they needed converted to their new system to support
internal and external reporting, as well as long-term billing needs. They wrote
these requirements in a strategy document, which they gave to the Standard
Consulting project manager.
Standard’s project manager assigned a
technical team lead to review the strategy document, and prepare a schedule and
cost estimate. Standard’s project manager was satisfied with the schedule and
cost, and so was Acme. The data conversion programs were to be ready for
testing by the client team in five weeks.
Falling behind schedule
After three weeks, the data conversion budget
was half used. This was about as expected. However, the technical team leader
had not submitted her status reports, and when pressed, provided only vague
verbal reassurances that everything was under control. She seemed unclear on
how she would know that her development team was finished.
Although there were several components
required to convert the billing and receivables data, there were no components
ready to test by the five-week deadline. Again, the technical lead was vague
and assured the project manager that the programs were progressing.
After about seven weeks, programs were
ready for testing, and the client lead was asked to review the sample data in
the new system. The client lead was shocked. This data wasn’t even close to
what was required. There were significant differences between what was stated
in the high-level requirements document and what had been developed. In
addition, there were several components that had not been built at all.
The technical team lead was disappointed,
as she had developed a perfectly elegant solution to the technical challenge of
extracting data from the legacy system, and the client was not appropriately
appreciative of the effort or outcome.
Getting the programs corrected for go-live
The Standard Consulting project manager
added a business analyst to the technical team. He was to review the design of
the conversion programs compared to the requirements, and determine what
re-work and new development was required. However, there were no detailed
design documents to review, only the original high-level strategy document. The business analyst assessed each
component by developing the detailed design, working with the technical lead
and billing lead to solve discrepancies between what was needed and what had
been built. Standard Consulting was committed to
delivering what had been committed to Acme. Significant parts of the data conversion
programs were re-written, and the missing components were developed.
Testing was very time consuming. The
programs had not been built for the volume of data and complexity that was
really required. As a result, whenever one bug was fixed, others would appear.
More than a dozen rounds of testing and re-work were required for some
components. The client couldn’t keep up with the testing, so Standard had to
provide additional testers. The data conversion costs went three hundred per
cent over budget. The client and the technical team worked nights and weekends
to complete testing and program revisions.
The go-live date was not delayed.
However, only the basic functionality could be used right away, because not all
of the conversion components were ready. The technical team continued to work
for another month to complete the remaining components.
Conclusions
The project schedule prepared by the
technical team leader should have been the first sign to the project manager
that something was amiss. The technical lead had been focused on the technical
complexities of extracting data from the legacy system, and had planned only
technical deliverables. She had included a task for preparation and a milestone
for sign off of technical design, but no preparation and sign off of detailed
requirements.
The next sign of a problem was the lack
of status reporting from the technical lead. When she tried to give just vague
reassurances, the project manager was rightly concerned, but should have pushed
harder and earlier for proper status reporting, with progress described for
each component. This would have allowed the project manager to identify earlier
that components outlined in the strategy document were missing.
In the end, the client go-live deadline
was achieved, and all of the components were finished. The data conversion
programs ran successfully and loaded correct data into the new system. However,
the client was not happy. Acme was not interested in the technical elegance of
the delivered programs. What they wanted, and didn’t get, was programs that met
their requirements and were delivered according to the originally agreed
schedule.
Copyright
2015 Debbie Gallagher
