Putting People first in the Digital Insurance Agenda


Recommended reading: Accenture Technology Vision for Insurance 2016.

What I like about this publication is that it is not just another piece about big data, customer experience or the newest business model, but puts people first on the digital insurance agenda. 

All industry insiders will immediately understand that the days where technology is a limiting factor are over. We can construct digital ecosystems that are just limited by our imagination. Problem is, we need people to perform within them. Change is hard, and maybe especially hard for many of the Insurance Industry’s specialists –  be it actuaries, product managers, sales managers, underwriters, insurance brokers or IT managers.

To illustrate this, let me share a story from my current project, where we bring together an established InsurTech player with an established Insurance Company to test-drive a new way of implementing insurance products on a SaaS platform in a matter of a few days or weeks instead of years.

The new platform provides real-time binding quotes and automatic underwriting capabilities.   The client’s business processes call for a 48h period between quote and underwriting for the parties to “think things over and make changes if necessary”. We challenged this, and it took us quite some time to get approval for a fully digital, straight-through process. Just because it was a radical departure from the way it used to be done, and actually made manual underwriting effort obsolete.

What I see quite a bit these days, is that a lot of capacity goes into discussions and efforts around changing the way a company works, rather than into the implementation effort itself, completely changing the dynamic of projects, and the types of skills you need.

It is thus critical in my view that Insurance top executives put much emphasis on seeding and nurturing a digital DNA in their organization.

How to do this is worth a separate post – I will keep you posted!

Waterfall to Agile Transition – Drivers

In this article. we look at what drives large, established organization to undertake a waterfall to agile transition. Contrary to many younger companies or even startups, who have worked in a agile fashion from the beginning, and know nothing else, our large, established clients are different. They typically feature:

  • large, complex application landscapes, often tightly coupled.
  • established processes, methods, tools to analyze, design, build, deploy and operate software and features.
  • large to very large business and IT departments with highly specialized people/teams, typically organized by business domain/system/platform/task.

Building a new feature or product thus requires collaboration of many of the specialist resources, both business and IT. Implementation of these products and features has a ripple effect  across the application landscape (e.g. affects the front-end system, customer databases, billing and payment systems, finance/controlling, etc. etc.).

Because of these interdependencies, these organizations typically bundle changes into large releases that are scheduled well in advance, and occur from once to a few times per year.

The downsides are:

  • long-term, detailed planning is required, resulting in high planning efforts.
  • large volume of change introduced with every release (in lean terms: large batch size), requiring massive preparation, coordination, testing and debugging efforts.
  • long time-to-market, because the long-term plan does not invite frequent changes and reprioritization.
  • high implementation efforts (high cost per feature)
  • little incentive for continuous improvement – one can hide a lot of imperfections in the software development lifecycle and the underlying processes and tools if you are on a annual release cycle.
  • does not promote a ‘stop and fix’ culture
  • perpetuates the high degree of specialization in people and teams.

Now with digitalization shaking up every industry, and nimble competitors appearing everywhere, these downsides are no longer sustainable for clients – change is inevitable.

Is agile a solution? We will look at this in our next blog. Stay tuned.


Waterfall to Agile Transition – why now?

Waterfall to agile transition – I know we have been doing agile software development at scale for about a decade now. Similar to other hyped trends, it is just now becoming a mainstream topic with our clients. To share what we experience on client projects during waterfall to agile transition, I will start a series of related blogs on this topic. Stay tuned.

What we will discuss here:

  • what prompts established clients with large IT departments to look at agile now (drivers)?
  • what are the expectations for a waterfall to agile transition at the diverse stakeholder groups within a client?
  • what needs to be done to get started?
  • what needs to be done to master the waterfall to agile transition?
  • what else ist out there? How do lean practices play a role?

next article in this series

Why Projects Fail ? (Project Best Practices 1 of 2)

We have all seen the studies – all pointing more or less to the same fact that around half of all IT projects started fail, or fail to reach their objectives, and/or are plagued by massive delays and budget overruns. I have seen my share of those at many clients in my 23 years at Accenture.

In this article series, I want to share some of the most common reasons for project failure that I have seen. Hope these help you to avoid or at least lower the risk for failure on your projects!

This first part focuses on the project definition phase, from the initial project idea through project design until formal project kickoff.

The second part then covers project mobilization and project execution, until project closure.

OK, lets get started! Continue reading “Why Projects Fail ? (Project Best Practices 1 of 2)”

Automation in Software Engineering

Automation in Software Engineering – I continue to be amazed how little even sophisticated clients invest in their software development architecture. These are the components that help design, code, test and deploy application software. Build, deploy, test data and quality management are often still the place for heros and massive efforts to get the software product out of the door. Continue reading “Automation in Software Engineering”