When Today’s Needs Were Not Enough for a Year: An Experience in Analyzing Insurance Software

Sometimes a software project may seem completely clear at the beginning. The client explains their requirements and business rules and expects the software to be built exactly around them. However, in some projects, the real challenge only becomes visible after the software is put into actual use and the business begins to grow and change.

The experience I am sharing here comes from a project in the insurance sales industry. The commission calculation model in this project changed repeatedly, and the experience showed me that requirements analysis is not just about understanding today’s needs. As much as possible, it should also take potential changes in the business into account.

I was asked to design a system for managing marketing activities and sales partnerships.

The software was responsible for registering sales agents and their downlines, managing the sales network structure, and, most importantly, accurately calculating commissions and bonuses.

At the beginning of the project, the number of sales agents was limited. However, the company’s plan was to continuously expand its sales network through incentive programs and by increasing the motivation of its sales agents.

An Important Question Before the Project Started

At the beginning of the project, the client had already designed a specific plan for calculating commissions and bonuses and expected the software to implement that model.

But I had a more important question:

What should the software do if this plan does not work in practice as expected?

A plan may look logical and complete on paper, but once the sales network becomes active, actual sales results and the behavior of sales agents may show that some rules need to be revised or that the entire reward structure needs to change.

For this reason, before providing a price estimate and starting development, I held around 10 working sessions with the client and technical experts to examine and analyze the project requirements and details.

The goal was not simply to create a list of required features. I needed to understand the business model, the structure of the sales network, how commissions were calculated, the relationship between direct sales and downline sales, and the types of changes that might occur in the future.

The result of this analysis led us to design the software from the beginning with the ability to support changes and future development of commission plans.

When the Plan Changes in the Real World

As I had anticipated during the analysis stage, the commission and bonus plan changed several times over the course of a year. Each time, it was revised and optimized based on the results that had been achieved.

Some changes required modifications to existing formulas, while others were significant enough to require programming and development of parts of the system.

One important decision in the initial design, however, was that each version of the plan and its related rules should be preserved alongside the records of previous periods.

Therefore, when the plan changed, information and calculations from previous periods were not lost. It remained possible to review each period’s calculations according to the rules that were in effect during that period.

This became increasingly important as the network grew. As the number of sales agents and the volume of sales increased, the load on the server also increased, and the system had to handle a larger volume of calculations without compromising accuracy or performance.

Why Was Calculation Accuracy So Important?

The sales agents’ commissions were scheduled to be paid at the beginning of each month. Therefore, the system was not simply a tool for recording information; its output was directly connected to financial payments to members of the sales network.

In such a system, even a small error in commission calculation could lead to financial discrepancies, dissatisfaction and, ultimately, a loss of trust among members of the network.

For this reason, each version of the plan was evaluated under real-world conditions after implementation. Sales volume, network performance, sales agent behavior and their response to the reward model were reviewed to determine whether the new plan actually produced the results we expected.

In other words, the software was not supposed to simply execute a fixed formula. It had to provide an infrastructure capable of evolving as the business model changed and developed.

An Experience That Highlighted the Importance of Initial Analysis

The manager of the company later shared an interesting observation about his experience of choosing me to develop the project.

He told me that before contacting me, he had spoken with several software companies. Some of them had simply quoted a price without carefully examining the project details or the company’s business model and said they could build the system. But you spent considerable time understanding and analyzing the problem before providing a price estimate. You wanted to understand exactly what we needed. That showed me that you understood our problem.

Some time later, another person contacted me and said that their company had also developed a similar project with another programming team. However, after several months, they encountered problems with the system and their sales network began to decline.

After hearing about the success of this insurance company, they contacted me and asked me to review their project and, if possible, redesign and develop it using a different approach.

They asked me what I believed had caused their project to fail. I explained that incorrect problem analysis, along with choosing an unsuitable technology and technical approach for implementing the software, had been among the main factors behind the failure. In complex projects, such issues may not become visible during the first few days. Their effects can appear months later, especially as the business grows.

What I Learned From This Experience

This experience made one important point even clearer to me:

Software analysis is not simply about creating a list of today’s required features. As much as possible, it should also take potential future changes and requirements into account during the design process.

A client may believe on the first day that their requirements are completely clear. But once a business moves into real-world operation, user behavior, market conditions, the revenue model and even internal business rules can change over time.

Software that is designed from the beginning to accommodate such changes can grow alongside the business. Software designed only for the conditions of day one, however, may require major modifications whenever an important change occurs.

That is why one of the most important questions to ask before starting software development is not:

“What do we need today?”

The more important question is:

“If our needs change tomorrow, how adaptable will this software be?”