Transformation Projects - A revolution of your IT platform?

Insurers are tackling transformation projects due to various factors identifying the current system landscape as not fit for the (future) operational requirements or/and not economically sustainable to keep modernising and using it.

An important dimension of the business and IT strategy, driving the project portfolio and the project goals of modernisation- or transformation projects, is which type of change the organisation has to implement to stay competitive. Based on the stage of the IT System lifecycle the organisation is currently in, we require different measures and different areas of expertise for the underlying IT platform. On top of this, we also have to be aware of which efforts the necessary changes have attached to them.

Figure 1 - Effort vs. Type of Change

Evolution

During the evolutionary stage(s) of your IT platform modernising your IT systems is sufficient to fulfil your operational requirements and to comply with the regulatory measures of the supervisory authorities. Modernising an insurance platform to stay competitive has normally a small to medium effort attached to it.

Revolution

As soon as your current IT platform is not able to sufficiently support your operation anymore[1], or you want to develop new areas of business, an IT revolution has to take place. Such a revolution can either be achieved by reengineering your current IT platform, or by implementing a transformation project alongside improving the existing business process to adapt to a modern market. Implementing such transformation projects, which are never IT projects alone but will always also affect the whole organisation and its processes, require a lot more effort for their preparation and implementation.

Measures for the different approaches

It is quite obvious that the scope and necessary activities that come along with e.g. a transformation project will always produce more effort than a modernisation due to its nature. On the upside, it also produces more potential for significant improvements in your organisation.

The important thing for the business and IT strategy is, that you are taking into account that both approaches have very different prerequisites attached to them. Expertise in the source and the target system (technical and functional aspects) is essential for any implementation project. This very fact has vastly different implications for the two approaches:

• To modernise a system landscape, your internal IT and business departments are the skilled experts regarding your IT platform and business processes. To get a fresh view or state-of-the-art concepts external consultants and industry experts can support the organisation with new concepts, ideas, and industry experience.

• During a transformation project, you will heavily depend on external know-how, considering that the target platform's technology, to which the organisation are transforming, is completely new to a big part of the organisation. Experts in the field are already aware of the potential obstacles and solutions along the way and are essential for avoiding a failed project. Unfortunately, it happens quite frequently that new and unknown technologies are implemented inefficiently in an organisation, which leads to enormous problems during the implementation project itself, but even more issues during the maintenance and modernisation phases. Due to the complexity of insurance implementations, with dozens of functionalities building on top of each other[2], a point of no return is reached quite quickly and the organisation is stuck with a sub-par solution too expensive to redesign and expensive to use.

Disclaimer & Notes

1. The categorisations in Table 1 are based on the averages for the type of change. Off course e.g. a lengthy refinement of the business processes can fall into the revolution category and on the other hand the introduction of an insurance product framework can fall into the modernisation category. It all depends on the current situation of your IT platform and on the necessary steps to achieve your goals.

2. The "effort" and "improvement potential" shown in Table 1 are predictions. Off course, it is very possible to spend a lot of effort (and budget) on a transformation project and the result is barely maintaining the status quo of your current IT platform. Being aware of the effort and consequences alone is not enough to take the right steps and implement the correct measures to achieve all of your organisation's goals. This is where the experts come in :)

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 on transformation projects and IT projects in general, feel free to check out my recent publication “Replacing Core Insurance Systems - Learning from the past to be prepared for the future” (especially chapters1.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.

[1] e.g. due to new business and supervisory requirements, or insufficient time to market and a slow product development process

[2] (product development process, all downstream systems, regulatory reporting, financial reporting, etc.)

Agile versus Waterfall

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 platform, like the quality and maintainability of the produced result, are often completely neglected and not addressed in the discussion.

If we take the insurance sector as an example, 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 organisation inherently face during any transformation project is improving the maintenance effort and operational use of the system 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 most agile approaches are not based on detailed specifications and a detailed architectural concept is a big issue for any legacy transformation project. You as an organisation want to introduce a modern (module-based) platform with a product framework. The steering of the whole 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 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 platform" fast, but we want your organisation to use "a well-designed platform" for developing your 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 products in the future.

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 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 regulated sector, the waterfall methodology appears to be the better choice.

In the insurance sector, 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.

1. Development of a prototype with an agile approach

2. A waterfall project setting up the platform and the insurance product framework

3. An agile approach again for

   1. additional features

   2. developing the product portfolio.

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.

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 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.

1.3 When do Insurers replace their Core Insurance Platform?

Having knowledge about the different stages of IT systems is the basis for approaching the implementation project in a forward-looking manner. With awareness of the lifecycle and the right technical know-how, the organisation is able to replace the IT systems at the right point in time.

Replacing the systems too late results in a more significant GAP to bridge and a longer period of time where the current IT systems are not receiving new features and updates anymore, while simultaneously the new system platform is not ready yet.

Business need vs. System status

Figure 3 - IT System Lifecycle, Introducing Late - based on (Comella-Dorda , et al., 2000, p. 2)

Stakeholder availability and resistance is a topic in general, but it becomes an even bigger issue the further we enter into the “Noman’s land”. The stakeholders will be struggling, in general, to prioritise their tasks during a transformation project. The struggle is even bigger when having to run the operation with an outdated legacy platform and taking up a leading role in the new transformation project on the business side. With bad timing and planning for the transformation project, trying to improve the situation with a new system platform, will make the situation much worse for the business departments at first.

The process of finding the correct timing is very delicate. Understanding how much time it takes to introduce the new IT systems and anticipating that the business needs are increasing during the project horizon as well gives us a more realistic approach. We also have to factor in, e.g., already known future supervisory measures and planned product launches. Having this on our radar allows us to avoid unnecessarily increasing the risk of poor scheduling and scope creep, both of which are two of the top reasons why IT Projects fail (see 2.1.1 Studies, Guidelines, Best Practises).

References:

Comella-Dorda , S., Wallnau, K., Seacord , R. C. & Robert , J., 2000. A Survey of Legacy System Modernization Approaches. Pittsburgh: Carnegie Mellon - Software Engineering Institute.