About 10 years ago I was working on a project that was something of a nightmare challenge and fitted many of the criteria of what I have later described as ‘the existing system syndrome’.  That is to say, it was a replacement, pretty much-like-for-like actually, of an existing application. These projects are almost always in my experience the most difficult and problematic.  Many people are surprised by this statement. Replacing an existing system should be easy, surely?  You already have the knowledge?  You have the existing system as a basis?   The business area using it is probably mature and knowledgible? 

Well, alot of this adds to the problem, bizzarly.  For one thing, the expectation on the part of the customer will be that it is ‘just an upgrade’ or a ‘conversion’ and therefore they won’t want to fund it properly.  For another, the simple fact that you are taking something that people already know (and sometimes love) and replacing it in it’s entirety means you have on your hands a potentially complex reverse engineering exercise (or at least we did), but it also taps into alot of emotional baggage that end-users have built up.  ’Oh the old system was so much better’ some histrionic soul emailed me (because a specific keyboard shortcut had changed if I remember correctly). It’s like trying to recreating the recipie for the favourite lasagne that someone likes.  You’ll never get away with it lightly.

There were a bunch of issues we faced with this project.  It was poorly estimated for one thing (not by me, I hasten to add, but probably as result of the mind set I have just mentioned). Yes, we did have some of the source code for the system we were replacing but this was incomplete in parts and in any event was presented to us as being somewhat ‘unreliable’ in terms of the version.  We had a compiled executable and installer (which may or may not have been built from that source code), and a set of documentation from about 6 years earlier describing the calculations the software had to perform.  It did, however, have to behave exactly as before.

This scenario throws up a whole load of discussions, but needless to say the project did run into problems – unsurprisingly – and I set about thinking of ways in which we could restructure the project to help deal with them.   It seemed obvious we would run into very serious issues if we didn’t, and there needed a way of ‘blowing the whistle’ if the right things didn’t start happening pretty quickly.

Over a combination of lunch and a glass of Leffe blanc after work with a colleague, the solution became clear. To cut a long story short, we would dissect all the existing tasks and requirements and structure them into logical groups based on how well they fitted together, their generic size and so on.  We would then agree priorities and allocate resources to them.  Crucially, the project would be structured into weekly development cycles, where we would do development basically from Tuesday to Thursday.  Friday would be set aside for testing, verification and deployment; Monday would be set aside for responding to customer feedback in the morning, planning in the afternoon, and then a view would be taken on how well we thought things were going over all.  If there were serious concerns about progress we would ‘blow the whistle’, escalate the concerns to more senior levels and work out a way forward at the earliest opportunity.  This might involve temporarily suspending the project. 

We called this approach…  well, nothing, really.  It just seemed a more sensible and logical way of structuring and getting on with the work. 

At this point in the article I was going to run a ‘what happened next’ competition to see if you could guess what happened when I presented the idea, but I’ll save you the trouble.

It got turned down. I think the reason I was given was that ’it would be seen as an admission of failure’ to go down this kind of route.  So we continued as before, and the system did eventually get delivered:  it didn’t turn out to be the horrendous abboration it could have been, on the contrary, in fact.   Towards the end I even got paid for some of the extra overtime, and managed to get home at a reasonable hour.

I promise you I’m not complaining.  Projects like this are what they call ‘character building’ and do give you an interesting insight into many things you won’t get from any formal training.  The fact that I came up with the new (to our company anyway) approach to project structure in about 2 hours I also find quite interesting when I look back and I’m rather proud of.   Nowadays of course, ‘agile’ is an industry, with dozens of books, conferences, training, communities and so on.  It makes you think. To me, though, most of the ideas in agile (though not all of them, I can assure you) are just common sense and there isn’t that much to diagree with.   So perhaps ‘doing the work’ is now the way forward.

« »