UNITEC – INSTITUTE of TECHNOLOGY
Faculty of Business
Department of Information Systems and Computing
Master of Computing Programme
Managing Information Technology Projects

Critique of an Insurance Software
Development Project

by

 Andreas Thiel

 October the 15th, 2001

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

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

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.

[....]