Sample Initiative Overview Map
Welcome
On this page, you will find an example implementation of an IOM (Initiative Overview Map). This assumes a FIDA initiative being implemented in an insurance company.
The primary purpose of an IOM is to provide the cornerstones of an end-to-end initiative. It is established during the preparatory phase and consistently maintained throughout all phases of the project. Typically, large projects are a collaborative effort involving distributed teams and diverse suppliers. Each of these contributors knows only a portion of the requirements. The IOM describes the big picture and encompasses all the facts about an initiative necessary for overall project management.
Please note that this page was developed using WordPress for demonstration purposes only. In real life, a sufficiently large project would require an enterprise architecture tool or a professional content management tool. This would allow, among other things, many people to work on the model simultaneously and better manage the relationships between the solution components.
Why FIDA?
FIDA is a forthcoming regulation from the European Commission, likely to come into effect in 2026 or 2027. The regulation governs the rights of customers of financial products to manage their own data. FIDA will therefore have a profound impact on the IT landscapes of all major financial institutions, including banks, insurance companies, and asset managers.
Description
The “Vision” section provides the most compact and concise project description. It summarizes the value the project offers to customers and the company.
Vision statements are frequently found on project manifesto posters for good reason. They provide easy-to-understand guidance and ensure that all stakeholders have a consistent understanding of the project content.
Life Cycle
Initial vision statements are developed in the inception phase. They are supplemented in the subsequent scenario assessment phase and agreed upon with all key stakeholders shortly before the project is approved and company funds are spent on implementation.
During implementation, all project decisions are continuously reviewed against the original vision statements, and the results are measured against them. To achieve this, the most important requirements for success are translated into clear and easily trackable KPIs.
Changes to the vision represent a significant realignment of the project that must be agreed upon with stakeholders.
Description
The domain “Customer Value” answers the question of why this project is being undertaken from the customer’s perspective. This goes hand in hand with the business case, which answers the related question of why the project is being carried out from the company’s perspective.
Life Cycle
Except for purely technical optimization projects, the discussion of the customer value is at the beginning of a project in the inception phase. It is the central motivation for the project and should remain largely constant throughout all project phases.
Typically, personas and customer segments are outlined in the scenario analysis and fully developed during implementation. However, if the business case critically depends on specific customer segments and personas, how they are addressed, or how they react to the project outcomes, these must be fully developed prior to implementation.
Description
The business case for a project consists of the benefits for the company and the associated costs. A distinction is made between ongoing costs (operating costs) and one-time costs (investments). When deciding on a project, various scenarios with different benefit profiles are typically considered – e.g., high benefits with high investments and lower benefits with lower investments.
Life Cycle
The business case is developed as the result of the scenario assessment phase. It is linked, on the one hand, to the expected values for the company and customers, and, on the other hand, to the project’s outcome—i.e., the deliverables with their associated costs, and schedule.
During the implementation phase, the project delivers its results. If assumptions regarding the costs of a deliverable or the schedule need to be adjusted, the business case must also be adjusted. Therefore, traceability of the key success factors is of utmost importance for project success and is monitored throughout implementation.
What will be delivered?
123
Description
The “Requirements” section describes the most important constraints and requirements for a project as a whole. In particular, it formulates those central requirements whose non-fulfillment would lead to dealbreakers—i.e., the failure of the project. Detailed requirements, e.g., for individual project steps, are processed and recorded separately in the individual teams.
Life Cycle
Requirements are captured throughout the project life cycle as knowledge about the topic grows. However, important requirements that have a significant impact on the structure of the solution must be known before the implementation phase begins.
However, it may happen that project areas cannot be clearly defined until well into the implementation phase. This uncertainty should be explicitly addressed in the solution development process—for example, by using exploratory techniques such as design thinking.
Avoid treating all areas of the project equally out of convenience. Where a high degree of certainty exists, solid planning should be used, while exploratory approaches should be taken in areas of uncertainty.
Description
In the “Business Solution” section, we describe use cases, processes, business objects, capabilities, and functions. Not all of these abstractions are relevant to all projects. Instead, we consider those that best fit the nature of a project.
A “business solution” can be described in any depth, and this is often necessary—for example, when introducing a completely new process, every single step must be worked out. However, this is not the scope of an overview model; instead, we focus on those facts that are relevant to project management and the solution’s architecture.
Life Cycle
The rough overview of the business solution is developed in the scenario assessment phase in order to derive all solution components and estimates. This can be achieved, for example, by focusing on use cases (or similarly, on business events, or business services). Techniques such as functional decomposition or domain storytelling or event storming can help you create a complete overview of your project. However, details are omitted during this phase.
Implementation is often organized into releases with multiple interim deliveries within each release, for example, in the form of agile sprints. To plan each release, the relevant part of the overview model is further broken down into finer parts to form the basis for development planning.
Description
The “Application” section contains software systems and their sub components such as applications, application components, data objects, and interfaces.
Typically, all of these elements are included in enterprise-wide architecture documentation. If this is the case, only core data and a reference to it are required. Even if a project introduces a new application, the enterprise architects should include it in their documentation.
The elements in the applications section are linked to elements of the business solution, for example, to indicate which new features they should receive or which features are used by a project.
They are linked to the elements of the infrastructure section to indicate how they are physically implemented.
Life Cycle
The list of required applications is developed in the scenario assessment. This is necessary to involve the respective application owners in the cost estimates and verification of the overall solution concept.
Interfaces and data are designed as part of the release planning during the implementation phase.
Description
The Infrastructure section describes the physical runtime for the application layer elements of a project, including compute nodes, storage, and networking.
Life Cycle
Unless infrastructure is the main focus of the project, only a very rough outline and a cost estimate are required in the scenario assessment.
The detailed design takes place during implementation, as only then is sufficient information available for a good design, especially for appropriate sizing.
Wayne Gretzki
Project lead customer satisfaction
Example Inc.
