Critique of an Insurance Software Development Project

Table of Contents

Executive Summary

1 1ntroduction

2 Project History

3 Major Decisions during the Project

4 Problems Encountered during the Project

5 Project Analysis
5.1 Reasons for Failure
5.1.1 General Reasons
5.1.2 Reasons in the People Management Area
5.2 My Approach to Ensure the Project’s Success
5.2.1 Project Integration, Scope, and Time Management
5.2.2 Project Communications and Quality Management
5.2.3 Project Risk Management
5.2.4 Project Human Resource Management

6 Conclusion

7 References

Executive Summary

In April 1994 the insurance company Giga Safe Corp. started a software development project. Its goal was to develop a software to automate medical insurance quotes. It was scheduled as a six-month project and should be ready by January 1, 1995, when Giga Safe’s new rates were to be released. However, although the project started with a highly motivated team and high expectations, it missed all deadlines and was not completed until May 1995.

To sum things up, the project failed mostly because of bad scheduling and planning, as well as insufficient management control and decreasing team morale. With a more structured approach to project management and better planning the project could have been completed in a shorter time.

1 Introduction

The high failure rate of IT projects is widely known. Therefore, it is extremely interesting to analyse such a failed project and to look at the reasons for its failure.

Since the author of this report was never involved in a failed project, this report is based on an excellent case study written by Steve McConnell, which describes an insurance company’s software development project (McConnell, 1996, pp. 29-37).

This report is going to take a closer look at this software development project. Its aim is to figure out the reasons for the project’s failure and to deliver possible solutions to prevent such a failure. To reach this aim it is necessary to look at the project’s history and the decisions taken during the project, as well as to examine the problems that came up during the project. The second part of the report will then analyse the reasons for the project’s failure and depict a better approach that could have made the project successful.

2 Project History

In April 1994 Giga Safe’s executive committee decided to fund the development of a software to automate medical insurance quotes. Sales agents should be able to enter their daily sales in the software, which should transfer them to the central mainframe in the head office, where they should be stored in a database. The man, who had written the proposal months earlier, was appointed project manager. However, he had written the proposal for a stand­alone system without connection to the mainframe. The committee wanted the software to be completed before their new rates would take effect on the January 1, 1995. Therefore, the project’s deadline was set to November 1, 1994. This meant a six-month schedule although the proposal was based on a 12-month schedule. The committee approved a huge budget to make the development possible in the short timeframe.

The project manager thought he could shorten the schedule by hiring additional top programmers, by changing the programming language from C to the more powerful object oriented C++, and by using a new report generating tool, because the project included many reports. He still thought that the project would need seven months but his boss convinced him to try it in six months because the committee was very strict about the 6-month deadline.

The project team consisted of three solid in-house developers and two contractors. Since he was impressed of one of the contractors’ skills, the project manager hired him against the recommendation of two in-house developers, who had interviewed him as well.

The team started the project by laying out the schedule. They would spend the first two weeks on summarizing the specifications and the following six weeks on the software’s design. This meant they had four months left for development, testing, and bug fixing. They estimated the product to have 30,000 lines of code in C++ and were sure to be able to finish the project in time. They agreed to deliver the first product builds to testing by September 1, and a feature- complete version by October 1.

Specifications and software design went smoothly and the team started coding at June 15. At the beginning of August, the team reported to be between 85 percent and 90 percent done.

In the middle of August, the company released its rates for the following year and the team realized that the new rating forms differed strongly from the older versions and included different customer details that had not been considered before. Therefore, input dialogs, database design, database access, and communications objects had to be changed.

Consequently, the first build was not ready for testing on September 1. On October 1, the deadline for the feature complete build, the team still had not handed anything over to testing. Therefore, the project manager’s boss ordered the team to work ten hours per day and six days per week. The team agreed, promised to deliver a feature complete version by November 15, and delivered a first build to testing on November 1.

After failing the November 15 deadline, the team had to admit that they would need at least three more weeks to hand in a feature complete version. The team agreed to work 12 hours a day and they were given three more weeks to hand in the feature complete build.

After the feature complete version had been handed over to testing on December 5, the first bug list was released. It contained over 200 defects, including 23 that were classified as most severe.

The team estimated that they would need at least four weeks to fix the bugs and check the database’s referential integrity. The project manager’s boss approved the schedule slip and the team started fixing the bugs. But testing discovered more and more bugs and they soon realized that they would not be able to fix all defects unit January 7. The project manager stated, the team would need at least four more weeks but his boss only approved a two-week schedule slip.

The team did not believe, they could make this ultimate deadline and one of the contractors had to leave because he had signed a contract with another company. He was replaced by an in-house programmer who discovered some severe errors in the contractor’s code. Finally, he had to redesign some big parts of the PC-to-mainframe communications link.

In the middle of February a crisis meeting was held because the six-month project was three months late and no end was in sight. Another manager took the lead, reintroduced normal working hours, and demanded a realistic plan when the project could be completed. Team morale increased a little bit and the software was projected to be fully completed by May 15. Therefore, the official launch was planned for June 1, one month before the company’s semi-annual rate increase.

The project was finally delivered according to the new schedule after 13 months or 98 staff months. It had been planned as a six-month project with 36 staff months. In the end the software consisted of 40,000 lines of code in C++. An average software project of this size should need 11.5 months with an effort of 71 staff months.

3 Major Decisions during the Project

The first major decision was the committee’s decision to fund the software development project. It was based on a written proposal but included significant requirement changes. The committee set the project’s deadline to January 1, 1995. This meant a six-month schedule although the proposal was based on a 12-month schedule with lower requirements. The project was generously funded to guarantee completion within the tight timeframe it.

The second major decision was the project manager’s decision to accept the new project requirements and shortened schedule. He decided to form a project team of some internal and external staff and to choose the programming language C++ as well as a powerful reporting tool to shorten the schedule.

The project manager’s boss made the next major decision when the deadlines for handing over the first and the feature complete build to testing were missed. He decided to lengthen the project’s schedule and to set a new deadline for the feature complete build to November 15 as well as to order the team to work ten hours a day and six days a week.

When the November 15 deadline was missed, the project manager and his boss decided to slip the schedule again three weeks to December 5 and to make the team work 12 hours a day. Since the software should be released on January 1, they decided to test the software and train field agents simultaneously. They overruled the testing lead, who had complained that this would not be enough time for testing.

[...]