This blog entry is based on experiences from me and from other people from multiple companies and projects and does not refer to any one particular organization or situation.
Many developers — including me — have at some point been amazed and bewildered at some how much time and money large organizations spend developing software and thought that it could be built in a fraction of the time and at a fraction of the cost.
The Swedish police spent some 30 million Euro building a case management system that ended up being scrapped after three years in development. Or how about the even more spectacular 2.1 billion dollar price tag to develop the healthcare.gov website? There are many more examples of such spectacular budget overruns.
I'm sure there are many reasons, but I'd like to look at one that can be described a a rift between business and IT that can allow issues to remain undetected and may even exacerbate them.
It seems to happen something like this. An organization with little or no experience building software brings in developers to get something built. Perhaps a consultancy who are happy to say yes to everything.
The consultancy might charge half as much as others. I've even seen a consultancy offer a "free resource". In this particular case the resource or developer that was provided at no cost was offered as compensation for a major budget overrun. Of course free meant that any time I offloaded work on them expecting it to take at most a few hours, it would actually take weeks and come back not working. So much for free.
When the business side brings in developers, the business side also tends to end up in charge of the development process while unfortunately often lacking the knowledge and experience necessary to lead the project.
An apparently attractive solution is to empower developers by creating a flat organization of self organizing teams where everyone is in charge.
But are the teams really self organizing or are they just not being organized? Does the flat organization really mean that everyone is in empowered and in charge, or does it mean that responsibilities are unclear and overlapping? Are teams able to meaningfully commit to a course of action, or are questions discussed and reopened endlessly?
An end user can decide what they think of a product once it's usable, but what about while it's being built? What's the quality of the code and do the technical choices make sense for the direction the project is headed in? And for that matter, what direction is the project headed in and how quickly? Both high level questions about general direction and low level details require domain knowledge.
Being in charge does not mean being in control. Domain knowledge is required to accurately gauge progress and to give direction when needed, such as when the project steers off course and when disagreements need to be resolved. If an organization does not have the domain knowledge required to lead a project, the solution is to find someone who does.