One day a manager had an idea.

It seemed to the manager that there was a good need for a new system. A system that would save money and make his organisation's life better.

The manager thought that this new system would not be difficult to build, after all , it was simple idea and had obvious benefits. At least, he thought the idea was simple and the benefits were obvious to him. And the new system couldn't cost that much. Could it? His consultants and his vendors all thought it was a good idea. After all, it could mean work and money for them, so it must be a good idea.

So the manager instructed a team to put together a business case to build the new system. He told them when it was to be complete and how much it would cost. After all, he was the manager and he knew best.

So the team obediently drew up a business case.

To please the manager the team made sure that the business case showed that the system would cost exactly what the manager had said and would be complete exactly when he said. This was even though nobody on the team, or the manager knew a lot about the technical details of the system they were to get or any problems there might be building and implementing the system.

And the team knew that it was important that the cost was low and the time to build was short. It was important because otherwise the business case might not get approved.

The business case was presented to the powers-that-be and was authorised, even though the powers-that-be didn't understand lot about the technical details of the system either.

The system never was implemented. In the end it took much longer to build than expected. And cost a lot more as well.

Not only that, but it didn’t deliver what the business needed. The manager was very upset with the failure. He just couldn’t understand what the problems were. His project manager had consistently promised that the project was on time and on track. And he would know, wouldn't he?

Unfortunately, when it came to testing the system, it just didn’t work properly. It didn’t do what the users wanted, it was slow and the cost of the technology was many times that predicted in the business case. Suddenly, the project manager's promised deadlines failed. Previously all his estimates and deadlines were met, now, when it came to testing, that changed. The project manager had claimed that the project was 90% finished. Now it looked as though the last 10% would take as long as the first 90%.

In the end the system was abandoned and the technical team were all reprimanded. Some lost their jobs. After all, they hadn’t delivered what the business case promised.

When the project was independently reviewed it was discovered that the business case had drastically underestimated how long and how much the system would take to build. The conclusion was that the requirements kept changing, the scope was unclear and there was no technical leadership across the project.

The moral to this story is:
When an IT project fails, don’t blame the technical team, blame the people who wrote and approved the business case.

Bernard Robertson-Dunn, June 2010