Project managers to the rescue
Could project management methods have saved this Australian ambulance dispatch system?
Projects die every day, often the victims of malpractice. When the Metropolitan Ambulance Service (MAS), Melbourne, Australia, attempted to procure a state-of-the-art emergency dispatch and communication system, consultants delivered the project according to an aggressive two-year deadline. But within days, MAS was experiencing severe performance problems. The contract cost the service AU$38.7 million from 1994 to 1996—well above the original AU$32 million.
The case, with analysis provided by Middlesex University's Software Forensics Centre, London, U.K., highlights the inability of sophisticated technology to overcome human and organizational missteps. Arguably the biggest factor in this high-profile troubled project was the lack of adequate project management methods. A project manager would:
ENSURE PROPER PLANNING AND REALISTIC SCHEDULE MILESTONES.
The breakthrough system would have been a quantum leap in technology. Under intense public scrutiny, MAS management decided that all the benefits and full functionality could be delivered in a single-shot implementation. With such untried technology, however, this was unrealistic.
The cost and time limitations imposed on the effort constrained the development process. An inexperienced team with poor management, information technology and procurement skills selected a consultant. No attempt was made to check the bidders' track records or ability to perform.
MAS provides emergency medical transport, prehospital care, and non-emergency stretcher and clinic car transport services for 3.5 million people throughout the Melbourne metropolitan and Mornington Peninsula regions. The service includes 62 emergency response locations, 763 staff (excluding non-emergency contractors), 56 emergency ambulance teams and 218 vehicles.
ESTABLISH A REPORTING CHAIN AND MONITOR PERFORMANCE.
Lack of a MAS project sponsor and experienced project leaders on the consultant side also may have led them to accept impossible deadlines at the expense of quality and reliability.
DETAIL A RISK MANAGEMENT PLAN AND CONTROL SCOPE CREEP.
Most management decisions were driven by the need to improve performance and response times quickly, so the team accepted many risks. Major assumptions went unchallenged, and group decisions about values and costs “anchored” perceptions. The unrealistic deadline should have been challenged and explored because novel solutions equate with high risk.
GUARANTEE ACCOUNTABILITY THROUGHOUT THE EFFORT.
The entire system never was tested fully under operational conditions, and there was no form of independent quality assurance. When serious problems became apparent, team members were instructed to abandon testing. To avoid further embarrassing failures, the team was allowed only to ask questions but was denied access to the equipment. An incomplete system was released with a number of uncorrected critical, yet “approved” software bugs.
HANDLE PEOPLE ISSUES AND GAIN BUY-IN.
Neither the system nor its users were ready for full implementation. The early MAS system became operational without appropriate discussion on staffing, new duties and responsibilities, health and safety, training or ergonomics with user representatives. The result: Ambulance crews, control room staff and unions didn't fully trust the new system. Many staff members concluded that their skills and experience no longer were needed and became unmotivated.
Above all, high-tech implementations require significant attention to the people in the system. Communication, end-user involvement and expectation management inspire buy-in for new systems. A project management professional could have focused on relationship management and outsourcing risk management.
After a lengthy inquiry into the purported mismanagement, what could have been the world's first fully privatized emergency dispatch system remains a less efficient ambulance service plagued with technical glitches. PM
If you know of a troubled project in a which a project manager could have (or did) save the day, share your lessons learned. Contact us at firstname.lastname@example.org.
FEBRUARY 2004 | PM NETWORK