We are often told when managing software projects that things should be more predictable, more repeatable and that our projects are less in control than others.  As we saw previously, I’m not convinced.

I’ve been watching with interest over the past few years as a major road upgrade has taken place near my home.  This was a 3 year project to convert a single carriageway into a dual carriageway and involved rerouting the road, creating some new roundabouts and bridges – including one that carries a railway line.

Overall, I’d say I’ve been reasonably impressed with the way this project unfolded.  It started on time, appeared to progress on schedule and was officially opened on time.  However, whilst the signs along the road side state that there would be disruption until Summer 2012, we still have cones along the roadside and overnight closures of certain sections.  I’d say that this project is definitely not complete!

So what happened?  And what can we learn about our own projects here?

Firstly, predicting timescales on any large project is hard.  The combined uncertainty of so many tasks can add up to make predicting an end date more of a guess than a science.  It was interesting to see that the end date they used on the road signs was Summer 2012, not 5pm on 1st June 2012.  Communication of end dates can be a useful way of inferring confidence, stating Summer 2012 shows the wide range of possible end dates that might be acceptable and shows the uncertainty with a lack of precision.  I have no doubt that a project manager somewhere will have sat down with a tool such as MS Project and will have added all the road building tasks onto the plan. Fortunately they avoided the trap of using the dates in that tool as the dates they communicated.

I also noted that at certain times of the project, they could predict with great certainty when parts of the road would be closed.  Signs would appear warning of closures for the following week.  Again, underlining the ability to predict with some certainty events that are close by (although even then sometimes the roads didn’t close when the signs said they would and the next day the sign would be updated with a different closure date).  This ability to predict close events with some degree of accuracy and further events with less is described as the Cone of Uncertainty.

Secondly, defining when a project is done is critical.  When upgrading the road, the definition of done seems some way off my own definition of done.  They officially opened the road on time, so perhaps they were happy with their definition of done, but as someone who drives on that road, I am not.

I have no idea why work is still being done on the road.  The road is functional, it has lines painted and lights on the side, so you could argue as version one it meets the Minimum Viable Product we might release as a software team.   A lot of traffic is using the road, so they are clearly providing value by “releasing early”.  Perhaps they have simply entered a maintenance phase, maybe they are taking the opportunity to reduce their technical debt.  Whatever it is, I just wish they’d hurry up about it!