Reviewing The Issues Of Software Systems Information Technology Essay

In this paper I am particularly focus on the issue of failure in relation to that group of software systems known as information systems. Then I am going to discuss two well-known cases that of the London ambulance service computer-aided dispatch system (L ) project and The London stock exchange (TAURUS) project, and describe strong failure factors of information systems failure. My purpose is also to use the generic material on IS failure and the specific details of this particular case study to critique the issues of safety,

Literature review

Like most computing professionals in the UK we were aware of the failure, using this term broadly, of the computer aided dispatch (CAD) system deployed by the London Ambulance Service (LAS) in, or shortly after,

For orientation a short sketch of the report follows. There have been a number of other analyses of the LAS CAD system failure of which Mellor (1994) is probably the most useful.

The London Ambulance System Disaster, 1992

Overview

The basic functionality of the intended LASCAD system was as follows: British Telecom (BT) operators would route all 999 calls concerning medical emergencies as a matter of routine to LAS headquarters (HQ) in Waterloo. 18 HQ ‘receivers’ were then expected to record on the system the name, telephone number and address of the caller, and the name, destination address and brief details of the patient. This information would then be transmitted over a local area network to a locator.

“The system was lightly loaded at start-up on 26 October 1992. Any problems, caused particularly by the communications systems (such as ambulance crews pressing the wrong buttons, or ambulances being radioed in black spots), could be effectively managed by staff. However, as the number of ambulance incidents increased, the amount of incorrect vehicle information recorded by the system increased. This had a knock-on effect in that the system made incorrect allocations on the basis of the information it had. For example, multiple vehicles were sent to the same incident, or the closest vehicle was not chosen for dispatch. As a consequence, the system had fewer ambulance resources to allocate. The system also placed calls that had not gone through the appropriate protocol on a waiting list and generated exception messages for those incidents for which it had received incorrect status information. Indeed, the number of exception messages appears to have increased to such an extent the staff were not able to clear the queue. It became increasingly difficult for staff to attend to messages that had scrolled off the screen. The increasing size of the queue slowed the system.”

Factors Contributed to Such a Disaster

Managerial failure

Technical failure

Human failure

Managerial failure

LAS management ignored or chose not accept advice provided to it from many sources outside of the service on the time table or the high risk of the comprehensive systems requirement

The project did not show, or discuss with, the LAS Board independence references on the lead CAD contractor, that raised doubts on their ability to handle such a major project

The LAS boards were given a misleading impression, by the project team of the previous experience of the lead contractor in emergency service system

In awarding the contract for CAD to a small software house, with no previous experience of similar systems, LAS management were taking higher risk

Project management throughout the development and implantation process was inadequate and at times ambiguous. A major system integration project such as CAD requires full time. Professional, experienced project management, this was lacking

There was incomplete “ownership” of the system by the majority of it users. The many problems identified with many of the system components over the preceding months had installed an atmosphere of system destruct in which staff expected system to fail rather than willing it to succeed

LAS board and RHA management, whilst realizing that there were continuing problems with the implementation of CAD, consistently accepted assurances from executive directors that problems were being rectified and that successful implementation would be achieved at no time was a full independent review commissioned of the true state of the project

Technical failure

LAS fail to follow the PRINCE project Management Method in the set up and operation of an information Technology (IT) executive committee, project board, project management team and project assurance team: London Ambulance Service

The CAD system relied on near perfect information on vehicle location and status being available to it at all times. The project team failed to appreciate fully the impact that a higher level of imperfection would have on the system

The system was not fully tested to a satisfactory level of quality and resilience before full implementation on 26 October 1992

On 26 and 27 October 1992 the computer system itself did not fail in a technical sense. Response times did on occasions become unacceptable, but overall the system did what it had been designed to do. However, much of the design had fatal flaws that would, and did, cumulatively lead to all of the symptoms of systems failure

On 4 November 1992 the system did fail. This was caused by a minor programming error that caused the system to “crash” The automatic change over to the backup system had not been adequately tested, those the whole system was brought down

Human failure

Training provided to CAD staff and to ambulance crews was incomplete and inconsistent

LAS management consultancy attributed CAD problems to willful misuse of the system by some ambulance crews. There is no direct evidence of this, but the circumstantial evidence that does exist indirect to the Inquiry Team that it would have been only one of the many contributory factors that led to the CAD failure

In the period leading up to an including 26 and27 October 1992 there were insufficient control assistants taking emergency call. This contributed to an unacceptable level of calling times. This has since been rectified

Conclusion

Failure was due to a complex mix of factors

Participation alone is not sufficient but helps!

Expectation of failure plays a part

does not meet the needs of the stakeholders

Systems should strive to meet the shared goals & needs of the different stakeholders

LONDON STOCK EXCHANGE (TAURUS) FAILURE

Introduction

The London stock exchange is one of the largest stock exchanges in the world with numerous foreign listings as well as British organizations

In 1989 the London Stock Exchange (LSE) put forward a proposal for a computerized system to ensure that share certificates and cash changed hands between the interested parties after the trading transaction; implicit in this was the dematerialization of stock certificates. It was a big project with hundreds of staff contracted in and lots of external pressures from various different stakeholders.

The initial goals of the system were 4 folded.

Competitive

Efficiency

Cost

Service

What TAURUS Team did wrong?

Lack of executive and stakeholders support

Based on the problems encountered it seem that the project manager was not that experience

Have a large expanding scope

Went ahead with the implementation of a system with lack of user and stakeholder’s commitment.

Lack of skilled resources and clear complete specs.

Reason for TAURUS Collapse

Poor monitoring and controlling

Monitoring a project work includes collecting, measuring, and disseminating performance information. If TAURUS management had good monitoring and control practices they would have known when they project was not meeting project objectives

Poor management of the nine project management knowledge areas

Knowledge Areas

TAURUS project managers managed the nine project management knowledge areas poorly

Scope: If they had managed the scope of the project effective the huge scope creep would not have been encountered.

Cost: If this was managed effectively the project would not have gone over budget 100%

Time: If this area had been manage effective the project would not have had a schedule overrun by 100%

Quality: If the quality area of the system was manage properly the specification was have been clear and complete

Risk: If the risk had been managed effectively they might have been able to abundant the project earlier.

Communication: If communication was managed all changes and delay would be communicated in a timely.

Human resources: skilled resources would be acquired and utilized.

Integrated Change Control

If TAURUS had an integrated change control they might have been able to influence the factors that create changes to ensure that changes are beneficial and control the scope of the project.

Changes would be communicated to top management and steering committee in a timely manner and they would be able to manage these changes as they occur because change control is a critical success factors.

Project Management Issues

Poor Management of triple constraints

SCOPE

TAURUS managers failed to control and monitor the scope of the project

TIME

Management failed to define maintain and utilize clear timetables with small milestones

COST

Management failed to maintain and track change to the project budget

Additionally, the budget and time constraints of the projects were seen to be a differentiator to their success. Goulielmos (2003) states that of the four concepts of failure in Information Systems is process failure where the project over runs its budget or time constrictions. TAURUS did both incurring increasing media attention and scrutiny, which led to an increase in pressure on the project team (Head, 2001).

Conclusion

Throughout the project there were several warning signs that were missed.

The project completion date was delayed 100%

Constantly changing requirements

Project not being accepted by major stakeholders

Incomplete specifications

100% over cost.

Fragmentation of the project (components to work together)

Appraisal of leading system development methodologies

Waterfall Model

This is the most common and classic of life cycle models, also referred to as a linear-sequential life cycle model.  It is very simple to understand and use.  In a waterfall model, each phase must be completed in its entirety before the next phase can begin.  At the end of each phase, a review takes place to determine if the project is on the right path and whether or not to continue or discard the project.  Unlike what I mentioned in the general model, phases do not overlap in a waterfall model.

Waterfall Life Cycle Model

Advantages

Simple and easy to use.

One of the main advantages of the waterfall model is its simplicity. It is conceptually straightforward and divides the large task of building a software system into a series of cleanly divided phases, each phase dealing with a separate logical concern. It is also easy to administer in a contractual setup-as each phase is completed and its work product produced, some amount of money is given by the customer to the developing organization.

The project management stakeholders are forced to correctly define the business requirements documentation (BRD) and the project management requirements. At the sometime the developers are forced to understand these thoroughly before they start writing the software requirements specification (SRS), high level design and code.

It essentially requires documentation at every stage. This gives better understanding of the requirements, the logic of the codes and tests that were conducted on the software. 

Disadvantages

The project scope statement needs to be detailed in infinite depth from the start because changes are not possible when using waterfall methodology. This is because the only way to amend something which has been already developed is to go back and start again. This will cause huge problems on projects where the project sponsors are indecisive and quickly causes scope creep.

Project communications with the client are extremely limited being either at the beginning or at the end of the development. In between, there is no way in which one can get feedback or potentially clarify any confusion over what the requirement actually means. The knock on effect is that it is up to the project team to make the key decisions on what requirements can be developed within the timeframes required, and what is developed later in a later deployment release by project planning in teams. This not only increases the overall time required to develop the software but also means that despite the team’s best efforts, the customer may still be extremely unhappy with the end product delivered.

Key team members stay idle for long durations. You see Waterfall does not operate on a matrix basis which makes project resource management an extremely rigid activity. Basically those allocated to the project stay on it until that phase is over. This as we can imagine, has a direct knock on effect on the project budget.

It is a very inflexible method which does not entertain any change in requirements and which makes any subsequent functionality changes required extremely difficult and expensive to implement. As such the fast pace of changing requirements determined makes this methodology difficult to use and calls for more quick methods of software development such as agile methodology.

Prototyping Model

This is a cyclic version of the linear model. In this model, once the requirement analysis is done and the design for a prototype is made, the development process gets started. Once the prototype is created, it is given to the customer for evaluation. The customer tests the package and gives his/her feed back to the developer who refines the product according to the customer’s exact expectation. After a finite number of iterations, the final software package is given to the customer.

In this methodology, the software is evolved as a result of periodic shuttling of information between the customer and developer. This is the most popular development model in the contemporary IT industry. Most of the successful software products have been developed using this model – as it is very difficult to comprehend all the requirements of a customer in one shot.

Advantages

For example, design documents, a test plan, and a test case specification are not needed during the development of the prototype. Another important cost-cutting measure is to reduce testing. Because testing consumes a major part of development expenditure during regular software development, this has a considerable impact in reducing costs. By using these types of cost cutting methods, it is possible to keep the cost of the prototype to less than a few percent of the total development cost.

Overall, prototyping is well suited for projects where requirements are hard to determine and the confidence in the stated requirements is low. In such projects where requirements are not properly understood in the beginning, using the prototyping process model can be the most effective method for developing the software. It is also an excellent technique for reducing some types of risks associated with a project.

Agile Methodology

Agile methodology is an approach to project management, typically used in software development. It helps teams respond to the unpredictability of building software through incremental, iterative work cadences,

10 Key Principles of Agile Software Development,

Active user involvement is imperative

2. The team must be empowered to make decisions

3. Requirements evolve but the timescale is fixed

4. Capture requirements at a high level; lightweight & visual

5. Develop small, incremental releases and iterate

6. Focus on frequent delivery of products

7. Complete each feature before moving on to the next

8. Apply the 80/20 rule

9. Testing is integrated throughout the project lifecycle – test early and often

10. A collaborative & cooperative approach between all stakeholders is essential

IT/IS Projects Fail. And How Agile Principles Help

Common cause of failure

How agile helps

Project Initiation & Planning Issues

Poor definition of project scope and objectives

Agile projects also benefit from clear definition of scope and objectives, even though details are allowed to emerge throughout the development.

Insufficient time or money given to project

If only agile could solve this!

Long or unrealistic timescales; forcing project end dates despite best estimates

Agile projects encourage short and regular iterations, developing the software and delivering working product in small bite size pieces.

Technical & Requirements Issues

Poor or no requirements definition; incomplete or changing requirements

Agile projects expect requirements to be incomplete and changing. That’s the nature of software. Instead of resisting this, agile projects provide for it by allowing requirements are allowed to emerge and evolve. Requirements being produced on a feature-by-feature basis, just in time to be developed, help with definition because it breaks this intensive task into small pieces instead of being a mammoth effort up front.

Unfamiliar or changing technologies; lack of required technical skills

Agile methods don’t help directly with this issue, although can help to surface such issues early, and make them visible.

Stakeholder Management & Team Issues

Inadequate visibility of project status

Agile projects provide clear visibility of measurable progress on a daily basis.

Project team members lack experience and do not have the required skills

Agile principles may help to surface such issues early, as they may well be evident in early iterations of the software. Frequent delivery of iterations and continuous testing can help to mitigate this risk when it might otherwise go unnoticed until much later in the project.

Poor collaboration, communication and teamwork

Close cooperation and collaboration between all stakeholders is essential.

Project Management Issues

Weak ongoing management; inadequately trained or inexperienced project managers

Agile methods and principles are just management tools. A fool with a tool is still a fool!

Ineffective time and cost management

Daily visibility of measurable progress.

Conclusion

The most Causes for Software Projects to fail Changes in Requirements

Classical Software Development life cycles assume that the requirements are fixed at the beginning of the project, Customer only sees the product at the end of the software development, Customer is not aware of the current status of the Software Development. This happens due to changes in the Business environment, as the customer uses a software module, he/she will see new features that are necessary

All modern software development methodologies (such as Agile) encourage shorter iterations, usually iterations are measured in weeks, and the developers demo the new features during the meetings with the customer at the end of each iteration. The customer can provide valuable feedback that will ensure that the software developed will meet the customer’s actual requirements.