Monday, May 25, 2009

Analysis of a failed Software Project

A real life project:

The project was to create an automated way of handling the back office work, with different interfaces and protocols to customers, data warehousing company, end users, hardware vendors, etc.

The project started with some discussion of schedules and features. The architect was bright. He could come out with innovative solutions to problems fast. Very inspiring and motivational to the team.

No one bothered to document anything, as everyone was “busy” and working day and night to meet the customer deliveries.Programmers were busy writing code, and then fixing it when the next set of customer requirements came. Everyone was busy "working". The architect worked the most, spending sleepless nights at the office.

Deadline after deadline slipped, and the project was slowly inching along. At the end of the year, a prototype with some features was available for integration. Neither complete nor exactly based on any specifications.

Then it came time to deploy the project with the first major customer. After technical meetings between the two companies, and initial tests, it was discovered that many of the customer message formats were incompatible with the system message formats. “So what, we can fix our side overnight to handle your message format” was the kind of mentality on the company side.

The message formats issue was fixed. But not having undergone any serious tests, other parts of the software started breaking. New bugs were reported everywhere.

Once real load started hitting the servers, it was observed that the response times were getting slower and slower. The system was crashing more often. An architecture review was conducted. It revealed many deficiencies in the architecture. No coding standards were neither available in the company nor were any followed by any developer.

After a few heated meetings in the months after that, the architect was let go. Some of the staff, complaining of long hours left. Some did not see the company going anywhere, since that was the one major project for the company.


What were the problems?

Inexperienced people. A lot of pressure was placed on the architect, who was the best of the pack. Though he did a great job, the work was far too much for one person. Most of the people did not have any real world project deployment experience.

Communication and Motivation. Though the higher management got along very well, team work stopped there. Company goals never made it to the trenches. Motivation was missing.

No Processes. In the haste to get things out fast, no one cared about defining a software development process. No clearly planned software requirements, schedules, testing, etc. Disciplined software development is the only way to produce software!


How about Risk management?

The company developed its own risk management practices, and paid a lot of attention to certain aspects of risks:

Risk of losing critical data – Backups were done and stored in different parts of the country at the end of every week.

Security risks – The premises were well secured with closed circuit security systems. Highly secure algorithms were used to transfer financial information, from system to system. Logistics of secure data was clearly planned. All sorts of precautions were taken to prevent hacking into the company systems.

Risks for hardware not being available. Various alternative plans were formulated to make sure the project is not affected, in case some of the hardware vendors did not cooperate to produce the customized hardware.

The company spent significantly on an external security consultants to point out flaws in the system.

However, management seemed to have forgotten the biggest risk: software development.

While this reads like a story, this scenario is repeated each day in countless organizations across the world. Software development risks are still not appreciated to this day by most organizations or management.