London Stock Exchange - Research Paper Example

?Project Management: London Stock Exchange Project management is a complex procedure and involves taking into account several different areas (finance, planning, goals) to achieve a set end-result. It does, however, not always go to plan, and there have been many examples of when project management has been the reason why a company or an individual endeavour has gone badly or bust. It is particularly interesting to consider this from a computer science perspective, as often software promises a lot to the company or consumer and can fail to deliver. Failure can occur for many reasons, not least of which is that the project management for the software is bad. This can cost the company (or the public) millions of dollars, which are wasted on 'entirely preventable mistakes (Charette, 2005, p42). A famous example of this is the 'missing warehouse', in which employees were getting paid despite the fact that their warehouse had been erased from the software system (Charette, 2005). Mistakes like this occur frequently within the software industry. The purpose of this paper is to examine one of these major software failures, namely the issues with the London Stock Exchange in 1993. The paper aims to uncover how and why the project failed, and touch briefly on whether these were preventable mistakes and how much it cost the company, the employees and the public. This information can be useful for those planning to become project managers for companies developing software, as well as providing others with a small amount of insight into the damage that a small number of mistakes can make within this industry. The final purpose of this paper is to draw some conclusions about the London Stock Exchange software failure and see if these are applicable to other situations. Overview & Description of London Stock Exchange Project Failure The aim of the Taurus London Stock Exchange Project was to turn stock trading paperless, with the aim of making transactions smoother and more convenient for London Stock Exchange traders (Bergman et al, 2002). The Taurus project started in 1986 from the 'big bang', an event at which the London Stock Exchange was turned into a self-regulating operation which was overseen but not fully controlled by the Bank of England (Keil & Montealegre, 2000). The offshoot of this 'big bang' was that many of the restrictions that were previously placed upon the London Stock Exchange were no longer in place and the Exchange could now enforce rules, regulations and software to improve the service. The United States and Japanese Stock Exchanges were primarily electronic at this time, with the London Stock Exchange taking three to six weeks to complete a transfer and the other international exchanges providing transfers in days (Currie, 1994). The London Stock Exchange needed to move from this paper-based time-consuming style of trading and move onwards into the future, and this was one of the main aims of the Taurus project. Taurus (Transfer and Automated Registration of Uncertified Stock) had the aim of providing a paperless service to the London Stock Exchange and reduce the burden on those in the back office (Bergman et al, 2002). The project had the aim to move to computerized shareholdings which would reduce both time and cost to the London Stock Exchange. Taurus was originally planned to be a software database containing a computerized database of all the investors and shareholders plus their stocks and holdings that operated through the London Stock Exchange as a central operator (Keil et al, 2002). The ownership of stocks would be as simple as an entry into this database, something which is represented by the stock markets of today. There were several aims of the project beyond those mentioned above. Firstly, the movement to a paperless system would remove the need for countless jobs and resources and could potentially have saved the London Stock Exchange millions of pounds. This movement was backed by several prominent economists and politicians of the day, as well as by those residing in the City of London who would reap the most benefits from the successful movement of the project. A secondary aim of the project was to reduce costs for share registrars, who had to work through paper share certificates to provide the appropriate service. Again, this would have saved both time and money and therefore have reduced the need for spends estimated to be in the millions. The project aimed to link 280 financial institutions (Flowers, 1997), including custodians, brokers and registrars, linking them all by an electronic software program that would allow these services to be interlinked. Not only would this facilitate easy transactions and communication between these services, but it would reduce the number of mistakes made at the London Stock Exchange from human error (Drummond, 1999). It would also make trading much faster and bring it into line with that found in America and Japan, two prominent stock exchanges that had already made the switch to a paperless system. Interestingly, the project was not always seen as a failure. The first stage of the project, known as INS (Institutional Net Settlement) was considered a success and was well implemented. This phase had the purpose of being an electronic net settlement system, which essentially gave a paperless means for the institutions to calculate and publicize their collective transactions on any given day (Keil & Montealegre, 2000). This was considered a breakthrough because it allowed for stakeholders to see how their shares were fairing in the marketplace and removed the difficult task of sending out paper receipts of net settlement information where it was required. The Taurus project was eventually abandoned because of massive delays to the software development at an estimated cost to the City of London of over $800 million. The system is now paperless due to the success of a follow-up program known as CREST which was started in 1993 after the demise of the Taurus project (Flowers, 1997). The CREST project has managed to move the London Stock Exchange successfully into a paperless system in which assets can be held in an electronic format rather than relying on paper certificates of ownership (Drummond, 1996). The project had the benefit of hindsight as it could learn from the failures of the Taurus project and was eventually launched in 1996 (Bergman et al, 2002). The following sections of this paper will outline many of the reasons how and why the Taurus project failed, which gave information to those developing the CREST system that is now in place today. How the Project Failed Despite the high expectations of the Taurus project and the initial success of the Institutional Net Settlement system, the project ultimately failed and has been heralded as one of the most expensive software failures to have ever existed. There are a number of ways in which the projected failed, many of which will be explained further in the next section describing why the project failed on so many counts. The first major failure of the project was that it used a piece of originally existing software (Vista Concepts) for its data management (Winch, 2004) that could not handle the distributed data processing and batch processing that were major aims of the Taurus processing. By doing this, there were elements of the program that had to be rewritten and therefore induced delays and issues into the project (Currie, 1994). The project failed here by failing to correctly analyse the needs of Taurus and therefore failing to produce the expected outcomes. This in turn meant that there were issues with the software itself rather than just the project management, and Taurus failed to deliver upon many of its promises and time-scales that were originally suggested. The major example of how Taurus failed is that it did not produce the results in the time-scale quickly. One of the reasons for this has been mentioned above, but essentially the program failed because running over time constraints always means that the budget will be exceeded. This is due to the fact that more manpower and hours need to be put into the project at a cost because the workers will obviously need payment. Another reason that time delays cost so much to software projects is relevant to the Taurus project for the London Stock Exchange. This is that the previously used method that the project seeks to override has to be used for a longer period of time (Currie, 1997). One of the many reasons for developing new software is to save costs to the business, and in this case it was estimated that the Taurus project had the potential to save millions for the London Stock Exchange. By going over the allotted time for the project, the original paper system had to be used and therefore it was longer before any savings could be made on manpower and resources from the switch to a paperless stock exchange (Currie, 1997). The project also failed by not sticking to budget constraints. It was estimated that the total cost of the project was 132 times the projected cost and it was still not completed at this time (Drummond, 1999). An important aspect of project management is sticking to the budget constraints given and then coming up with a manageable solution if this is not possible. Evidently, one of the main reasons how the Taurus project for the London Stock Exchange failed is by not keeping to the suggested budget and this was one of the many reasons why the project ultimately failed which will be discussed in the next section. It has been suggested that one of the main difficulties with IT projects is that it can be difficult to estimate the true cost because there will always be problems in software that cannot be expected (Drummond, 1998). This means that projects need to be more flexible in their budget, which is another reason perhaps how the Taurus project failed and a reason why the subsequent CREST project succeeded (Drummond, 1996). Another major reason how the Taurus project failed is that it ultimately did not provide the service it was projected to do. The first goal of the service was to move the settlement process from paper-based to electronic, which it did achieve. However, the Taurus project did not manage to achieve the advantages of a computerized book entry system of share transfer and allow the 280 participating institutions that were to benefit from this would be able to retain their rights and licenses through this online system. The Taurus project for the London Stock Exchange failed to deliver on this promise and did not manage to tie together all the different elements that it aimed to (Bergman et al, 2002). Why the Project Failed Having covered the reasons how the project failed in delivering promises, it is necessary to discuss why the project failed in more detail to provide a full overview of the project and the project management. Many of the reasons why the project failed were combated by the subsequent CREST project, and thus it is important to cover how the software engineers and the project manager can learn from the mistakes made by the Taurus software for the London Stock Exchange. The first thing that is often mentioned when discussing the Taurus project is that it failed by being over ambitious (Currie, 1997). As previously mentioned, it was originally only intended to move on from the paper-based system of settlements within the London Stock Exchange, but then became promised as a fully electronic share registration and transfer system (Flowers, 1997). This caused problems because the software originally was only intended for the purpose of settlements, and adding other functions meant that the program became filled with bugs. This is often a problem with software when it is extended beyond the original means, because really any software should be written for purpose rather than adding major new features that can leave holes. Another problem with the Taurus system is that it had to conform to several regulations. Firstly the trading system is regulated by a number of processes and laws that had to be incorporated into the program (Currie, 1994) to ensure its legality and usefulness for purpose. Not only this, but the member firms had different requirements and purposes that all had to be standardized as the system was intended to cater for all 280 firms. The reason why the Taurus project failed on this account is that it became increasingly difficult to include all the specifications that the government and the member firms required, as well as ensuring that the program could deliver promises to everyone involved (Drummond, 1998). This is another aspect in which the project could have been said to be overambitious and the project manager could have avoided this problem by setting out the requirements in the early days and ensuring that all members of the software development team were aware of all the regulations that needed to be imposed on the system. It would also have been useful to provide details to each of the member firms and the government agency that provides stock regulatory laws to ensure that any missing gaps in the project could have been identified and filled prior to the software engineering actually starting. As previously mentioned, the system relied on a US program (Vista software from Vista Concepts) for the database processing. This would have been fine if the Taurus project had remained as a real-time online processing tool for settlements, but the Vista software was not appropriate for distributed data processing or batch processing, which is what the Taurus project intended (Flowers, 1997). Because the London Stock Exchange had such high expectations of the Taurus system, 60% of the Vista software had to be rewritten (Bergman et al, 2002). This is such a high proportion that it may have been better to write an entirely different program, but this tactical rewriting left gaps in the program and left it buggy and incomplete. It would have been better for the project manager to identify all the purposes of the program before starting to help analyse which would have been the better original software to base the project on, as leaving it to the software engineers to scrape together extra coding to help maximise the project left major gaps (Currie, 1994). The Vista software originally cost ?1 million, but this entire section ended up costing over ?14 million, a 1400% increase which added significantly to the problems with going over-budget on the project (Bergman et al, 2002). Again, it would have been useful for the project manager to identify this as a possible problem and therefore plan for a possible need for this additional funding prior to the software being developed. Another reason why the project failed has been said to be the communication between the various elements of the project. There was no cross-project evaluation method, which meant that it became unclear who could be held accountable for each element of the project (Drummond, 1999). Interestingly, this can be found to be a problem within many software programs as there are often separate departments for the software itself, the financing and the other elements of the project that are put together to make the whole. There were also two rival management companies involved in the project, which meant that it was fragmented at times (Keil & Montealegre, 2000), again leading to a breakdown in communication within the problem which ultimately led to the demise of Taurus. The project was also fragmented because the London Stock Exchange set milestones for the project which were often missed (Drummond, 1996), and several elements were started before others were finished. Conclusions There are several conclusions that can be drawn from the above analysis of the Taurus project for the London Stock Exchange. The first major conclusion is that it is important in project management and software design to ensure that the project is not over-ambitious. All the requirements for the project should be outlined before it has even begun, and any additions should be covered after the original intentions have been covered if possible. The Taurus project tried to combine too many elements of the stock exchange when it was originally only intended as a settlement program, and this is one of the major areas where the project failed. It can also be concluded that it may perhaps be better to write an entirely new piece of software that conforms to all specifications than relying on existing software, like the Taurus project did on the Vista software (Keil & Montealegre, 2000). Making too many changes can leave software buggy and incomplete and may cause more problems than it solves. It can also be concluded that, whilst it is difficult to estimate the total cost of a software program, it is always better to over-budget than under-budget both with time and money. This means the investors are less likely to get impatient waiting for and paying for projects that are overrunning. The Taurus project overspent massively at a huge cost to the City of London and the London Stock Exchange, and this could have been avoided if the project manager had stuck to the original budgets and plans. Finally it is important to understand from this that it is always useful to look at previous projects to understand how and why other projects failed and succeeded. In this case, the Taurus project was scrapped and replaced by the CREST program which managed to convert the entire process of the London Stock Exchange electronic and remove the need for paper processing (Flowers, 1997) The CREST project succeeded because the limitations of the Taurus project served as an example, and it was not over-ambitious. It must be noted that project managing software design which is intended for such an important purpose can be difficult as different investors will be clamouring for different elements of the project that serve their individual interests. As the London Stock Exchange has to be regulated by different fiscal bodies, it is also important to take these into consideration before starting the project. As an example of software project failure, the Taurus project stands out because it promised so much and ended up costing so much. Works Cited Bergman, M., J.L. King, and K. Lyytinen. “Large-scale requirements analysis revisited: The need for understanding the political ecology of requirements engineering.” Requirements Engineering 7.3 (2002): 152–171. Print. Charette, R.N. “Why software fails.” IEEE spectrum 42.9 (2005): 36. Print. Currie, W. “Computerising the Stock Exchange: a comparison of two information systems.” New Technology, Work and Employment 12.2 (1997): 75–83. Print. ---. “The strategic management of a large scale IT project in the financial services sector.” New Technology, Work and Employment 9.1 (1994): 19–29. Print. Drummond, H. “Are we any closer to the end? Escalation and the case of Taurus1.” International Journal of Project Management 17.1 (1999): 11–16. Print. ---. “Escalation in decision-making: The tragedy of Taurus.” OUP Catalogue (1996): n. pag. Print. ---. “Riding a tiger: some lessons of Taurus.” Management Decision 36.3 (1998): 141–146. Print. Flowers, S. “Information systems failure: identifying the critical failure factors.” Failure and Lessons Learned in Information Technology Management 1.1 (1997): 19–29. Print. Keil, M., and R. Montealegre. “Cutting your losses: Extricating your organization when a big project goes awry.” Sloan Management Review 41.3 (2000): 55–68. Print. Keil, M., A. Tiwana, and A. Bush. “Reconciling user and project manager perceptions of IT project risk: a Delphi study1.” Information Systems Journal 12.2 (2002): 103–119. Print. Winch, G.M. “Managing project stakeholders.” The Wiley Guide to Managing Projects (2004): 321–339. Print. Read More