Meaningful milestones

For the past 12 months I’ve been working exclusively on the same project, if you follow me on Twitter (and if you don’t, you really should) you might have heard me refer to it as Überproject as it’s without doubt the biggest project I’ve ever been involved with in my career so far.

It’s handover time for Überproject and as we’re wrapping up our development I’ve been taking stock of the last 12 months and thinking along the lines of “If we had to do this all over again, what would we do differently?” aka “What gave us grief, and how can we avoid doing it again”.

Meaningful milestones

One particular aspect of Überproject was a large section of bespoke functionality which was, in effect, a project within a project which I’ll refer to as #up1 for the purposes of this blog (It’s not gone public yet, so I can’t name it specifically).

Early on, we attached two milestones to key stages in the project, a testing milestone, and a go-live milestone.

The testing milestone was defined as a date when functionality was to be delivered to our development environment ready to be put through it’s paces where any bugs would be logged as tickets in Trac (our project management / source control platform) and we would then work through any outstanding tickets before the go-live milestone date.

up1 was given milestones consistent with the rest of the project with a couple of months between testing and go-live, the development of the back end was going well and the front end development would be taken care of later with the rest of the front-end build (which had it’s own milestone).

About a week before the testing milestone was due for #up1 I was hit with a bombshell. The definition of ‘testing’ in this instance meant that the back-end had to be fully functional and production-ready for the end-users to start populating the module with data. This meant that the back-end should have entered testing weeks ago and had bugs ironed out before the end-users ever got close. The back-end needed be go-live ready.

Fortunately, a week’s worth of frantic coding meant that I got #up1 fully functional before the users were allowed in and this was only done on a limited basis, users were aware that we were still in development and we turned the situation to our favour by deputizing them as bug testers by asking for and encouraging feedback.

The moral of the story?

Going forward, we will need to be absolutely clear of what’s expected to be delivered at each milestone and avoiding vague terms like ‘testing’, as we’ve seen, the definition of testing can vary wildly between different aspects of the same project.

comments powered by Disqus