Reference no: EM131185555

Lavasoft Company, a web site development firm, is developing new site software for one of its corporate clients. The project starts out well. Lavasoft staffers meet frequently with client representatives to produce a document of clearly stated client needs and requirements. There is no question about what the client needs; however, members of the Lavasoft development team disagree about the kind of system that would best satisfy these needs. The project manager, Mary West, is concerned about the time this project will take. She feels that the kind of system that would best satisfy the user needs is more or less obvious, and she asks a few people on the team to help her create some bullet points and general flowcharts to address the requirements. She also creates a project schedule.

She then presents the charts and schedule to the rest of the development team and says that anyone is free to question her about them. Some people are concerned that the approach as stated by the bullet points and the high-level charts are too vague. Mary assures them that the vagueness will be worked out as details of the system are defined.

A team of designers is selected to perform the detailed design and development work. To speed up decision making and reduce outside interference, the team's size is kept small and relatively isolated from other development teams in the company. Daily the team is forced to interpret the bullet points and high level charts and to make design decisions. Whenever there is disagreement about what should be done, which is frequent, Mary makes the decision.

The design team produces the detailed system specifications on time according to the schedule, so the project is considered in good shape. However, upon looking at the specifications, some reviewers raise questions. For example, it is not clear that all aspects of the system will be compatible with the client's existing site products. Further, the effectiveness of meeting all the requirements is not uniform (some requirements are clearly met; others are questionable); and some of the specifications involve system expertise that isn't the forte of Lavasoft. The original development group does not want to change the general approach; instead they simply change some of the specifications before proceeding.

Many weeks pass as the specifications are reworked, reviewed and approved, but questions persist. Finally, the project manager decides that coding and testing must begin if the project is to stay on schedule. Once coding and testing of elements of the system are completed, however, resistance grows to changing the specifications because that would require recoding and delay the project further. Compromises are made to the specifications. More time passes and the system falls 3 months behind schedule. To meet the deadline, Mary puts more people on the project. Eventually the system is considered ready for installation, but it is 2 months later than the original promised date. Because more people were needed to staff the project, Lavasoft does not make a profit. Also, because the system is not completely compatible with other elements of the client's web site, Lavasoft must continue to work on it and introduce "fixes." The client is not happy with the results and does not contract with Lavasoft again.

QUESTIONS

1. What went wrong with the project?

2. Where were mistakes made in the project initially?

3. How were problems allowed to persist and go uncorrected for so long?