Insurers Prefer to be Agile
It is hard to imagine a time when insurance carriers gambled that the software solution they were
purchasing would work effectively from the moment the carrier went live. Today, it is hard enough
to get a project green-lit without business champions and IT leaders worrying the implementation
approach would allow them to keep their jobs. Agile technology has made life easier for many
developers and implementation teams, but three insurance technology analysts believe insurers need
to examine all project options. Our three analysts this month are: Karen Furtado, partner, Strategy
Meets Action; Jeffrey Goldberg, vice president research and consulting, Novarica; and Colleen Risk,
senior analyst, Celent.
What Do You Think?
This month’s question:
Is there any good situation today where insurers should look at something other
than agile development for implementing a technology solution?
Karen Furtado,
SMA
Agile, in some form,
is the preferred
development path
for project delivery
today. Gone are
the days of lengthy
requirements-gath-
ering sessions
followed by months
of development without any visibility
into a view of the product.
The benefit of an agile approach is
that business-user input and validation throughout the process is critical
both to ensure the right capabilities
are being developed and to promote
greater adoption of the solution after
implementation.
Industrywide, however, different projects are suited to varying degrees of
agile development. Policy administration projects tend to require a modified
agile approach, as they necessitate bulk
requirements gathering and development.
Claims is a different type of project,
and most companies use an agile approach for implementation. The implementation approach must consider the
needs of the project to ensure success.
Jeffrey Goldberg,
Novarica
While I’m a big
believer in agile, not
all projects should
or need to adopt an
agile methodolo-
gy. As an example,
updates to a legacy,
back-office system
will not likely see
much difference between an agile and a
waterfall approach.
Organizations where executives do not
feel comfortable moving from explicit and
detailed project plans will need to see a
culture shift at the top of the organization
before moving away from waterfall.
One major advantage of agile is it formalizes an ongoing interaction between
IT and stakeholders. Companies handled
a waterfall approach by defining requirements and then “throwing them over the
wall.” It doesn’t have to be that way.
An organization that has a high project
success rate and a high rate of satisfaction
by both IT and business users doesn’t
need to change for the sake of changing. Adopting agile will help when these
fundamentals need improving, and when
engaging with vendors and consultants
who most likely have adopted agile.
Colleen Risk,
Celent
Agile development
methodologies and
the recent investment in DevOps
have addressed
the basic concerns
around the necessity for speed
of development.
However, there is no one best way to
implement a solution.
The methodology to use depends on
the talent and capability of the developers, the underlying technology being
changed, and the complexity of the
change. Many insurers use a waterfall
development methodology for purely
pragmatic reasons.
Much of the technology is many
years old—if not decades—and does not
lend itself to a more modern approach.
Celent encourages the use of agile, but
it is not a ‘one size fits all’ approach to
development.
For web and mobile development,
agile is the way to go. When facing a
legacy project where it is crucial to know
upfront what to expect including size,
cost, and timeline of the project, waterfall
may be the better choice.
