Why software projects are always late (Part 2)

The list of reasons why software projects finish late is seemingly endless. Here are four more.

The first part of this post is here.

Absent project sponsor

The most sensible thing I’ve ever heard about project management is the vital importance of the project sponsor. This is the person who sets the project agenda, has ultimate power over the project, pays the bills, and the person who should make all the big decisions about budget, time, and scope.

But often the project sponsor is absent or pays scant attention to the project until it is too late. You would think for a project of any importance the sponsor would be over it like a rash. Maybe that happens in small businesses, it almost never happens in large businesses and large projects. Maybe it is simply too scary for the sponsor to stay focused on what must appear at times a chaotic shuffling zombie.

Sometimes, inexplicably, the project sponsor will delegate their executive privilege. Which leads me to my next reason for project failure…

Inappropriate outsourcing

The arguments about when it’s good to outsource software development rage on. On the one hand we have  cost and flexibility, on the other hand we have software quality, process transparency, and effectiveness of communication.

My view is that you should never outsource your brain. The heart might be well replaced by a mechanical beat-box, but the management and production of software development, with all the quirky organic edge cases and reciprocating parts is simply too much.

I realise this is not a popular view, and that the multi-billion dollar industry is evidence that in some sense (though I argue it is a limited and often irrelevant sense) it must be concluded that outsourcing provides measurable benefits.

I would never do it with my own money except in the most limited and routine cases.

Disproportionate emphasis on (what should be) supporting activities

Project manager, salesman, marketer, stakeholder, sponsor, tester, business analyst, systems analyst, line manager, documentation writer, packaging and deployment specialist, infrastructure consultant, user-experience analyst, user representative, programmer.

Suppose you were forced at gunpoint to pick exactly one of these specialists and still produce a software product, which one do you choose?


Hint: It’s not the project manager.

The creeping paralysis of technical debt

Technical debt accumulates as shortcuts are rushed into production to meet short-term urgencies. The shortcuts sink into the foundations of the product as new features are piled in on top, and eventually the temporary measures set like neglected broken bones, crooked and ill fitting.

Eventually the cost of maintenance and support exceeds any possible payback and the product is forced into life-support mode or gets replaced.

A sure sign that a product is approaching this point is when every estimate is met with disbelief and scepticism. Do you know any products like that?  I most definitely do.

For every product that reaches this point there is a preceding period of time where development life becomes extremely difficult and project failure is common.





Posted in Software Management

Ed Guiness

I am the author of Ace the Programming Interview, published 2013 by John Wiley and Sons. In 2012 I founded SocialCoder.org, a volunteering organisation for programmers. I have been a professional programmer for more than 20 years, and a hiring manager since 2004.

Ask me anything.