Session 7

1. Session 7 London Ambulance Service Case Study

2. Up front issues • LAS had a vision to create a great system – which would have created competitive advantage now that they had to tender for work with the carious hospitals • Always difficult to implement a new system when morale is low • Time and budget constraints, as we shall see, created huge problems – these were issues even before the project commenced

3. Analysis Strategy • The new system was to be strategic in terms of: • Corporate strategy • LAS had to tender for new contracts and they believed a new, all embracing system would give them competitive advantage • Operational strategy • The new system would replace a largely manual system resulting in improved response times and efficiencies which had been benchmarked as being inadequate • The decision to implement the system in a single phase (big bang approach) was a poor “implementation” decision, which was in large part responsible for the disaster • Strategy does not exist in a vacuum – it must be attainable and realistic deadlines and time horizons must be set

4. Analysis Enterprise Architecture (EA) • No formal or informal EA was in place • No mention was made of business models, processes, architecture, standards, interfaces, etc • No analysis had been done on the who, what, why, when, where and how – this resulted in the exclusion of the ambulance team in the analysis process • If standards and interfaces had been specified, it would not have been possible to commence the project without specifying the interfaces between the three core modules. • Computer Aided Dispatch (CAD) • Computer Map Display (CMD) • Automatic Vehicle Location System (AVLS) • An EA would have surfaced many of the issues – processes, divide and conquer, personnel, responsibilities, etc • Risk of failure and the possible consequences were not assessed realistically

5. Analysis Acquisition decision • Arbitrary budget • Where did the budget of £1,5m come from in the first place? • It was clearly unrealistic and probably eliminated some of the better and more honourable contenders • The correct approach would have been to call for tender submissions and then see what was affordable – this would have set more realistic expectations • The winning price of £1m was £700k lower than the next price and fully 1/3 of the other prices – might it not have been more prudent to explore the offer at around £1,7m?

6. Acquisition decision • LAS ignored Staffordshire Fire & Rescue ’s reference? • Staffordshire warned that Systems Options were overstretched and were having difficulty meeting deadlines • Why go to the trouble of obtaining references if you are going to ignore them? • On top of that, Systems Options was given the lead role • LAS had no permanent members on the project team – this is nothing short of reckless • DHA – no representatives on the WAIO project • No internal skills to participate • No oversight • All left up to consultants

7. Analysis Managing for success • Imposed deadline • Wilby was not an IT person and shouldn’t have been party to the setting of such a deadline – in fact he ignored Arthur Anderson’s recommendation to increase the time span • Deadlines should never be imposed – they should always be negotiated • Setting unrealistic or arbitrary deadlines is one of the biggest causes of project failure • This doesn’t mean techies have the right to set unrealistically conservative, but their opinions should be sought • Team leaders who are responsible for delivery have the right to negotiate the deadlines (and so on up the chain) • Clearly 8 months was inadequate to implement and test such a complex system – particularly when Arthur Anderson had said 19 months for purchased system – more for built!!! • Why pay for an opinion if you are going to ignore it? • While the LAS systems were inefficient, they were not broken – there was no need for the system to be implemented with such haste

8. Managing for success • Divide and Conquer • The system was to comprise three “modules”: • Computer Aided Dispatch (CAD) • Computer Map Display (CMD) • Automatic Vehicle Location System (AVLS) • Phased approach • Why were these systems not designed such that they could be implemented and tested separately and integrated only when they were working adequately? • Had they taken this approach, the first module probably could have been rolled out in time with the subsequent modules following at appropriate intervals • Many problems arose because they were ultimately implemented independently with printers et al having to be connected, but not tested as they were not expected to operate in a stand alone environment?

9. Managing for success • Project Management • PRINCE is the project management methodology that is required by the UK public sector • Given that LAS as well as its suppliers had no expertise in PRINCE, why did they not get an expert from a government department, or contract someone from the private sector • There was already an unrealistic project implementation time - why compound matters by having to learn the project management methodology? • Clearly PRINCE was not working – only in December did they realize the project wouldn’t be ready by January! • Where were the LAS members on the development team – why wasn’t Cromwell ( the analyst) more involved?

10. Managing for success • Turning a blind eye • LAS recruits Brent Carmichael as new systems manager • “His report recommended that the planned implementation date should not be changed (in order to maintain pressure on the suppliers), although it recognized that the deadline might not be met” • Keeping people in the dark is unproductive – far better to manage the situation and set expectations appropriately

11. Managing for success • Change control procedures were ignored • Unless a project is being developed as a prototyped project, the team does not have the right to arbitrarily add ad-hoc user requests - particularly when the project is running late • As the person who is ultimately responsible for the project’s delivery, it is the project manager’s prerogative to approve or disapprove add-hoc changes

12. Managing for success • Testing • Insufficient time had been set aside for testing – a direct consequence of the imposed deadline • One problem inherent in the big bang approach is that it is impossible to test the system from beginning to end until development has been completed • Given the pressure the development team was under, there was no way the system could be tested adequately • No mention was made of unit testing – this is possibly a reason so many things “broke” under pressure • No mention was made of load testing – the consequences of this were apparent when the system went live • The system was not properly tested in with respect to: • Functionality • Operation under load • Integration of modules • “Script” based testing crucial for a big bang approach – one tweak can destabilize the entire system

13. Managing for success • Training • Poor project planning resulted in training taking place too soon which resulted in Skills Decay

14. Managing for success • October release • System had never been tested under load • A vicious cycle was created • As load increased, the system slowed down • As the system slowed down repeat calls came in • These repeat calls in turn slowed the system even more • November – lock up • The lock up in November resulted from a minor mistake which was not detected because of inadequate testing • The fact that the fall back to the second server had not been implemented compounded matters

15. Analysis COTS versus Open Source • No mention was made of an attempt to find open source components that might have lightened the workload • While is possibly true that such component did not exist, should they have existed, they might have taken some of the pressure off the development team

16. Analysis Ethics & privacy • Ethics • LAS • LAS knew that failure could result in loss of life – was it ethical for them to embark on what they knew “… was always going to be a high-risk venture” • Hiding the fact that the project would be late from the team was unethical and unproductive – lying to the team was not constructive • Consortium • Why did the consortium “mislead” LAS when it was apparent time would be an issue? • Why did Systems Options not address the issue that they were under resourced? • The consortium should never have allowed an unready system to go live