When an insurance company plans a major IT project – a new policy system, a revamp of the claims process, the implementation of a risk assessment engine, or the adaptation of sales network oversight to new regulatory requirements – it usually already has a preliminary list of requirements, a budget and a project start date. However, three questions remain unanswered: does this list of requirements actually form a coherent solution concept; can it be built in the intended environment; and is the project’s implementation, based on the assumed parameters, commercially viable?
The Discovery phase answers these questions before a single line of code is written – not only during system development, when every change already costs many times more.
The Discovery phase – what does it involve?
Discovery is a time-bound phase preceding development. We carry it out jointly with the client’s team, most often on a Time & Material basis. The outcome is not merely a report with recommendations, but a specific set of deliverables: a solution concept, business and technical specifications, a backlog, mock-ups, a proof of concept for the elements carrying the highest risk, and a quotation based on a verified scope.
We work simultaneously across three streams: governance, analysis and technology. This enables us to identify inconsistencies between business objectives, requirements and technical assumptions right from the start. Without such an analysis, these inconsistencies often only come to light during implementation – when rectifying them is considerably more expensive.
The three streams of Discovery in practice
Let’s look at this using a specific example. By 1 July 2027, every insurance company working with an agency network must bring its supervision of agents and individuals carrying out agency activities (OFWCA) into line with the Polish Financial Supervision Authority’s (KNF) Recommendations on insurance distribution. In discussions about achieving this objective, a seemingly obvious solution quickly emerges: a portal for agents and OFWCAs designed to collect information on training, data required for the agents’ register, and declarations.
- The governance stream begins with determining who within the company is responsible for supervising the network. Formally, responsibility lies with the management board; however, in practice, information on agents is scattered across the sales, compliance and network administration departments. The recommendations require the company to assess how agency activities are carried out and, should any irregularities be identified, to take corrective action and, if these prove ineffective, to impose sanctions as well. It is therefore necessary to decide who, in practice, will make such decisions. This is a management decision, not a systemic one: the sales department is rarely willing to take responsibility for preventing an agent from carrying out their activities. Without a clear assignment of this responsibility, the portal may be set up, but decisions will still not be taken.
- The analytical stream translates the concept of ‘supervision’ into specific, documentable actions: verifying the conditions under which agency activities are carried out and the fulfilment of training obligations, comparing the data in the agents’ register with the actual situation, and checking the agent’s marketing materials. At this stage, an issue also comes to light that determines the scope of the solution: the OFWCA is not a party to the contract with the company – the agent is. With regard to its own distribution staff, the company can directly prevent them from carrying out activities, whereas with regard to the OFWCA, it acts through the agent. The exception is where the OFWCA fails to meet the conditions for entry in the register – in which case the response should be immediate and lead to the submission of an application for removal. These are two distinct processes, not simply a single click on the portal.
- The technology stream determines where the data feeding the portal will come from and who will enter it. Will training certificates be sourced from the company’s e-learning platform, or from the systems of dozens of agents – in dozens of different formats? Can data relating to the same OFWCA be unambiguously linked across the agent register, the commission system and the sales system? And will a multi-agency firm working with eight companies manually enter the same data into each of the eight portals? If not, large multi-agency firms will require system integration, whilst the portal will primarily serve smaller agents.
- This is where the scope is usually revised. A portal, which seemed the obvious solution, is not sufficient to achieve the objective – it is merely one of several channels for data collection. What really needs to be designed is the audit trail: a reproducible record of who carried out the verification, what it concerned, when it took place and what the result was. Such a record must be made available upon request by the supervisory authority. Changing the definition of the objective at this stage after the contract has been signed means redesigning the data model. Before signing – it merely involves amending a paragraph in the specification.
It is only by combining the conclusions from these three areas that we can determine whether the project is feasible and makes business sense given the assumptions made. This is particularly important when a deadline is imposed from outside and cannot be postponed. If the scope needs to be adjusted whilst the system is already under development, there is no longer any room in the schedule to redesign the solution.
Where else does Discovery prove its worth?
The same mechanism – analysing a project across three areas – also proves its worth in other IT initiatives within the insurance sector, for example in:
- reducing the time taken to implement tariff changes from quarters to days,
- ensuring a multi-channel approach without silos between the agency, direct and bancassurance channels,
- automating commission settlements with the sales network – taking into account bonus thresholds, adjustments and previously undocumented exceptions,
- building product flexibility, which allows new variants to be introduced without IT projects lasting several months.
In each of these cases, Discovery enables us to answer the same question: is the stated objective based on verified architectural assumptions and clearly defined business rules, or is it merely a wish listed in the RFP – with no confirmation that it is feasible?
What does an insurance company gain from Discovery?
In none of these cases does the problem stem from a lack of competence on the part of any of the parties, but rather from the fact that key questions – regarding architecture, the completeness of business rules and the actual complexity of the integration – are asked too late.
The primary role of Discovery is not to create new requirements, but to verify those that already exist – before they are set out in the contract and form the basis for large-scale development work. For an insurance company, this brings tangible benefits: fewer scope changes during implementation, fewer disputes over the interpretation of requirements, and a quotation that, after three months’ work, still reflects the actual scope of the project.
Once the Discovery phase is complete, the entire set of documents remains at the client’s disposal – regardless of who carries out the project. If the company chooses a different contractor or entrusts the work to its own teams, the documents will still be useful. Each tenderer then quotes for the same, precisely described scope, so tenders can be reliably compared.
Discovery need not prolong the project – its results form the direct basis for development work, rather than being additional material separate from the actual implementation. It is a small investment of time in exchange for significantly lower risk in later stages. This is precisely why, in the insurance sector – where a single process is often the joint responsibility of several business functions and distribution channels – this stage is particularly worthwhile.
We are a team of specialists working primarily on projects for the financial sector. On our blog, we share insights from real-world projects: we discuss technologies, analyze implementation approaches, and highlight what works in practice. We create content that helps better understand IT and make informed decisions — both from a business perspective and within technology teams.
