London Ambulance Service Computer Aided Dispatch (LASCAD)
What are the major problems with the design and implementation of the system? The main objective of the LASCAD software application was to leverage the power of automation to provide better/improved service to its end users (patients and their relatives in this case) as the existing manual process was deemed time consuming and error prone We know from the caselet that all stakeholders considered the implementation of LASCAD a failure. Though the question is about the flaws in design and implementation that led to this failure, we will take this opportunity to discuss all the broad reasons over the entire SDLC that caused this failure. For large system implementations like LASCAD to fail, the reasons are far more complex and greater in number than design flaws and implementation errors. Moreover wrong decisions at any step seem to have a corresponding adverse domino effect on subsequent steps and this leads to a vicious circle of both manual and automated processes going wrong leading the system to behave incorrectly/incoherently and lastly hang/jam/become unusable in case of LASCAD The first major root cause for the design/implementation to go wrong was the "high unrealistic expectations" the LAS management had of this application. They wanted a fully operational system by a date (Jan 8, 1992) that was not estimated taking into account both the scope and technicalities of the application, the steps involved in development and testing ahead of deployment and time required for each of them. The management turned a deaf error to the concerns raised by several vendors that this date was impractical and not feasible. The second root cause was the commercial/political pressure to award the contract to the lowest bidder and not necessarily to the one who is most qualified to do it. It is now known that the consortium that won the contract had quoted a substantially lower price than the closest competitor. The fact that the vendor had no prior experience in CAD applications was also overlooked in the zeal to award the contract to the lowest bidder We thus had an inexperienced vendor working on this critical application, under significant time constraints, without fully understanding the finer details of the business problem he was trying to address. In light of this background, let us now understand the several shortcomings of the System Options team (the corresponding incorrect choices made and their impact) through out the system development life cycle as well its deployment phase, with respect to LASCAD One: Incorrect and Incomplete Requirements Gathered
While developing the SRS of the application, it is both important and imperative that the team meets all users (actors in terms of "use case" paradigm) of the application to understand how they plan to use the system, what inputs shall they provide, what outputs shall they get and what are the business rules governing the functionality they are associated with, which in turn will help them identify the required changes in their work related processes as well Ambulance crews are one of the most critical users of this application as it is they are the face of the LAS from a patient's perspective, for whom this application was being developed Unfortunately due to some union issues, though a letter inviting them to necessary meetings was sent out, representatives from this set of users never attended these meetings and their perspective of requirements was never captured. This I deem is a major flaw as this led to incomplete requirements gathered in some sense. If representatives of various user groups (call takers, resource allocators, ambulance controllers, staff that operates the ambulance) were made mandatory reviewers/approvers to the SRS, a more complete set of requirements could have been gathered. The challenge was that key consumers of the application never validated that there is some chance that the...
Please join StudyMode to read the full document