TAURUS and CREST were two projects aimed at tackling the same issue but with very different philosophies to their approaches. TAURUS was the first project to take on the huge task of creating a computerised system for the London Stock Exchange (LSE) which would ensure that share certificates and cash changed hands between the interested parties after the trading transaction. The dematerialisation of stock certificates would also be embedded in this process. However Taurus was ultimately a failure and was eventually scrapped in March 1993, costing the LSE a massive £75 million. Following this failure, the LSE decided to undertake another project (CREST) as they still required a computerised system. There are a number of vital differences between the two projects and countless mistakes were made in TAURUS. CREST aimed to learn from these mistakes and that is exactly the reason why CREST was successful.
Taurus was a colossal project with hundreds of contract staff drafted in to deal with the design and build. One of the main reasons why Taurus failed was because they wanted to make their system “all things to all men”; they wanted to make their system compulsory and so they also faced pressure from all the stakeholders. Some of these stakeholders were also opponents of the system who would have an obvious conflict of interest. For example, the Treasury stood to lose £800 million per year of revenue from stamp duty if the system was successful. The government involvement with the project resulted in a 150 page legal document which the system would have to adhere to. They took on 21 “Corporate Actions” or “Events” to try and satisfy all of the stakeholders but the downside of this was that the business requirement became too complex and the designers simply could not cope. In contrast CREST usage was optional but anybody could potentially be a user. This was a key issue as this would allow CREST to exclude any opponents to the project. They published a minimalist specification comprising just 2 business processes: stock movement and cash movement (or both). The designers chose these 2 business functions as this would be enough to deal with 85-90% of all transactions. CREST adopted the policy of only including a business function in their design if over 80% of customer representitives in an area demanded it.
TAURUS made another wrong choice when selecting their software for the project. They chose a package from Vista Concepts of New York but this required a great deal of modification in order to cater for all the business functions they required. The project team wasted too much time travelling across the Atlantic, and there were also the obvious risks of using unproven software. CREST decided to write a completely new system but took on the expertise of an IT Manager from the Bank of England who already had experience of building a similar system to what they envisaged. The testing of CREST’s systems was conducted independently, ensuring that the maximum amount of faults could be identified early on as there would be no bias during the testing.
CREST also took a different approach to TAURUS when it came to how the project teams were structured. Whilst TAURUS used hundreds of contract staff, CREST took most of their staff from Admiral Software. There was a 20 strong team and a programming team. A high-level design team of just 4 or 5 managed the whole project. There was plainly too many staff involved in TAURUS and this made project co-ordination impossible. CREST’s approach was much better thought out, far more structured and all teams stuck to their own field of expertise.
On 19 July 1996, CREST’s system went live right on schedule and the team also managed to get the system fully operational earlier than expected. In stark contrast, TAURUS suffered numerous delays and failed to meet their budgets and time constraints. TAURUS was always destined to fail; not because it was too difficult to complete but because they had too many opponents who sought to sabotage the project. CREST learned from past mistakes and very carefully managed to exclude these groups from being involved in their project.
Taurus was a colossal project with hundreds of contract staff drafted in to deal with the design and build. One of the main reasons why Taurus failed was because they wanted to make their system “all things to all men”; they wanted to make their system compulsory and so they also faced pressure from all the stakeholders. Some of these stakeholders were also opponents of the system who would have an obvious conflict of interest. For example, the Treasury stood to lose £800 million per year of revenue from stamp duty if the system was successful. The government involvement with the project resulted in a 150 page legal document which the system would have to adhere to. They took on 21 “Corporate Actions” or “Events” to try and satisfy all of the stakeholders but the downside of this was that the business requirement became too complex and the designers simply could not cope. In contrast CREST usage was optional but anybody could potentially be a user. This was a key issue as this would allow CREST to exclude any opponents to the project. They published a minimalist specification comprising just 2 business processes: stock movement and cash movement (or both). The designers chose these 2 business functions as this would be enough to deal with 85-90% of all transactions. CREST adopted the policy of only including a business function in their design if over 80% of customer representitives in an area demanded it.
TAURUS made another wrong choice when selecting their software for the project. They chose a package from Vista Concepts of New York but this required a great deal of modification in order to cater for all the business functions they required. The project team wasted too much time travelling across the Atlantic, and there were also the obvious risks of using unproven software. CREST decided to write a completely new system but took on the expertise of an IT Manager from the Bank of England who already had experience of building a similar system to what they envisaged. The testing of CREST’s systems was conducted independently, ensuring that the maximum amount of faults could be identified early on as there would be no bias during the testing.
CREST also took a different approach to TAURUS when it came to how the project teams were structured. Whilst TAURUS used hundreds of contract staff, CREST took most of their staff from Admiral Software. There was a 20 strong team and a programming team. A high-level design team of just 4 or 5 managed the whole project. There was plainly too many staff involved in TAURUS and this made project co-ordination impossible. CREST’s approach was much better thought out, far more structured and all teams stuck to their own field of expertise.
On 19 July 1996, CREST’s system went live right on schedule and the team also managed to get the system fully operational earlier than expected. In stark contrast, TAURUS suffered numerous delays and failed to meet their budgets and time constraints. TAURUS was always destined to fail; not because it was too difficult to complete but because they had too many opponents who sought to sabotage the project. CREST learned from past mistakes and very carefully managed to exclude these groups from being involved in their project.
