Every CFO wants to know three things about an IT project: What is the benefit? How much does it cost? What are the risks? If the project sponsor or project manager follows an agile approach, the second point is often very difficult to answer a priori. You also don't know everything about the risks, while the benefits are usually painted in the brightest colors. This does not satisfy "numbers people." On the contrary, they become skeptical and withhold their approval for as long as possible, even when the demand for innovation, automation, and optimization is high and the competition is making life difficult. However, it doesn't have to be this way.
Let’s look at an example from the inherently risk-averse insurance industry, which could have played out in a similar way in any other sector.
An application and policy management system for a mid-sized multi-line insurer is due for modernization. Gems of core application IT, grown and cherished over 40 years, are to be retired with dignity to the software museum. They are too cumbersome for today's VUCA world, and too few people master their aging languages, development patterns, and architectures.
I. The Problem
While it was immediately clear to everyone involved that an agile approach based on SCRUM, tailored to the organization's needs, should be the methodology of choice, the sense of a financially prudent, waterfall-style plan was also indisputable. After all, insurance companies have risk aversion in their DNA—and in their regulations.
The paradigms simply don't seem to fit. How can a budget be defined and risks—along with mitigation measures—be identified if the full scope of functional requirements is not yet set before the project begins?
At their core, these two approaches, Agile and Waterfall, appear incompatible. Agile development derives its strength from implementing requirements in parallel with their specification, thereby testing them in practice. Conversely, the waterfall methodology conveys an apparently high degree of certainty and reliability thanks to its comprehensive planning process prior to implementation.
II. Potential Solutions
How can this perceived contradiction between agile operations and waterfall-oriented financial planning be resolved?
If you fail to plan, you are planning to fail - Lenin
Alternative 1: Comprehensive specification before project start
The obvious approach would be to specify as many functional aspects of the technical implementation as possible before starting the project and to make effort and risk estimates based on comparable experiences. However, the major disadvantage of this solution is that any theoretical specification is quickly rendered absurd by new insights or problems that arise in practice.
Everything should be made as simple as possible, but not simpler - Albert Einstein (Note: The original German text referenced Aristotle, but the sentiment is often attributed to Einstein in this context; keeping the translation faithful to the German text's intent regarding proportionality).
Alternative 2: Design to Aspiration
Based on all available facts, assessments, and references, an ambitious goal is set top-down regarding time, finances, and functional scope. The disadvantage of this variant is that requesting "more" time and money will be difficult to push through.
In the long run we are all dead - John Maynard Keynes
Alternative 3: Value at Risk
At its core, this aims to answer the question of what the costs would be if one were to use statistical data to make a statement that is valid to a high percentage. This method is suitable for comparable projects under known technical and organizational conditions.
III. The Synthesis
A project typically proceeds in several phases; its artifacts are created agilely in increments. Why shouldn't budgeting also be understood as a process of increasing accuracy?
a. Before project start - Triangulation with a safety margin
If there are no comparable projects in terms of content and effort, several practically oriented measures for effort estimation are worthwhile:
-
Proof-of-Concept: A short, well-prepared PoC is the best way to show how fast project progress can be. For example, it can demonstrate that a low-code project is 3 to 5 times faster than classic software development.
-
Reference values: System integrators and platform providers have a good number of reference customers. Their functional scope and the time required for it can serve as a benchmark.
-
Replacement value: For replacement projects, various software metrics can provide a good starting point as part of an assessment.
-
Relative estimation: Past software projects are another reference point. Their effort and duration are known.
b. MVP - Go or No Go
Within the framework of the MVP, several functional increments and numerous sprints are completed. They offer management an excellent opportunity to compare planned values with actual values, thereby improving their own effort and budget estimates.
At the same time, operational progress should be demonstrated live to the largest possible audience: Do good and talk about it! This way, decision-makers and users can see for themselves how success is taking shape.
c. Roll-out - Continuous refinement
If the decision is made to continue the project, the roll-out is next. A smart "design-to-time-and-budget" approach is recommended during the roll-out: features are realized to the extent that they can be kept within the time and budget plan.
d. Continuous improvement - the Evergreen approach
Once the first complete and operationally usable release is finished, another motto applies: The king is dead, long live the queen! The former project has arrived in the continuous improvement process, just as all modern software is subject to an evergreen approach today.
Financially, this means that an annual budget is set for the further development of the systems. IT is moving away from a CAPEX-oriented view toward an OPEX-oriented world.
