Ten years since Railtrack

Time fly’s, I still feel young but when I realised this morning that this time 10 years ago I was working on a project for Railtrack I felt a bit older. That project taught me a lot about how not to run a project, it also lead to a lot of thinking over the years.

In the mid-1990’s the British Government set about privatising the railway system. At the time British Rail owned and ran everything to do with trains in Britain. It was too big to privatise in one go and the Government wanted to bring about competition on the railways so it was broken up into many smaller pieces.

A set of Train Operating Companies (TOCs) where established to run the trains, and one company, Railtrack, was given the track to run. The BBC have plenty of stories on what happened to Railtrack, for example this one, but none of these talk about APLAN.

To bring about this vision Railtrack needed a new timetabling system, the old one kind of worked, it was a MSDOS based computer system (PROTIM) and lots of paper. This didn’t matter much because the timetable didn’t change much, just twice yearly increments. But for the new world of competition something much bolder was needed... and so project Access Plan, APLAN for short, was born.

By the time I joined the project in September 1995 it had failed once already and had been passed to a second software development company - Sema. At its height there where about 120 people on the project. The odd thing was that few of these where programmers: at most 12 C/C++ developers, 2-3 Visual Basic developers and 4-6 database DBA’s / SQL developers. The rest of the team was business analysis, testers (system and user acceptance), architects (who didn’t code and came from a COBOL background) and managers: lots of managers.

The project was priced on time and materials so there was money to be made. I was a contractor working on an hourly rate (6 days a week), there was my agent (adding 20-25% for themselves) and then Sema, with their own staff living in hotels and working on a T&M basis plus the a mark-up on the contractors. Railtrack was paying the bill but they where still owned by the Government so it was really the tax payer paying.

Just to make sure we all got the job done to a suitable standard we worked to ISO-9000. We had think process manuals and even thicker requirements, architecture, specification, functional specification and test plan documents. Unit testing happen religiously but it wasn’t automated. (This was the project where I realised that ISO 9000 was evil.)

The project was a “success” – it shipped code, Railtrack used the system to produce a new timetable.

The project was a “failure” – very early on the most ambitious ideas about train companies bidding to run trains had been dropped. Towards the end of “phase 1” even more features where dropped and much of the final timetable was produced on paper.

Trouble was: who was going to tell the Prime Minister the system was a failure? Sure everyone at the code-face knew things weren’t going to work like people envisaged, even the first line management knew that. But the message was watered down as it got passed up the chain. If the CEO of Railtrack or John Major knew the true extent of the problems the privatisation couldn’t happen.

And if it didn’t happen when it was scheduled to happen well... everyone knew that Tony Blair would be Prime Minster in a matter of months so it might not happen at all. So the project was a classic Death March.

“Phase 2” was cancelled before it even got started. Yet with the bulk of the system in place Railtrack had to continue to use it. I even rejoined the project two years later to develop parts of it – but that is another story.

Of all the lessons I learnt on this project two stand out.

Lesson 1: Inside every large project is a small one struggling to get out

This project created its own size, more people required more people. It was T&M so there was an incentive to add people. We could have lost 80% of the people and achieved an awful lot more than 20% of the work.

Yes, 20%, 30% or even 40% would not have been what the Government wanted but that leads to lesson 2.

Lesson 2: Some projects shouldn’t be done

I often asked myself: what would I do to fix the project? By the time I was on the project it was already too late.

I often asked myself: how would I have run the project? I knew a lot of techniques to improve things, and I know a lot more now, but I don’t know any that could make this project a true success. The only conclusion I can give is: the project should never have been done in the first place.

Some projects are too big, too complex, too ambitious, too time constrained that they should not be attempted. As a supplier you should not accept such projects.

Of course there will always be someone, somewhere, who given enough money will attempt it but these are actually the worst people to attempt such a project. If the customer will not listen to advice and does not realise what they are getting into it is their own problem.

No, if someone comes to you with such a project you should try to persuade them of a better way: extend the time allowed, break the project into chunks, reduce scope. Infact, this is more than just a "should” it is your duty!

But if at the end of the day you can’t persuade them to accept an alternative don’t do the project: you don’t need the money that much and your staff will thank you for not making them do the project.

In ten years a lot of things have changed: Neither Sema or Railtrack exist any more, I’m not a contract programmer any more, our business models where not sustainable. Unfortunately death march projects still occur.