All successful software development projects are alike; each unsuccessful software development project is unsuccessful in its own way…and some become white elephants. Paraphrasing and extending the first sentence of Anna Karenina, a white elephant is not only a failed project, but also a project that fails miserably, severely late to market–if at all–, severe cost overruns, severe quality problems or a combination of the above. As a software professional, chances are you’ve participated in a white elephant project.

Why do white elephants happen?

Nobody wants a white elephant. So how is it that, as software professionals and very frequently being the most expensive resources for a company, we (as in the collective we) manage to produce white elephants?

There’s a combination of factors, but projects that turn into white elephants are typically very large, either for the size of the company, or multi-million, multi-year projects that span multiple, possibly geographically disperse teams. Large product rewrites are typical, but you can also find white elephants when investing in new technology, too.

While researching for this post, I came across this article, entitled The Most Common Reasons Why Software Projects Fail.  Unfortunately, not much has changed from previous years, and the reasons are similar to works published by other authors.  A couple of the points in that article that resonate with me have to do with schedules and process.

Mandated completion dates originate from the need to deliver products that are time-sensitive: Products sensitive to time to market can become irrelevant if they’re not delivered on time, and this is perfectly understood by the collective we, so why are these schedules still imposed and accepted?  For a green team–and I’m not talking about an energy-efficient team–it is easier to impose a mandated completion date.  Few dare to say no or negotiate a different outcome, and the team embarks in crazy hours.  These teams usually have high turnover rate and replacing members is expensive to the project.  This white elephant is easier to understand, but how about experienced teams savvy teams that can negotiate a schedule?

Software development processes are necessary in any product that is going to be in front of customers…yet, when we fail to follow them chaos ensues and things become like a Running of the Bulls in Pamplona, where everyone runs for their lives. I remember a C++seminar I went to in 2003, where the speaker, Herb Sutter, asked the audience how many of us had a software development process in place in our companies.  I remember raising my hand…only to find myself alone. I don’t think things have changed dramatically in the last (ouch!) 13 years.  What used to be iterative processes, such as Rational Unified Processes (and referred by people that has joined the ranks after the Agile manifesto as “waterfall”), turned into Agile, but implementations true to the spirit of Agile are scarce (and some are turned into Fragile) and now DevOps.

Two other reasons I’ve seen for white elephants are gullibility and panacea. Gullibility is an over-promised and under-delivered completion date. It flows from the bottom layers to upper management, who buys the completion date with a complete disregard for data that shows the opposite. Panacea can be anything that will deliver your project, be it a technology that is a silver bullet (and the one you want to add to your resume) or compressing a schedule by bringing another team, but failing to manage it properly. For some reason it seems that throwing people at a problem is akin to throwing hardware at a problem–heck, add more RAM and while you’re at it add more disk space. Any additional resources that you throw at a problem will increase the amount of communication needed and the number of “collisions” will increase, too. Nothing new under the sun.

So..have you seen a white elephant lately? I didn’t think so. They don’t exist, right?