Building Roads


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!


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, estimates, planning, Project Management, software development and tagged , . Bookmark the permalink.

Leave a Reply

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

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

Twitter picture

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

Facebook photo

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

Connecting to %s