Why the BIG project failed - Efficient and Intelligent Mistakes

(This is a work of fiction. Resemblance to any company, project or people is unintentional.)

The BIG project (BIGP) was the promise of liberation for Grey Matter. It was supposed to be a two year, multi-million dollar project. With "many more similar sized projects" if this went well.

An entire army of big guns were poached from software majors. Folks who had executed similar projects and come out with flying colors. Or so they said.

Today, about three years since the project was started, the curtains have come down - officially.

What went wrong?

Many things.

To start with, the project was highly over-architected. When I first saw the architecture diagram, I thought it was a huge club sandwich. There were about ten layers. Ten layers? That's a lot. When you have ten layers in your architecture, you know you have a problem. Mr. Architect-in-Chief just loved complicated architectures. "Come on guys, this is a huge project. How can it have a simple architecture? Three layers is for wimps. The more (layers) the merrier. How about 10?"

"Makes sense", all his cronies nodded in agreement.

In any software project, there is one cardinal rule that must be followed: Keep it simple. When you have a project with such complicated functionality, you have to keep the design simple.

This brings me to the next problem with the BIGP. Multiple locations with no single anchor. The project was executed from three locations. There was no single person responsible for the project. People in all three locations had heavyweights who took no personal responsibility for the overall delivery of the project. They had a fancily named Project Management Office (PMO) which was supposed to be jointly responsible for the project. Joint responsibility - another red flag. There is no such thing as joint responsibility. There has to be one person responsible for a project. Nobody could be held accountable. Not Mr. Bald Eagle, not Mr. Bong Babu. Certainly not Mr. Spineless in San Jose.

In going with the fancy sounding names, the Agile methodology was adopted. Apart from sounding sexy - "We're using Agile" - it looked good on a resume. Well, there is nothing wrong with the Agile methodology. The only caveat is you have to follow it completely. Here, Agile was used in parts. For example, requirements freezing for a sprint, the foundation of an Agile sprint was never done. As a result, features kept getting added on the last day of a sprint! A sure recipe for disaster.

A major problem with the project was nobody from the PMO had their ears to the ground. The developers on the project, the foot soldiers, had predicted this outcome six months into the project. Nobody listened. They raised red flags again and again. Still nobody listened. The number of bugs kept getting bigger and bigger. Stability plummeted. Still nobody listened. If the customer was happy, why bother.

That was a huge problem in itself. Mr. Chief Architect knew how to please customers. Unfortunately he did not realize that you can fool some people some times, but you can definitely not fool all people all the time. Sooner or later the customer would wake up. When he did, all hell broke loose. But by then it was too late.