Big software projects? A system that needs fixing.

If you recognise the following scenario, this post is for you.

Your company is going to launch a new project for a new cool software product. It is about time. One or more analysts are appointed, and they start gathering the requirements for the new product. Everyone and anyone who is remotely affected is consulted for their wish list of features, including yourself. Of course you start listing the features that are most important to you, but then it quickly starts to go wrong, and it is not your fault. Since you know that after the project budget is approved and all developments are done, you will hardly get a chance to add more features, you start thinking about corner cases that might happen, and add features to handle those corner cases. And then of course, you also think forward about what might happen in the future, and again you start adding features to cover for those potential future cases. Your fellow co-workers are also doing the same thing. And everyone is proud to have covered all cases, now and in the future.

After a few months of requirements gathering the analysts bundle everything in a hefty document, together with their non-functional requirements, because the new application also needs to be secure, future proof and so on. The analysts, proud of their masterpiece, turn their work over to, let's say, the project manager, who now tries to come up with a budget based on this very thick and detailed book of functional and non-functional requirements which he only partially understands. In some cases the project manager is lucky in that the project will be executed by an external development company, so he sends of the requirements document for offers to some external companies who understand even less about your business. In a lot of cases they will quote for the project, not based on a thorough understanding of the project, but based on how desperate they need the work.
Sounds like a good basis for such a big project.

Then there is the execution of the project, again for a lot of months, where as much as possible features are cramped into the project, cutting corners on usability, quality and so on, and don't ask about changes, you had your chance during the requirements gathering phase. It even gets as crazy as companies not being able to adapt to a changing world because their IT-systems can't adapt.

The consequence of this all: overly complex products, failing projects and in a lot of cases up to 80% of the product not, or hardly being used in day to day business (yes, there is research and literature on these aspects).

It feels to us as like a broken system that needs fixing.

We believe there are fundamentally 2 things going wrong:

  1. The believe that a good software product has as much features as possible
  2. The believe that a software product is a project

The 2 issues are closely related. Not only do we try to put as many features into the product as possible, but they also have to be delivered all in 1 big project. Wrong and wrong.

There is a famous quote from Antoine de Saint-Exupery I appreciate very much:

A designer knows he has achieved perfection not when there is nothing left to add, but when there is nothing left to take away.

So why don't we? I would like to hear from you through comments or other ways, and find out together with you why, and how this system can be fixed.

Herman JansenComment