The London Stock Exchange is one of the oldest exchanges in the world and currently supplies real-time prices to 90,000 installed terminals in over 100 countries worldwide. (http://www.londonstockexchange.com/en-gb/about/cooverview/whatwedo/marketinfo.htm) One of the most important roles of the LSE is to ensure that share certificates and cash change hands between the parties who have traded and it is this process which TAURUS aimed to computerise in order to reduce transaction time and eliminate the need for ‘paper’ transactions. TAURUS, however, was nothing short of a disaster and it was the failure of this system which led to the successful birth of CREST. It is astounding that two systems implemented by the same company could have such different results and so it is necessary to consider why CREST succeeded where TAURUS failed.
Perhaps one of the main reasons for the failure of TAURUS was that it tried to be “all things to all men”. (Case Study, p.4) By making TAURUS compulsory for all member firms the project team dug itself into a very deep hole because this allowed companies to argue that if they were being forced to use the system they should be entitled to have their businesses processes included in the design. As a result, the system became extremely complex with 21 “Events” such as takeovers being included and even the designers struggled to understand the business requirement. (Case Study, p.4) It is therefore clear to see how the failure of TAURUS came about as if the designers cannot understand the system the program is likely to be written incorrectly and this will clearly cause problems. Furthermore, by attempting to please everyone and do everything the system was destined to become the proverbial “jack of all trades, master of none”. This can be further highlighted due to the fact that CREST took the exact opposite approach and made usage optional. This meant that companies had no leverage over the designers and so could not force changes to the system; thus the system contained only 2 “Events” – substantially less than its predecessor. This meant the system focussed on a small number of processes which were integral to the LSE and carried them out to a high standard – it would appear the design team learnt the lessons taught by TAURUS.
A further reason for the failure of TAURUS is organisational feasibility. Organisational feasibility is important because it includes how responsive people are to change (http://www.wikipedia.org/) and according to Chris Rees the people involved only wanted to maintain the “status quo”. By ignoring this very important fact TAURUS was doomed to failure whereas the CREST team took the time to ask questions which could gauge what needed to be done rather than what had always been done. (Case Study, p.6)
TAURUS again ignored the rules of software development by involving such a large team as the bigger the project, the higher the chances of failure as can be illustrated by failures such as the Fox Meyer’s ERP system. (www.slideshare.net/vinaya.hs/erp-implementation-is-the-challenge/) TAURUS included hundreds of staff and this is clearly a logistical nightmare as there is a huge potential for conflict and for too many adjustments to be made which is what appears to have happened. In stark contrast to this, CREST employed only a team of only 20 to design the programme and 4 or 5 people oversaw the whole project. This allowed for continuity, stability and ultimately a much more successful programme.
In conclusion, TAURUS failed for a number of reasons including its sheer size, the adjustments which were made to the standard package which had been bought from an outside source, the amount of bad publicity it received and its failure to consider organisational feasibility. However, perhaps the most important reason for failure was its attempt to please everybody by doing everything rather than observing the ’90-10’ rule or Pareto principle. (http://www.wikipedia.org/) The system could have been just as effective and come in on time and on budget had this principle been applied as the designers would have realised that there was no need to put so much additional effort into adding only 10% to the program. CREST was a success due the fact that its designers learnt the lessons taught by TAURUS. They focussed only on what was actually required, kept the project minimal and kept morale high. All of these factors led to this project being finished on time and within budget. In other words it was a success.
REFERENCES
Case Study (TAURUS & CREST) pp.4&6
London Stock Exchange, http://www.londonstockexchange.com/en-gb/about/cooverview/whatwedo/marketinfo.htm, accessed 31 October 2007
Slideshare, “ERP – Implementation is the Challenge”, www.slideshare.net/vinaya.hs/erp-implementation-is-the-challenge/, accessed 2 November 2007
Wikipedia, http://en.wikipedia.org/wiki/Pareto_principle, accessed 1 November 2007
Wikipedia, http://en.wikipedia.org/wiki/Feasibility_study#Organizational_Feasibility_study, accessed 1 November 2007
Perhaps one of the main reasons for the failure of TAURUS was that it tried to be “all things to all men”. (Case Study, p.4) By making TAURUS compulsory for all member firms the project team dug itself into a very deep hole because this allowed companies to argue that if they were being forced to use the system they should be entitled to have their businesses processes included in the design. As a result, the system became extremely complex with 21 “Events” such as takeovers being included and even the designers struggled to understand the business requirement. (Case Study, p.4) It is therefore clear to see how the failure of TAURUS came about as if the designers cannot understand the system the program is likely to be written incorrectly and this will clearly cause problems. Furthermore, by attempting to please everyone and do everything the system was destined to become the proverbial “jack of all trades, master of none”. This can be further highlighted due to the fact that CREST took the exact opposite approach and made usage optional. This meant that companies had no leverage over the designers and so could not force changes to the system; thus the system contained only 2 “Events” – substantially less than its predecessor. This meant the system focussed on a small number of processes which were integral to the LSE and carried them out to a high standard – it would appear the design team learnt the lessons taught by TAURUS.
A further reason for the failure of TAURUS is organisational feasibility. Organisational feasibility is important because it includes how responsive people are to change (http://www.wikipedia.org/) and according to Chris Rees the people involved only wanted to maintain the “status quo”. By ignoring this very important fact TAURUS was doomed to failure whereas the CREST team took the time to ask questions which could gauge what needed to be done rather than what had always been done. (Case Study, p.6)
TAURUS again ignored the rules of software development by involving such a large team as the bigger the project, the higher the chances of failure as can be illustrated by failures such as the Fox Meyer’s ERP system. (www.slideshare.net/vinaya.hs/erp-implementation-is-the-challenge/) TAURUS included hundreds of staff and this is clearly a logistical nightmare as there is a huge potential for conflict and for too many adjustments to be made which is what appears to have happened. In stark contrast to this, CREST employed only a team of only 20 to design the programme and 4 or 5 people oversaw the whole project. This allowed for continuity, stability and ultimately a much more successful programme.
In conclusion, TAURUS failed for a number of reasons including its sheer size, the adjustments which were made to the standard package which had been bought from an outside source, the amount of bad publicity it received and its failure to consider organisational feasibility. However, perhaps the most important reason for failure was its attempt to please everybody by doing everything rather than observing the ’90-10’ rule or Pareto principle. (http://www.wikipedia.org/) The system could have been just as effective and come in on time and on budget had this principle been applied as the designers would have realised that there was no need to put so much additional effort into adding only 10% to the program. CREST was a success due the fact that its designers learnt the lessons taught by TAURUS. They focussed only on what was actually required, kept the project minimal and kept morale high. All of these factors led to this project being finished on time and within budget. In other words it was a success.
REFERENCES
Case Study (TAURUS & CREST) pp.4&6
London Stock Exchange, http://www.londonstockexchange.com/en-gb/about/cooverview/whatwedo/marketinfo.htm, accessed 31 October 2007
Slideshare, “ERP – Implementation is the Challenge”, www.slideshare.net/vinaya.hs/erp-implementation-is-the-challenge/, accessed 2 November 2007
Wikipedia, http://en.wikipedia.org/wiki/Pareto_principle, accessed 1 November 2007
Wikipedia, http://en.wikipedia.org/wiki/Feasibility_study#Organizational_Feasibility_study, accessed 1 November 2007
No comments:
Post a Comment