Who Said the Software’s Late?

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.
  1. Of the 3 original tasks, they were better expressed as several subtasks, the combined total of which took longer than originally planned.
  1. The project finished on the 4th February, not the 24th January as originally planned
  1. 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).


About Big_GH

Currently employed as a Software Development Consultant with over 30 years experience with computing. Started writing BASIC programs on the Commodore VIC 20, C64 and Amiga before switching to C and C++. Now spends more time helping others with their software and looking after the "bigger picture".
This entry was posted in agile, costs, estimates, information, planning, process, Project Management, software development and tagged , , , , . Bookmark the permalink.

1 Response to Who Said the Software’s Late?

  1. Pingback: Kanban with kids | The Big GH

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s