Section 1: Abstract
There have been a significant number of articles on the matter of software project failures. Some focus on the causes leading to those failures and some are about the real world examples along with the analysis of how the improvement could be done. However, those articles are mostly about only one aspect such as a project failure or a project success. Hence, they are not very convincing to say if the same methodology used for a successful project will be effectively applied for another. The reason is that projects are different even when considering the same team in the same environment due to the differences in project nature and stakeholders’ expectation. In this paper, I’m going to present two case studies from Westpac that are completely different in terms of: 1) the outcomes: one is successful whereas the other is a failure and 2) the approaches applied during the course of the two projects. By examining the two cases, one can realise the importance of choosing a right approach to a project.
Section 2: Introduction
Westpac (Western – Pacific) is one of the oldest banks in Australia. It was first established as the Bank of New South Wales in 1817. After the acquisition of the Commercial Bank of Australia in 1982, it changed its name to Westpac Banking Corporation. Westpac, as the result of the Merger & Acquisition process, has numerous legacy systems which are mostly “silo” applications. Besides that, many transaction codes have been repeated across various product systems over the years that led to inconsistencies. In 1987, Westpac publicly launched a project called Core System90 (CS90) as its first entry into the electronic financial services sector (Andrew 2001, p.20). The project was very ambitious with the aims to create reusable building blocks and to facilitate the management with a decision support mechanism. The purpose of the reusable building blocks is to reduce significantly the number of transaction codes from 1800 to less than 50 generic types. A large investment was put into the project with around 300 IT staff at its height plus the overhead bills and salary nearly $A1 million a month. However, the project eventually failed and drained $150 millions from Westpac.
BT Financial Group is a Westpac’s wealth management division including life insurance and superannuation. In 2004 and 2005, there was a legislative change that enabled employees to move super assets among financial firms. As a result of the legislative change, there were a huge growth in the benefits from super accounts and therefore an increase in competition. Facing the difficulty resulted from running five separate superannuation systems, BT decided to re design and develop the legacy systems so that its competitiveness could be improved. In 2006, Westpac again started another project to serve that purpose. The aim of this project is to allow a smooth integration among the silo systems by using new technologies, thereby improving efficiency and customer responsiveness. After approximately 18 months in development, BT Super for Life product was put into use in October 2007 and won the 2007/08 Best New Product category in SuperRatings’ Fund of the Year Awards (Gartner 2008). It was a huge success with sustainable profits. Moreover, it has proved the effectiveness resulted from the great collaboration between IT and Business.
Section 3: Detailed Information
Section 3.1: CS90
During the deregulation period of the Australian banking system, Westpac realised that IT could be used a weapon to compete locally and globally (Andrew 2001, p.20). Furthermore, it recognized the current limitation of its infrastructure that was resulted from the M&A process with inconsistency and repetition of transaction codes. Therefore, Westpac started a project called Core System 90 (CS90) as its first high profile into the electronic financial sector. According to Andrew (2001), CS90 had a set of five applications and a set of development tools as its core. It was always an ambitious project that was to be proved in-house and then sold world-wide.
However, Westpac had faced many obstacles that led to running the project over budget and its eventual termination in 1992. The project has drained $150 millions without leaving behind much to show. As stated by Andrew (2001), the project was technically feasible and the main problem was adapting Westpac culture to the demands of CS90. According to Robert (1992), the project had totally four focused areas: 1) leveraging the concept of reusable components for system development, 2) building product development facility, and 3) a transaction processing facility plus a decision support system that can help deliver the management information to the customer and staff. All of the aforementioned ideas were all about improving straight through processing which had not happened in Westpac because of the isolation of information among various legacy systems. Next, an object oriented approach was employed to implement the reusable components. Matt (2005) said that the concept of object oriented and its implementation were started from the early 1960s. Therefore, at the time of the project development, this concept was not very new and actually was put in use successfully. Having considered the number of talented staff around 300 at the height of the project and the total effort put into it, all the technical requirements should not be some rocket sciences. This is to prove the point that technical difficulties were not the main cause of the failure of CS90. Besides that, Westpac staff was very enthusiastic about the financial benefits so it means that there was a great buy in from the stakeholders.
However, the development staff found it very difficult to collect the real requirements while they were investigating individual bank product. This is quite easy to understand because as mentioned before, Westpac did not have any unified systems. They were actually separate systems that Westpac obtained through the M&A process for many years. In other words, the systems were not meant to interoperate. More technically, a data field in one system could be hardly applied in another system. Therefore, the complexity could have been overwhelming. The politics was also one of the most challenging barriers that resulted in feeding incorrect data to the development staff as addressed by Andrew (2001).
Next, when Westpac partnered with IBM who had expertise in defense projects and dealing with US government departments, new problems arose. The difference in the two companies’ cultures was putting the project far behind the schedule. IBM’s rigid approach and complex system development processes were not suitable for the banking environment because such an approach could not get the buy in from stakeholders and more importantly could not collect the real requirements wherein politics and non documented procedures were a challenge. Finally, according to Andrew (2001, p.20), Westpac policies were so intolerant of mistakes and late delivery so the management had to build up the project benefits to keep funding. Therefore, the effect of CS90 failure had been escalating and become catastrophic at the end.
Section 3.2: BT Super for Life
Constrained by legacy Superannuation systems, BT found it a challenge to improve its efficiency and customer responsiveness. To increase its competency, BT decided to offer a new product called BT Super for life using a new approach to the collaboration between IT and business. This new product also enables other existing super products to be moved to the new technology platform gradually. There are three critical areas in this project: 1) the application development process, 2) the technical architecture of the new system, and 3) achievement of customer centricity (Gartner 2008).
Firstly, BT used a new approach to the application development process. Having recognized the limitations of the waterfall approach, BT leveraged an agile development process with guidance from an external consulting group called ThoughtWorks. With this approach, the development staff did not have to invest a significant amount of effort to capture the requirements, and then analyse them to ensure robustness and consistency. Rather they used rapid prototyping so that the customers can quickly study the system and give their feedback. Based on the feedback, the development team can get a deeper understanding as well as pinpoint what they are lacking. Moreover, an agile approach can be effectively used to cope with the dynamic banking environment wherein requirements keep changing to adapt to the business environment. Next, this approach had changed the landscape of how IT and business collaborate. By splitting up the whole project duration into smaller iterations, the team had made the development process more user-centric. At the end of iterations, business users can participate and review the deliverables. It means that the users are constantly involved in the project and they know the direction the end product is heading to. At the same time, this collaboration helps reduce the risks of software development. For example, during the course of the project, the users review the deliverables and discover that they have missed out a critical feature. They will then have a chance to discuss this problem with the development team, analyse the effect of adding the new feature, decide whether it is worth investing or not, and reschedule the project accordingly. On the contrary, if this happens in a traditional waterfall process, it is often too late for the users to discover and to take appropriate actions.
Secondly, right technologies were used in this project. The concepts of SOA, Web Services and Portal were feasible with the flourish of many providers such as IBM, Microsoft at that time. They helped Westpac to resolve the problem of having multiple legacy systems without the ability to share information. Briefly, Service-Oriented Architecture (SOA) is a style of building systems that allows the integration between different platforms. Thomas (2005) states that it is a model in which systems are composed of smaller, distinct units of logic that can be individually distributed or collectively used to comprise a larger piece of business logic. Hence, leveraging such an approach can help the legacy systems to interoperate. Moreover, with screen element reusability of portal technology, the development time was significantly reduced with the enhanced flexibility (Gartner 2008, p.4). Compared to CS90, the project BT Super for Life had many technical advantages because of the maturity of technology.
Thirdly, customer-centricity was fostered in BT Super for Life project. This made the difference with the “follow home” approach. According to Gartner 2008, the users were observed as to how they managed their paperwork and other activities in normal environments. This approach allowed users to look back to understand their work and know what could be done to improve. Furthermore, based on the observation, the development staff got a deeper insight into the problems and was able to offer the most innovative solutions which the user can adapt to.
Section 4: A right approach to CS90
It is obvious that with the advance of technologies and the maturity of project management, BT Super for Life had more chances of being successful than CS90 did. However, there are still many lessons which can be learnt from the failure of CS90 because from the technical perspective, CS90 team could have fulfilled the project requirements as well. It is fair to say that the only change applicable for CS90 is the project management approach since the level of technology at the time of the project obviously could not change. Based on the lessons learnt from BT Super for Life, one of the possible ways to make CS90 successful is employing an Agile methodology. By changing the approach, the development team could collaborate with the business team and find out the main barriers of the project.
In order to discuss how Agile can work for CS90 project, it is reasonable to first understand the concepts of Agile, the differences between Agile methodology and a traditional system development process such as Waterfall. According to Sanjiv (2005, p.37), Agile management is about keeping the team energetic, empowering them so that they can deliver business values in a rapid and reliable fashion by engaging customers, and adapting to the changing environments/needs. From the concept, there are a couple of key ideas worth noticing: rapid, reliable, user involvement, and adapting to changes. There are tons of tutorials and materials on this subject and this will not be discussed in detail in this paper because it is not the main topic. However, to assist readers in understanding, some personal viewpoints will be addressed based on James, et al. (2003, chapter 8). Agile has some interesting best practices such as short iterations, workable deliverables in each iteration, frequent feedback from users for each deliverable and “just barely good enough” documentation. They are also the differences compared to traditional methodologies. Agile is not about creating lengthy documents and the finest system architecture. Everything is kept at “just barely good enough”. On the other hand; in a Waterfall approach, a rigid documentation system is required, the best system architecture will be produced after the requirement engineering phase. Developers then move on with the implementation and testing. It turns out to be a one-way process that going back stages is not feasible or too costly to be performed, if new requirements are discovered or the team has missed key features when collecting users’ inputs.
With the basic information presented above, there seem to be four reasons as well as four main barriers that an Agile methodology could have been used to tackle with the problems of CS90 project. Firstly, working in a banking environment requires a high level of flexibility. This is attributed to the fast growing nature of business. There was also a limitation resulted from the fact that aggregating multiple discrete systems was one of the main objective of CS90. This effort was really tremendous since a thorough understanding of all the systems and how they interoperated was required. Besides that, sharing information such as how individual bank product worked and benefited was not an easy decision for Westpac management. Therefore, applying a Waterfall approach in such a condition was not appropriate since the development team needs to conduct the requirement analysis at the first place and could not change them later or it would be very costly. However, if an Agile approach is applied, the team can work on small iterations each of which produces a workable version and hence the users can validate the system right after that. Simply put, the team can gradually learn the requirement as the project progresses.
Secondly, Agile approaches could enhance the level of user acceptance. With the end products of iterations, the user seems to have more interests and have more chances to participate in the development by experimenting and giving feedback. This is different from the philosophy of traditional project management which is to collect all the requirements in the first place. This technique appears to be very risky since there are just a few people who can actually define their requirements well as addressed by Scott (2011). Mostly, they are capable of indicating their problems and expressing whether they like an opinion presented to them or not. Therefore, with a big requirement upfront approach of Waterfall model, the users are more likely to not address all their requirements in the first place. As a result, the end system seemingly could not address all the issues and satisfy the user expectation. In other words, even with a successful project produced by traditional approaches such as Waterfall, the results are likely less ideal than expected even though they reflect the specification correctly. This is also the reason Scott (2011) states Active Stakeholder Participation is one of the critical success factors in Agile practices. Instead of figuring out all the requirements at the first place, the development team and the users are given a chance to have the system developed from iteration to iteration, and gradually learn what the real requirements are. Hence, it reduces the user resistance to changes and yields a better intimate experience between the users and the system.
Next, unrealistic expectations could be minimised using an Agile methodology. With rigid documentation and the finest system architecture which could be actually built up by the development team, the stakeholder usually seemed to have a very high expectation as for the potentials of the whole system. Moreover, every project is unique so no matter how much effort was put in place plus the complexity of emergent technologies, the estimation of project duration at the first time seems to be far off from reality (Kathy 2009, p.8). This was probably one of the issues of CS90 project. As mentioned earlier, the delay of CS90 led to the build-up of benefits from the development team to keep funding from the sponsors. On the contrary, for BT Super for Life project, the stakeholders were constantly updated with the status of the project not only with reports but also with workable systems as the end products after iterations. Having tested the real features of the system, the stakeholders of BT Super of Life could realise what could be done and what the impedance of the project was. Based on that, they could make reasonable changes to the scope, budget and timeframe of the project. Likewise, employing an Agile methodology for CS90 project could possibly help the management recognise the real status and obstacles so they could have taken more appropriate actions. Therefore, Agile methodology tends to minimise unrealistic expectations from the stakeholders.
Finally, according to Mike (2007), Agile methods are much better in risk management compared to traditional project management. He also claims that rapid risk identification and reduction are the main reasons. These reasons could be applicable for BT Super for Life project. Since it does not take a long time for the stakeholders to see the end projects after iterations, the chances of misunderstanding requirements and the inability to have errors fixed toward the deadline could be reduced to some extent. Based on that logic, the stakeholders of CS90 project should not have had to postpone until the end of the project to realise it had problems if an Agile approach had been put in use. Rather, they could have mitigated the risks during the course of CS90 project. They could even have called off the project instead of dumping billions of dollars before realising it’s impossible to recover the project.
Section 5: Conclusion
Selecting a right approach to a project is compulsory to the end success. Based on the analysis of the two case studies from Westpac, we can see how important it is and what we should do to manage the project right. There are a couple of reasons that led to the failure of CS90. Firstly, the management staff had a very high expectation ignoring the inherent complexity of combining multiple legacy systems. Besides that, the management approach was too rigid and not flexible enough to be adapted to the banking environment. On the contrary, BT Super for Life had a very flexible approach which can facilitate the communication and innovation between the business team and the development team. In other words, the Agile approach chosen for BT Super for Life was one of the main contributors for its success. There might be more approaches which can be applied in this context of Westpac but Agile methodologies seem to be sufficient enough and actually very promising since there is a growing number of researchers and practitioners who have been studying the variances of Agile approaches and how to put them in use.
Section 6: Bibliography
Andrew, H., 2001, Failsafe IS Project Delivery, Gower Publishing Limited, England.
Westpac, Our history, http://www.westpac.com.au/about-westpac/the-westpac-group/company-overview/our-history/, visited 25 April 2011.
Matt, W., 2005, The Evolution of Object-Oriented Languages, http://www.developer.com/java/other/article.php/3493761/The-Evolution-of-Object-Oriented-Languages.htm.
Sanjiv, A., 2005, Managing Agile Projects, Prentice Hall PTR.
James, et al., 2003, The Practical Guide to Enterprise Architecture, Prentice Hall PTR, USA.
Kathy, S., 2009, Information Technology Project Management 6e, Cengage Learning, Boston, USA.
Mike, G., 2007, Agile Risk Management, http://leadinganswers.typepad.com/leading_answers/2007/09/agile-risk-mana.html, visited 15 March 2011.
Scott, W., Active Stakeholder Participation: An Agile Best Practice, http://www.agilemodeling.com/essays/activeStakeholderParticipation.htm, visited 17 March 2011.
Thomas, E., 2005, Service – Oriented Architecture: Concepts, Technology, and Design, Prentice Hall PTR, USA.
