We are always hearing about software projects being late.  My current experience tells me that my own software team will deliver their software later than planned.

So why is that?  Let’s firstly get the assumption that the team is somehow lazy, incompetent or unmotivated out of the way.  Good software developers and development teams just aren’t like that!

Right, so we have established that everyone on the team wants to succeed, they are working hard, but still the deadlines come and go and the software ends up late.

I think this can all be tracked back to estimating and we all know that estimating is hard.  I think the big question when someone decides that a software project is late is “who decided when it should be finished anyway?”  Simply changing the end date takes a project from being late to being on-time or even early.  This fact is so important, yet estimating is rarely given enough importance in order to set a realistic end date for the project.

One of my favourite responses I heard someone give to the question of when their software would be ready was “it will be ready when it’s ready”.  Really unhelpful in terms of planning the myriad of other activities that depend on that software being complete, but entirely truthful and sums up both the difficulty of estimating and the desire to avoid setting unrealistic expectations.

Let’s draw some pictures.

Firstly let’s look at a software project as a series of tasks that require completing before the project is complete.  You might see this on a GANNT chart:

Note: This is a very contrived example, simply to illustrate the point.

In this example, we have broken down our project into 3 tasks, all of which depend on the previous task completing before we can start the next one.  Our project plan shows us starting on the 6th January and finishing by the 24th January.

Now let’s take a look at the plan once the project is complete.

Several things now become clear:

1. There weren’t just 3 tasks involved in this project, there were 5.

2. Of the 3 original tasks, they were better expressed as several subtasks, the combined total of which took longer than originally planned.

3. The project finished on the 4th February, not the 24th January as originally planned

4. If the team (or project manager, sponsor or whoever is in charge of producing the plan) had produced a plan that looked like reality (version 2) then they would have been praised for completing the project on time.

The ideal project plan is therefore one that accurately predicts the future!

Don’t confuse poor estimation with poor performance (or the ability to set low expectations and then exceed them as a mark of good performance).