Critique of an Insurance Software Development Project

Table of Contents

  Executive Summary  II

1  Introduction  1

2  Project History  1

3  Major Decisions during the Project  4

4  Problems Encountered during the Project  5

5  Project Analysis  6

5.1  Reasons for Failure  6

5.1.1  General Reasons  6

5.1.2  Reasons in the People Management Area  8

5.2  My Approach to Ensure the Project’s Success  9

5.2.1  Project Integration, Scope, and Time Management  9

5.2.2  Project Communications and Quality Management  10

5.2.3  Project Risk Management  10

5.2.4  Project Human Resource Management  10

6  Conclusion  11

7  References  12

I

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.

II

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 standalone 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.

1

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 featurecomplete 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,

2