Show me the money

An application and policy system of a medium-sized multi-line insurer is to be modernized. Over 40 years of growth and well-deserved gems of core application IT are to be given a dignified send-off to the software museum. They are too cumbersome in today's VUCA world, and too few people have mastered their outdated languages, development patterns and architectures. It is time for a fundamental overhaul. The operational risks increase with every year of continued use. Departments, IT, company management and consultants have jointly decided on a specific platform stack, which is largely cloud and SaaS-based; however, some components should continue to run on-premise for regulatory reasons. In several short proof-of-concepts, it was verified that the platforms meet the functional and technical requirements - both on their own and in combination with each other. Now it is a matter of budgeting and obtaining the approval of the Management Board and the upstream investment committees.

While it was immediately clear to everyone involved that an agile SCRUM approach tailored to the organizational needs of the insurance company should be the methodology of choice, the usefulness of financially prudent waterfall-style planning was also undeniable. After all, insurance companies have risk aversion in their DNA - and in their regulations. The paradigms alone do not seem to fit. How can a budget be specified and risks and mitigation measures identified if the full scope of the functional requirements are not yet known before the project begins? As every IT manager and CIO knows, the devil is in the detail. And several devils together can create a project hell that can quickly turn into a spending pit - a well-known pattern of many failed projects.

Essentially, these two approaches, agile and waterfall, do not appear to be compatible. While agile development develops its strengths by implementing the requirements in parallel to their specification, as it were, and thus testing them in practice, and the scope of functions grows incrementally ("Rome wasn't built in a day either"), the waterfall methodology conveys an apparently high degree of security and reliability thanks to its comprehensive planning process prior to implementation. The latter is particularly important for project budgeting, which is practiced in many places. The release of funds requires a certain amount of planning.

How can this supposed contradiction between agile operations and waterfall-oriented financial planning be resolved? The following solutions can be considered:

Those who fail to plan, plan to fail (Lenin)

Alternative 1: The obvious approach would be to specify as many functional aspects of the technical implementation as possible before the start of the project and to carry out cost and risk assessments based on comparable experience. The security aspect would probably be seen as a major (superficial) advantage: Everything has been considered in the best possible way before even one implementation activity is started, and the best possible decisions can be made before the project begins. However, the major disadvantage of this solution is that, firstly, any theoretical specification is quickly reduced to absurdity by new findings or problems that arise in practice, while the planning time that is then largely obsolete can no longer be made up for. Secondly, experience from past projects is only valuable if there is no technical caesura in which completely new platforms and technologies are to be used.

Each thing should only receive as much attention as is appropriate to its content (Aristotle)

Alternative 2: Design to Aspiration(quality, time and budget) could be another option. Based on all available facts, assessments and references, an ambitious top-down target is set in terms of time, finances and scope of functions, which must be worked towards. The goal should appear realistic, even if it may be ambitious. If time or budget are not sufficient, the budget is "re-budgeted". Until then, however, it is clear whether the chosen path is likely to be successful. The advantage here is that project management is simple and valid results can be obtained very quickly without having to go through time-consuming planning rounds. The disadvantage of this variant is that it will be difficult to implement a "supplement" in terms of time and money, especially if it is of a significant magnitude. Furthermore, decision-makers may get the impression that they are being motivated by a "salami-slicing" approach to a project whose true scale they would not have agreed to without further ado.

In the long run we are all dead (John Meynard Keynes)

Alternative 3: Value at risk is familiar to every financial controller and financial services manager. Essentially, the question is to be answered as to how high the costs or the loss or the turnover etc. would be if a valid statement with a high percentage were to be made based on statistical data; e.g. how high would the project costs be with 95% certainty, even if significantly lower costs were assumed (on average)? This variant aims for conservative planning and is particularly suitable for comparable projects under known technical and organizational conditions, provided that project controlling has conscientiously recorded the actual values of its projects. The disadvantage of this approach may be very high theoretical (!) project costs if you set your safety requirements very high. In addition, these are usually estimates, as valid statistical values are lacking or are only available with a high degree of uncertainty.

So what to do? None of the approaches is convincing on its own. So what could be more obvious than to take an eclectic approach and combine the most useful aspects of each project planning method into a pragmatic approach?

A project regularly runs in several phases; its artifacts are created in agile increments whose performance is constantly increasing. Why shouldn't budgeting also be understood as a procedure with increasing precision? As a rule, it is not essential for management that the exact expenditure is determined a priori, but whether the company can afford the project and that the desired success is achieved. Consequently, we want to present an iterative budgeting method without frills that consists of three steps.

a. Before project start - triangulation with safety margin: 

Budgeting usually takes place before the project begins. If there are no comparable projects in terms of content and cost, which is usually the case, it is worth taking several practical measures to estimate the cost:

1. Proof of concept: A short, well-prepared PoC limited to manageable but representative use cases is the best way to show how quickly the project can progress. For example, it has been shown that a low-code project is 3 to 5 times faster than traditional software development. This factor is noted down.
2. Reference values: System houses and platform suppliers have a good number of reference customers. Their functional scope and the time required for this with given project members and developers can serve as a second benchmark, provided their services and products are used. Reference discussions also provide valuable insights into any estimation errors made by other users.
3. Recovery value: In replacement projects, various software metrics can provide a good indication of how long it would take to redevelop the existing functionality if the same technology stack were to be used again.
4. Relative estimation: Past software projects, even if they are different in terms of content and other technologies were used, are another reference point. Their cost and duration are known. The order of magnitude in comparison with the project plan can, with good will, at least be put in relation to "T-shirt sizes" (XL, L, M, S etc.). 

These four measures together result in a spread of the expected expenditure and the expected project expenditure derived from this, which is an initial indication. If the value-at-risk method is followed in this phase before project approval, a high value would be set, corrected if necessary by (usually) discounts or surcharges from estimates by experienced developers and project members, and then provided with a risk buffer again. This significantly increases the chance of not exceeding the financially viable framework. It goes without saying that the greater the need for security, the higher the risk buffer should be.

With this amount - or if possible an interval - you can start the budget discussions and aim for a release of funds for a minimal viable product (MVP). In this MVP, a functional prototype should be created that is as small as possible but includes all operational and technical challenges. This is the only way to see whether the technology stack, the approach and the resource situation will lead to success. Theory becomes practice.

b. MVP - Go or No Go

As part of the MVP, several functional increments and, within these, numerous sprints are run through. They offer management an excellent opportunity to compare planned values with actual values and thus improve their own cost and budget estimates. This quantifies their own estimation errors and makes them usable for the new estimates or projections. This method of gaining knowledge must be agreed with management in advance. Otherwise, you run the risk of losing confidence in the project work if your own estimates are revised with every increment. You have to be able to tolerate this flexibility.

At the same time, the surgical progress should be demonstrated live to as large an audience as possible: Do good and talk about it! In this way, decision-makers and users can see with their own eyes how success is achieved and can also provide valuable feedback on the subsequent practical suitability of the product. The worm must taste good to the fish and be prepared correctly as soon as possible.

At the same time, the non-functional requirements, i.e. the technical suitability, are checked. Does the technology stack deliver what it promises? How future-proof is the created solution with regard to the established criteria of a well-architected framework (performance, scalability, security, operation, costs)? Does the project implementation method and the existing skillset fit?

With this evidence, management can decide after the end of the MVP whether to accept the revised costs and use of resources. Thanks to the measurement experience and the cost estimate corrected over several measuring points (increments in this case), the budget comes much closer to a priori planning à la waterfall, even if part of the implementation path has already been covered in the MVP. You already have something "in hand", not just declarations of intent and PowerPoint charts.

c. Roll-out - continuous sharpening

If the management decides against the project, an alternative must of course be chosen. Even then, the experience and concrete assessments from the MVP can be used. If a productively usable release has already been created in the MVP, this is available for further use within the alternative solution.

If, on the other hand, the decision is made to continue the project, the roll-out is now imminent. In this phase, the progress of the project, including budget compliance, is regularly checked by means of a new plan/actual comparison. A monthly interval is recommended in order to keep the administrative effort for the project team to a minimum. In order to resist the temptation of "nothing is impossible" and end up struggling with the realization "too much wanted, nothing is possible", a clever "design-to-time-and-budget" approach is worthwhile during the roll-out: those features are implemented to the extent that they can be adhered to within the time and budget plan. All those developments that do not cause technical debt in the system architecture and are not absolutely necessary from an operational point of view should be postponed until after the roll-out has been completed. This is the time for continuous improvement. You could call this intelligent procrastination.

Finalizing the project on time and on budget has the advantage that work continues to be carried out incrementally and with conscious consideration, rather than suddenly "building Rome in a day" in complete overconfidence or overoptimism. Otherwise, this day will take an infinitely long time and management will have lost faith and confidence in the success of the project before dusk falls. This effectively avoids the fertile conditions for brilliant and expensive failure that are so common to so many projects.

d. Continuous improvement - the evergreen approach

Once the first complete and operationally usable release has been completed and - in the case of modernization projects - the cut-over from the old systems to the new system has been completed, another bon mot applies: The king is dead, long live the queen! The former project has arrived in the continuous improvement process, just as all modern software today is subject to an evergreen approach. From now on, new features are constantly being developed and made available, so that major version changes no longer take place at all or only very rarely - Microsoft 365 is a good example of this.

In this phase, the close cooperation between specialist departments, management and IT has already become second nature. The corporate purpose, range of services and technical implementation go hand in hand. IT has a say in functional issues, while the specialist departments have a say in technical matters. Constructive discussions without glorifying terminology continuously generate new ideas and added value for customers - the prerequisite for entrepreneurial success.

In financial terms, this means that an annual budget is set for the further development of the systems. Further developments and new releases are seen as a "subscription", as is familiar from software-as-a-service: IT is moving away from a CAPEX-oriented approach towards an OPEX-oriented world. "Regularity" should be incorporated directly into the P&L without the detour via depreciation. Expenditure should be spread over the useful life and not be incurred in full after a longer period of time. Providers and customers can plan better financially.

Today, planning and flexibility should go hand in hand in IT projects. Operational agility does not necessarily mean financial unpredictability. An eclectic approach helps to make the cost risk transparent at an early stage and to be able to make conscious decisions about what is achievable. Nevertheless, two important principles must not be overlooked: Competent, responsible and courageous project staff are the most important prerequisite for successful IT projects. The second important prerequisite is stringent and dogma-free leadership of this team - sometimes in detail and hands-on, sometimes with foresight and distance, sometimes motivating, sometimes critical, but always mentally independent and fully aware that mistakes and corrections are part of success.

Business Automatica reduces process costs by automating manual activities, increases the quality of data exchange in complex system architectures and connects on-premise systems with modern cloud and SaaS architectures.