A lot of organizations are struggling when choosing a project management approach for their legacy transformation project. Agile has been widely advertised as the “one fits all solution” over the last decade, but is this really the case?
Once you as an organisation have decided that a modernisation of the legacy platform is no longer possible and you are launching a legacy transformation project, we first have to establish that any transformation project has the current status of the system landscape as a starting point and an acceptable target area we want to transition to. To get from the current status of our IT platform to our desired target status we can only move in one general direction.
Figure 1 - Target Status
There are two main project management methodologies we can utilize to manage a legacy transformation project in your organisation (and on top of this a sheer endless number of ways to set up hybrid approaches).
Waterfall methodology
The waterfall methodology starts with a meticulous planning phase, where the necessary activities are specified and signed by all parties. The different development phases (Plan, Design, Implement, Test, Release) are processed sequentially with the full scope of the project. After the implementation phase is completed, the testing phase is used to verify if the specifications are met by the implementations.
For projects, where the test phase establishes that the defined and signed specification deviates from the reality of how a company operates, a new target status has to be established and the process has to be repeated to get over the "actual finishing line".
Figure 2 - Waterfall Approach
In short, the waterfall methodology is an approach where all activities have to be specified in detail first, which ensures the architectural integrity and quality of the implementation (if the project is executed with enough know-how on board). Naturally, the more complex a matter, the more complex the task of specifying all activities becomes.
Agile methodology
The agile methodology takes a different approach. There is no overall planning or specification of the target status created when starting with the implementation. Instead, user stories (general descriptions of a feature) and acceptance criteria for them are defined and grouped into epics as a basis for the project. The user stories are then processed in small packages in so-called sprints. At the end of every sprint, feedback is collected from the stakeholders and the next sprint is planned. From the collected feedback, new details or even new user stories and epics can emerge. Graphically depicted the project is starting to move in a direction and gradually “correcting the course” to land at the desired target status.
Figure 3 - Agile Approach
The idea behind the agile approach is that if it is not possible or reasonable to define and estimate the goals in detail upfront, we are trying to achieve an unknown goal with a lot of stakeholder involvement and by iteratively getting closer to it. As soon as all user stories are processed and no new ones are evolving from the stakeholder feedback the project is completed.
In short, the agile methodology is a flexible approach with tight stakeholder involvement and produces a result fast, but with no inherent way of ensuring architectural integrity and quality with a detailed upfront global design.
Implementation Phases - Similar, but different
“According to how it is depicted in some sources, the agile- and waterfall methodology are ‘completely different modi operandi that have nothing to do with each other', but if you take a closer look the only major differences are the amount of scope and the iteration frequency.” - (Kaiss, 2022, p. 141)
With the two graphically very different representations from Figure 2 and Figure 3 above, how dare I say they are similar but just utilise a different frequency? Figure 3 is depicting the aggregated status level of the agile approach. When we are having a look at the individual tasks it becomes clear why this is the case.
Figure 4 - Implementation Phases Agile vs. Waterfall
As illustrated in Figure 4, each user story is processed in the same way (Plan, Design, Implement, Test, Release) as the full scope in a waterfall approach. With every implemented user story the aggregated overall status is iteratively moving closer to a not defined, but still existent, target status.
Figure 5 - Agile Approach Detail
Soley the difference in frequency is the reason for the very different characteristics of the two different variants.
Agile: The pieces of the puzzle are created individually and with only experience-based awareness of other future pieces and the bigger picture.
Waterfall: The full picture is part of the design phase and then divided into small pieces to reach the target in the implementation process.
With insights into the two variants and knowledge of IT systems and IT implementations in general, we are able to draw a few conclusions for the planned transformation project.
Architectural integrity, quality and maintenance
Most of the current theorising about which option to choose is quite one-dimensional. When the differences between agile and waterfall are being discussed, the focus is mostly on the project itself and the time it takes to reach “a goal”. Equally important aspects of your insurance platform, like the quality and maintainability of the produced result, are often completely neglected and not addressed in the discussion.
In the recent past, regulatory authorities like the eiopa also become aware of these factors and have been introducing regulations towards the quality and maintainability of insurance platforms.
“Undertakings should develop and implement a process governing the acquisition, development and maintenance of ICT systems in order to ensure the confidentiality, integrity, availability of the data to be processed are comprehensibly secured and the defined protection requirements are met.” - (European Insurance and Occupational Pensions Authority, 2020)
On top of this, a challenge you as an insurer inherently face during any transformation project is improving the maintenance effort and operational use of the insurance platform. A survey about product development by the Society of Actuaries underlines this and states that even companies with a strong development process, are lacking steering possibilities in the downstream systems, which leads to a lot of maintenance effort there.
“We have a very strong implementation process. It is a large effort due to the large number of systems that get involved … a lot of downstream work …It’s really all in the upfront part that is more within our product development area that we can have more control over.” - (Purushotham, et al., 2017, p. 76)
The fact that the agile approach is not based on detailed specifications and a detailed architectural concept is a big issue for any legacy transformation project. You as an insurer want to introduce a modern (module-based) insurance platform with an insurance product framework. The steering of the whole insurance platform with static product information, and therefore your future time to market and product development costs, is completely dependent on the platform's architectural integrity and the integration of the core systems. Next to the product development process we also have to fulfil the regulatory reporting requirements which are also completely dependent on our enterprise- and system architecture.
Creating a detailed architectural vision and specification before the implementation starts ensures the architectural integrity of the system platform. During an agile implementation, similar to a case-by-case approach [1], we only consider partial aspects when designing our implementations, which makes it very hard to develop the underlying insurance product framework and in fact any framework.
When developing a framework functionality tight stakeholder interaction and short increments are cannot replace a vision and a detailed concept, since there is hardly anything to show and collect feedback upon during this stage of the implementation. With the bigger context being put aside and having a limited area of vision utilised in the design of the individual implementations, it is probable to produce a result that does not support all cross-platform-, quality-, maintainability-, etc. needs.
“With a ‘case by case’-approach we are creating a ‘historically grown system’ artificially.” - (Kaiss, 2022, p. 39)
“Dr. Chris Mattmann, Chief Technology and Innovation Officer (CTIO) at NASA Jet Propulsion Laboratory, told Forbes Advisor that “agile methodology is used more for IT companies, [companies] that fail fast and move fast, types of places where you can proceed in parallel in different phases.” (Hoory & Bottorff, 2022)
Due to this artificial creation of a "historically grown system" on the fast lane, there is a good chance to recreate issues similar to the ones existing in your legacy platform. We do not only want to create "any new insurance platform" fast, but we want your organisation to use "a well-designed platform" for developing your insurance products over the next decades and the systems have to comply with the regulations in the sector. Of course, the development costs of your IT systems and introducing the new platform as fast as possible are also factors to consider, but during the transformation phase, you are at least not competing with the same time pressure as you will be during the creation of new insurance products.
If your goal is to create a maintainable platform with a product-centric product development framework the waterfall approach fits these aspects a lot better. The better the initial concept the better the time to market and the lower the implementation costs when you are using the new platform!
With an agile approach, you either have to be prepared to rework significant portions of our platform in the later stages of the project or to accept architectural flaws, with the attached maintenance costs and slower product development process. Especially the second option might be tough to accept for the insurance platform you are going to use for your operation over the next decades.
“The organisation is exposed to operation-, maintenance-, and extension costs for a significantly longer period, than the initial transformation project. A slow product development process does not only generate additional costs during the maintenance and product development but also for the business departments and indirectly with losing sales to the competition due to the longer time to market.” - (Kaiss, 2022, p. 186)
Accuracy in defining the business needs
Another important aspect of choosing the right approach is the degree it is possible to accurately describe the business needs towards the IT platform [2] and the target area (Figure 6). The challenge here is to identify the tipping point, where the business requirements are too vague to plan and specify the whole project and the project is better off using an agile approach.
The positive sides of the waterfall methodology can only be utilised if we can properly define the underlying requirements. Describing how the legacy system is implemented is not enough, we need to understand the motivation and the purpose of the processes and functionalities. If we are not able to specify them for any given reason, a waterfall approach does not fit the purpose and we are better off working agile. The agile methodology starts to shine, as soon as the target is getting vague.
Conclusion
We have to abandon the idea that there is a “one size fits all” approach, even within a company. Just because an agile project worked fine when e.g. introducing a small customer portal, it does not mean that this is now also the best approach for a big legacy transformation project. Nor is it the case the other way around.
Figure 6 - Agile vs. Waterfall
Being aware of the different aspects of the two methodologies and their consequences is of enormous help when facing a decision. There are a few crucial factors that have to be considered:
Implementation project size
Confidence in defining the business needs correctly and exhaustive
Skill level of the involved stakeholders – not using the legacy system, but for defining the underlying business needs
Skill level of the enterprise architects – technological, technical and functional
Skill level of the implementation teams – technical and functional
Awareness of the regulatory requirements across the complete team (architecture, stakeholder and implementation team)
Quality and time-to-market requirements towards the platform
Due to the differences in approach, the agile methodology is more suitable for projects where innovation is the driving factor and for developing prototypes. With big legacy transformation projects, especially in a sector as regulated as the insurance business, the waterfall methodology appears to be the better choice.
The German regulatory authority BaFin even specifies that:
“Significant changes in the IT systems as part of IT projects, their impact on the IT infrastructure, the organization and the associated IT processes have to be evaluated in advance as part of an analysis.” (Translated) - (Bundesanstalt für Finanzdienstleistungsaufsicht, 2022, p. 23)
Time will tell whether this makes the agile methodology obsolete in the German insurance sector, if hybrid approaches [3] are going to be used, or if an agile form of “evaluation and analysis” will be accepted by the BaFin.
As is so often the case one of the most important takeaways is not to use or do something “because everybody else is doing it”, but to actively analyse and decide which methodology suits the purpose and the organisation best.
A hybrid approach with three layers (Agile Waterfall Agile) appears to be a good start for the workshops and alignments with the customer.
Notes
In such a short read it is impossible to cover all aspects and nuances of the discussion. If you are craving more details and insights feel free to check out my recent publication “Replacing Core Insurance Systems - Learning from the past to be prepared for the future” (especially chapters 1.1 IT System Lifecycle, 1.5 Insurance Product Lifecycle, 1.7 Insurance Product Framework, 1.13 Supervisory Measures and Standards, 2.4 Architecture Vision, 2.15 Agile vs. Waterfall and 5.1 Time to Market), or to reach out to me in the comments or via linked in.
Last but not least, agile is obviously not failing the insurance sector but it is an additional tool to tackle implementations. It has any right to be around for innovative implementation projects and prototypes, where no blueprints exist yet. Agile is just not the answer to every question and sets difficult parameters for a legacy transformation project. Or in other words: sorry for the clickbait :)
References
Kaiss, M., 2022. Replacing Core Insurance Systems. Vienna: s.n., ISBN 9798352709771
Purushotham, M. et al., 2017. Understanding the Product Development Process, s.l.: Society of Actuaries.
Bundesanstalt für Finanzdienstleistungsaufsicht, 2022. Versicherungsaufsichtliche Anforderungen an die IT (VAIT) - Rundschreiben 10/2018 in der Fassung vom 03.03.2022. s.l.:s.n.
European Insurance and Occupational Pensions Authority, 2020. Guidelines on information and communication technology security and governance. s.l.:s.n.
Hoory, L. & Bottorff, C., 2022. Forbes. [Online] Available at: https://www.forbes.com/advisor/business/agile-vs-waterfall-methodology/
[1] The case-by-case approach is implementing one insurance product after the other.
[2] Although we do not know how accurately we can describe the target at the beginning of a project, so we are in fact identifying our confidence in our ability to do so.
[3] E.g. SAP is using hybrid approaches.
Comments