Matthew: why software projects fail

Matthew tells us why software projects fail. Good observations, looking from a coding perspective.

In my experience, failure can also be defined in another way: failure means that the customer is not happy with what he gets, if he gets anything at all.

This is not necessarily the fault of the party implementing stuff – here’s how I have seen things fail spectacularly in the past:

  • The client needs a solution to a specific problem, which he can’t quite grasp technologically, which is why he’s hiring somebody to do it for him in the first place.
  • The sales rep sees $$$$$$$$
  • The sales rep describes what he thinks is the problem to the programmer and asks him/them for an estimate
  • The programmer only sees the parts of the problem he can solve by doing something he’s been doing for years
  • (at this time, we are already waaaayyyyy off track!)
  • The programmer gives an estimate to the way he sees the problem
  • The sales rep suspects that the programmer is playing for time and cuts the estimate, adding QA and documentation without increasing the time
  • The project is late and implements a solution to a different problem.

Doomed from the start. But – the client usually plays along, i.e. he will happily accept such offers without questioning them, looking for the best price.

Why does that still happen, after so many years of failed projects (how old is “The mythical man-month” again?)? I find it disturbing that we don’t seem to be able to learn from these failures, and fail to make sure the problem we’re addressing is being solved making the client happy.

It comes down to two central points IMHO:

  • Sales is too optimistic about time & costs, and the client is only too happy to accept that. Times are being estimated along the client’s wishes, disregarding realistic estimates.
  • The *real* requirements are never properly addressed.

Silly.

Update: as has happened a few times before, today’s Dilbert cartoon fits perfectly.