Single Blog

When I read in the news about the failure of a million-Euro project or a smaller, but closer project, I wonder why?

We are computer smart people. How can this be?

Analyzing failed projects that I have seen these 20 years, there are three main reasons, there are three main points that can “kill” a software project if they fail.

Here is the first reason for the “death” of a project.

Have you ever put together software that you were sure would be “the bomb” and hundreds or thousands of hours of work later no one wanted to buy or use it?

Have you ever followed the “requirements” – whether it was 1 paragraph or 100 pages – and once finished, or even halfway through the project, they told you that this was not what was wanted and a tremendous amount of changes began that multiplied by several times the work needed on the project, or worse, was the project lost?

Some “good” failures

• In a real case, a startup spent years and millions of Euros developing an online software product and service assuming it would work, but without examining the real demand for it and what the user really wanted. The consequence was closure and loss of investment.
• In another case, hundreds of millions of Euros and years were wasted on a system to automate an important part of the State administration. Talking to end users we know in that area we found out that the system is useless, since it does not include basic functions that they need in their daily lives and that are not even difficult to implement.

This all boils down to the topic of:

What does the client and/or user really want or need?

Tens of thousands of hours can be wasted going in the wrong direction. This is such a radical mistake that it may well be the source of most “great total failures.”

The most common errors

• We may not be talking to the end user, but rather to an intermediary who “knows” what is needed, but does not really know it (e.g. with the client’s IT department if they have not checked with their real users, but instead “knows more than anyone else” – but doesn’t really know).
• The user can give us his (bad) “solution” instead of the problem he is trying to solve. With a few honorable exceptions, his solution will be a failure if we follow it. In any case you have to examine it in detail, get to the real problem and get a good solution for the problem.
• The user is unable to analyze what he needs on his own due to lack of organizational, technical, etc. capacity. We will have to do it for him.
• And the worst thing – we have never examined what the user really wants or needs – we simply “assume” it because “we know.” This is a good route to failure, if it is not accompanied by real research.

The problem with all this is that the wrong requirements will hit us in the face, even if it’s not “our fault.”

When “garbage hits the fan” it hits everyone.

It is very difficult to collect payment for a “failed project” even if it is not “our fault” and we can even end up with a bad reputation or legal action.

The solution

The solution is to make sure the requirements are actually correct, regardless of whether it is “our responsibility” or not. It requires discipline, as it is too easy to “shortcut” and “assume.” Some functional rules in this regard are:

1. Never accept requirements “simply” without a thorough analysis of your own. Do the requirements make sense? Do they have contradictions? If we were the end users, would we want this system? If something is wrong with any of these questions, we have to start investigating.
2. Never accept that they give us very little detailed requirements for a project. For ex. Every once in a while someone asks us “What would it cost to make a Facebook?” or something similar. I’m sorry for anyone who gives a quote for this (and then accepts it). By obtaining more data and finalizing the project we can achieve something.
3. Verify the supposed requirements of a project with end users, ensuring that it makes sense to them. In very few cases can we accept that the client has done this analysis correctly with their end users, especially if we see things in the analysis that do not make sense.
4. Make sure to do the complete and thorough requirements analysis before starting development. Sometimes “commercial rush” leads to starting without further ado, with “half-finished” requirements and the consequence is changes mid-project and hundreds or thousands of hours lost. If the client cannot detail his requirements in good detail, it is very possible that he does not (yet) know what he wants or needs and that he will want to change it mid-project with great losses for everyone.
5. Never start your own project just because it is a “good idea” in our imagination, without a minimum of market research, even if it is informal, but with a sufficient number of people. Do that analysis.

Sure there are many refinements and details, but it is the most basic 1-2-3-4-5 that we have found that if we do not respect it in a project, it is very possible that it will fail – and that much to our regret we have found in one of our projects where we relaxed these requirements and then a lot of work was required to redirect or rescue the project.

I hope it is useful to you.