A Review On The CAD System Information Technology Essay

Introduction

The computer aided despatch system was introduced on October 26th 1992 with the aim of improving efficiency, controlling resources and decreasing the personnel requirements of the current London Ambulance System (citation). On October 26th 1992, same day it was introduced, the CAD system failed.

Many literature have come out with reasons how the system failed, highlights of which are (Sommerville, 2004):

Emergency response took several hours,

Communications with ambulances failed and thus they were lost from the system

The system could not cope with the load placed on it during normal use

Serious errors detected in the procurement, design, implementation and introduction of the system.

To fully understand the CAD system failure, one would like to give a short background on the London Ambulance Service.

London Ambulance Service

The LAS was managed by the South West Thames Regional Health Authority but became a National Health Service (NHS) Trust on 1st of April, 1996 (LAS website 2011). It is the largest Ambulance service in the world covering an area of over 600 square miles and a population of over 6.8 million people. On average, the LAS carries over 5000 patients everyday receiving between two thousand and two thousand five hundred calls every single day out of which about 1500 are emergency calls (Sommerville 2004).

CAD Systems

A typical CAD system is shown below:

http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/3.pdf

It mainly consists of a CAD system, a communications interface, Radio system and mapping software amongst others and is used for taking calls, identification, allocation and mobilization of resources.

This CAD system was introduced to replace the manual despatching system previously used by the LAS. Features of the Manual System included (Sommerville 2004):

Call Taking – Calls were recorded on forms and sent to central collection points on conveyor belts. Locations identified on maps.

Resource Identification – Once the form is collected, it is passed onto a region based allocator who decides on what resources need to be allocated, fills this in a form and is handed over to a dispatcher.

Resource Mobilization – this dispatcher communicates with the ambulance station who then sends out the ambulance.

This whole process was expected to take less than three minutes.

http://www.cs.ucl.ac.uk/staff/A.Finkelstein/advmsc/3.pdf

The new system was expected to be fully automated using resources more efficiently. The features include:

A CAD software

A mapping system

Radio communications

MDT terminals in ambulances

Automatic Vehicle Locating System (AVLS)

The specifications stage of a project is the stage at which all stakeholders involved in the project come together to decide on certain key issues some of which are:

Describe purpose, aims and deliverables.

State parameters (timescales, budgets, range, scope, territory, authority).

State people involved and the way the team will work (frequency of meetings decision-making process).

Establish intermittent break-points where progress is reviewed and results measured.

It is clear that the LAS CAD project were not explicit enough in the areas highlighted above. For instance, some of the deliverables for the project were over ambitious. Even though existing CAD systems were investigated, the idea of adapting them was easily discarded as it was not cost effective considering the differences in size of regions. However, no mention was made of investigation of other CAD systems used by ambulance services in large cities anywhere in the world.

In terms of deadlines, a report by Arthur Andersen suggested at least a 19 month time line for the delivery. This report was also discarded and an eleven month deadline was set.

Some other issues include non inclusion of stakeholders in the development of the specifications, non inclusion of intermittent points in the time for project review.

The System Requirements Specification (SRS) was completed in February 1991. It specified the following:

The new system would include computer aided dispatch, computer map display, and automatic vehicle location.

Using CAD software, the completed system would require integration with several other systems, including a computerized radio communication system, an automatic vehicle location system, and a mobile data terminal system with the CAD software.

Key issues

Though SRS called for integration with CAD software, it did not appropriately specify in details, how the integration would be implemented.

The detailed look into the specification also showed that the new LAS CAD system would bring about a total change in the normal duties of staffers in the LAS i.e. call centre and ambulance crew. Unfortunately, these sets of staffers were not a part of the process of developing the SRS.

Apart from the ‘flaws’ highlighted above, the SRS developed by the project owners and the System Design Specification (SDC) reviewed by the project managers was not totally wrong. As for specifications, in spite of the ‘aggressive’ deadline, the project was still considered as doable by 5 of the 17 companies that submitted bids for the project.

Alternative Solutions

One alternative solution in the specification process that sticks out is that the LAS could have given room for the adaptability of other similar CAD systems used by ambulance services in any large and developed city around the world. Adapting a similar technology would have saved time, money and maybe would not have ended in failure.

Another alternative solution in the specification process is breaking the overall project down into different and smaller mini projects making it easier to manage.

Recommendations

The major fault in terms of Specification with the LASCAD project was in assigning the project to an inexperienced and small software company SO. Even though all other requirements of a specification stage were met, they were met in bits and pieces. For instance, they were break points within the project timeline to measure success or failure, these were not enforced as SO kept postponing these deadlines which in itself should have sounded an alarm bell to the project owners.

In all, the pressure to deliver the CAD software within a particular time frame affected the quality and contributed to the failure of the project. Inability to totally enforce the requirements of the SRS and SDC also contributed to the failure of the project.

Project Planning

A project planning stage usually involves the following stages – Project Timescales, the project team, the project critical path analysis, Gantt charts, project financial planning and reporting and project contingency planning.

The contract for the LAS CAD system was awarded to a consortium formed by Apricot Computers, Datatrak, and Systems Options (SO). This consortium had the lowest bid and one of the five companies (out of 17 that submitted a bid) who said they could meet the 11 month deadline. Out of the 11 months, the consortium spent 5 months in developing a comprehensive SRC leaving only about 6 months for the project itself. The short time for project development left no time for project testing which would have exposed the likely problems the system would eventually face had it gone on.

The consortium decided to adopt PRINCE, a methodology they had no real experience in and even though there was training effective use could not be achieved. In addition, as expected in PRINCE, the project owners, LAS, did not assign any member of their staff full time to the project team. Also, an important feature of PRINCE was also not fully implemented – the project did not have a full time Quality Assurance team and only one part time employee performed QA for the project.

In terms of the financials, the consortium bid £937,463 which was about 44% lower than the next lowest bid which can most likely be ascribed to the fact that Systems Options (SO), which was developing the CAD software, was a small software consulting company with no previous experience in CAD systems development.

Key Issues

As can be seen above, there were major issues with not fully implementing the project as a PRINCE project. Using a part time, non independent employee for QA posed a threat to the success of the project.

The question also arises if the right project management methodology was chosen. PRINCE as a methodology is not known to be effective when there is a non flexible deadline as in this case. A methodology more tuned to this is SCRUM.

Perhaps another fault lies in the project contingency planning area. Early on in January 1992 when the project was to be delivered, SO did a partial testing of the system, partial because the full system was not tested. Now these tests did not take into consideration possible system errors and failures as should have been done and thus could not make contingency plans should in case a fault happened in real life. An independent QA team would have properly verified and tested the system if there had been one.

Alternative Solution

In the Project planning stage, an alternative solution would have been the use of a more suited methodology – SCRUM, would have taken into consideration the time and financial constraints. SCRUM breaks the work down into different SPRINTS with every sprint focused on achieving a preset aim. Product owners are not allowed to change the work requirement during a sprint and the aim is to deliver the final product within a specified period of time. Using SCRUM would have delivered the project as at when due.

Recommendations

It is obvious that the PRINCE methodology was not implemented in full. This may have been due to the inexperience of the Project team in using PRINCE and also the need to save costs. A full time, independent QA team should have been attached to the project to ensure adequate testing and verification of the software.

Overall, one of the major reasons the LAS CAD project failed was because it was not executed as a project management task. Even though the managers adopted PRINCE as a methodology, their inexperience in the use of PRINCE was glaring and some of the essential features of PRINCE as highlighted in sections above were either not fully adopted or totally inexistent. It has been said in some literature that if the task had been fully implemented as a project management task by experienced PRINCE users, even with the short timeframe and budget, it may have still been a success.

Conclusion

In conclusion, there are many lessons to be learnt from the failure of the LAS project. These lessons can be viewed from different stages involved in the project. It is clear that proper investigation into what the project will entail was not undertaken or not employed by the project owners – no wonder the project was assigned to the lowest bidders without consideration on the feasibility of the project being executed at this cost.

Also the project owners failed to thoroughly monitor the project all through its development lifespan. Breakpoints in the project planning stage that could have exposed flaws were not properly utilised. This is an area for future project owners to learn from.

For the project managers, one of their failures lies in the fact that they were a small software company and as such had little or no experience in handling such big projects. The project itself was not planned as a project management project and what is more, the correct approach was not adopted. This is clearly down to inexperience.

In addition, the glaring flaw is in the area of lack of expertise. SO clearly did not have expertise in the project management approach they adopted and even though they trained their staff in this area, implementation inexperience affected the planning and delivery eventually.

If the above are looked at and corrected, it will save LAS from future failures.