Hofstadter’s Law declares that IT projects will always take longer than you expect, even when you take Hofstadter’s Law into account. Brooks’ Law observes that adding personnel to a late software project always makes it even later.

Good tech takes time, but the very brave announcement that Lloyd’s Blueprint 2 initiative will once again be delayed, and that legacy processing systems will be maintained until at least 2030, has prompted me to use this entry in my Insurance Technology Diary to set out guidelines to ensure IT projects are delivered on time.

The seven articles of Bonnissent’s Law might not always let you reach your objective exactly as scheduled, but they will give your in-house or external developers a fighting chance of meeting their go-live deadline.

Article 1. Consider the end users. Analyse their existing processes, and involve them in the development from the beginning. They are the people who know best what they need their platform to do, and they are the ones who will use it, so it’s best that you start with them when defining the project. If you cannot identify the potential users, the project is a non-starter. If you expect your new platform to eliminate roles, be sure to consult with the people who originate the tasks, and who will use the outputs.

Article 1.1. Beware. End users are like kids in a candy store. It’s a treat to get a new system, but you want to make sure they don’t go overboard. They will always ask for more than they can chew, so don’t promise more than they need.

Article 2. Empower a strong leader. Western military organisations (hopefully) believe in defending democracies, but not in being run like one. Think of your project team in the same way. The project manager is the officer in charge. Everyone is welcome to have an opinion, but when a hard decision has to be made, the commander needs to make the call, and it has to be respected.

Article 3. Define clearly the problems you wish to address. Platforms that go off in search of a business-process challenge will rarely solve the correct problem, just as armies searching for an enemy usually wreak havoc. As you advance, keep asking why. This might sound obvious, but you’d be surprised how often we’re asked to add new functionality for other reasons.

Article 4. Identify the minimum viable product to meet stated, clear delivery objectives. A general would send a reconnaissance battalion before mobilising multiple divisions, which take ages to arrive and are probably much more than is needed to get the job done. You can always add functionality, but overkill is always wasted.

Article 5. Know from Day One how the data will look and flow. You need to understand where your intelligence will come from, how it will be ingested and analysed, what formats and standards it must meet, and which operating units need to use it. Only then can you set out functioning supply lines.

Article 5.1. Be clear about where data will be deployed, and how. If you need an interface at underwriting boxes, or in Tasmania, it’s best start with that assumption before manoeuvres begin. If NEDs need to see loss-event impacts in real time, start with that in mind, but if no one needs a mobile app, don’t build one.

Article 6. Consider from the outset how you want your data presented and managed. Different users require different datasets in different formats. Know who needs what, who can change the presentation, and who can amend the underlying data. You should know what legacy data should be archived, and how it will be transferred. You will certainly want a Corporate Data Treasury, which acts as data HQ and a single source of truth. Who decides what is truth, and what is merely alternative facts?

Article 7. Bring everyone along. Remember that turkeys never vote for Christmas, and that front-line troops will only use kit that makes their job easier. If agentic AI is your target, for example, you might want to treat your ultimate objectives confidential, but keep in mind always that loyal troops are critical to the successful execution of any insurance technology battle plan.

When in doubt, refer to Bonnissent’s Law, Article 1.

Guillaume Bonnissent is Chief Executive of Quotech