All Change Please
Until the 20th May I had a well-orchestrated routine in the morning to ensure I arrived at my station in time for the train to London. It worked well for the past year and half since I made the decision to move from London to just outside Brighton.
But like the course of true love, this implementation definitely did not run smooth and my fellow commuters and I suddenly found ourselves the victims of a failed project.
Dude, where’s my train?
The effect of the new timetable resulted in many cancellations, trains disappearing from the boards at stations moments before they are due to arrive, delays and a level of unpredictability that is causing many commuters to wonder if working in London is worth it. The chief of Thameslink has resigned. A government enquiry is underway.
As a project manager, I find it unbelievable that a project of this scale went “live” when it now appears it was known internally at Govia Thameslink Rail (GTR), Thameslink and Southern’s parent company, that the new timetable was unworkable. In fact, at a Rail Industry Readiness Board on the 4th of May it was predicted there would be a high risk of cancellations once the new timetable was implemented. So, what happened and what can it teach us about how not to manage a website/intranet project?
The success of the new timetable relied on several deliverables which needed to be in place before go-live. Below are a few key ones:
- Approval of the new timetables
- Successful delivery and testing of new trains
- Driver training
The delays to these key milestones contributed to the failed implementation.
Sign-Off of a Key Deliverable
Sign off CAN be delayed in any project but only if the risk of the delay has been mitigated and you are able to proceed with the plan as originally intended once sign off is received. In the rail case, the new timetables were signed off 3 weeks before they were due to go live instead of 3 months but it appears no mitigation was implemented to prevent this from being an issue.
If mitigation is not possible then a delay to the project plan is sadly inevitable. As seen though, ploughing ahead is not always the best course of action and can make an implementation fail.
Rushing testing or not completing it will only lead to issues post go-live, be it unavailable functionality or poor user experience.
Too often testing is not given the importance it deserves but it is fundamental to a successful project launch. Testing ensures a smoother implementation. Our team of Quality Assurance testers will put all our developments through their paces before handing over to our clients and our project teams will then support our clients through user acceptance testing to ensure minimal issues post go-live.
The quality of the training is not the only factor for a successful project but when the training is conducted is also important.
We always plan training before user acceptance testing. In the same way GTR would not expect a driver without training to be able to drive a route they have not been trained on, we do not expect our clients to be able to complete testing without knowing how to navigate the system we have delivered, therefore our UAT phases cannot progress until training has been delivered.
Hot fixes often cause Project Managers a headache. They may well alleviate an issue in the short term but ultimately, they only add to the backlog of work to be done at a later date (technical debt). It can increase the cost of a project and result in benefits being realised later.
My PM’s keep logs of all risks and issues for our projects and review them regularly with our clients. We are transparent about issues and will also highlight the risk of a hot fix over a long-term solution.
Wrong side of the tracks
A failed implementation will do lasting damage especially if expectations have not been set correctly. As previously mentioned, there were a number of benefits sold to commuters in the run up to the 20th May. Despite GTR’s troubles over the past few years (ongoing strike action and the reliance on drivers to work rest days to ensure the previous timetable was achievable, to name just two), many did think this would be an improvement. Those extra trains per hour and Thameslink trains finally stopping at London Bridge after years of travelling through London at a snail’s pace whilst the station was completely transformed, sadly were too good to be true and now commuters have lost faith in a solution being found without either Government intervention or a new supplier taking over from GTR.
With a website or intranet, first impressions are key. User engagement can be lost very early if proper training is not provided, users are not engaged on a new solution or simply things do not work.
To ensure a smooth adoption we demo our solutions to our client project teams early in development so small changes can be considered early on rather than waiting until late in a project to show what has been developed. As above, we place a lot of importance on testing to ensure the product delivered matches the expectations set at the start of the project and matches agreed acceptance criteria.
Even if working in a more agile manner and there are areas of a site that are not yet complete it is possible to add “Work in Progress” pages to at least let users know why something is missing or perhaps not complete. It helps set the correct expectations with users.
Major projects are not easy and I am sure there are a lot of factors that resulted in the timetable failure for GTR but the above definitely outlines some key things not to do in a project. By ensuring you know your deadlines and milestones, mitigating your risks, and ensuring honest communications your project is more likely to be successful!