now more functionally broad, better written, and more easily modified and extended. Therefore, the possibility that one vendor will
differentiate themselves on functionality alone is smaller as time
goes on. Where vendors win or lose is more on execution—their
implementation track record, software configuration capabilities,
support, pricing, and contract terms.
As important as choosing the “right” vendor, the carrier must
have a complete understanding of the vendor they choose. Often,
problems that arise with implementation projects can be directly
traced back to a lack of homework during the selection process.
The landscape is littered with problems large and small that originated with a lack of insight as to what the vendor’s capabilities were
in a given scenario. A project may go swimmingly well for a period
of time and then hit the rocks.
Analysis often shows the early going was a repeat of efforts
the vendor had previously done and the rocks appeared when the
vendor was being asked to do something they hadn’t done before.
One of the truisms of projects is it’s never good to be first.
Resource the Project Adequately
In almost 40 years of being involved with technology projects,
I have never seen one that allocated too much time, too much
money, or too many qualified people. Pretty much every project is
under-resourced in one or more of these key areas.
Why do we do this to ourselves? If we can fail for $3 million or
do a half-cocked job for $5 million, why not do a good job for $6
million? Why is it the people who know almost nothing about the
project get to arbitrarily set deadlines that the project must meet?
Why is it that people who should know better undertake an expensive, mission-critical, enterprise-wide project without securing
key resources that have done this before? What makes a carrier’s
management think that the people that have spent 20 years doing
maintenance can suddenly pull off a core system replacement? Or
that the vendor will do it for them?
Here is a second truism: The best risk mitigator is to have key
resources on the project who have expertise doing core system
modernizations. It is unrealistic to expect people to figure out how
to control such a demanding project without the benefit of prior
knowledge. Third truism: Not knowing is dangerous, not knowing
what you don’t know is very dangerous.
Experienced resources don’t know everything, but crucially
they know what they don’t know, and they know how to figure that
out. In discussing the keys to project success we often talk about
methodologies, realistic plans, and suitable approaches. These
frameworks and artifacts are, of course, important, but they are
secondary. If the project is (human) resourced appropriately then
these assets will follow, brought along by the experts who have
done it before.
Why do we place arbitrary and unrealistic timelines on proj-
ects? There is some justification in time-boxing a project to meet a
compelling date; regulatory changes, contract expirations, and im-
portant business triggers come to mind. But if the project is made
to labor under such restrictions then senior management should
reasonably be expected to loosen the purse strings and resource the
In my experience most projects are under-resourced and
time-constrained because of a systemic lack of understanding of
the sheer scope and complexity of work involved. But if nobody actually knows what the project will take, then at least build flexibility
and reserves into the time and cost estimates.
Truism number four: Ultimately the project is going to take
what it is going to take. Any senior management notions that
somehow the project will expand to fill the time available fails
to recognize the commitment and extreme efforts of those who
participate in these projects. There is enough stress to go around
without management’s help.
If you get the right vendor, and you get the right people, you
still have to control expectations. The reality is that core system
modernizations happen infrequently and therefore take place in an
atmosphere of long-suffered frustration and disappointment on the
part of business users who have been waiting for all kinds of fixes
and enhancements for years. This pent up demand, coupled with
the sales pitches about speed, flexibility, and functional completeness—both internal and external—required to procure approval
and funding can easily overwhelm the project scope in a way that
can threaten success.
As every IT professional knows, the best course is to slim the
initial scope delivery in order to get into production and create
momentum. This, of course, is diametrically opposed to the busi-ness-users view that if I don’t get “it” now I never will.
I have argued previously that the best way of viewing a core system modernization project is that rather than satisfying a (lengthy)
laundry list of functional requirements, it is about establishing a
modern and flexible platform on which the company can continue
to evolve and enhance its core processing capabilities for years to
come. The project is not a once and done event. Truism number five:
The implementation is not the end of the project, it is the beginning.
Not every project we at CastleBay see suffers from these three
major problems, but those that don’t are the exception, not the rule.
Given the infrequency and the criticality of these projects it seems
rational to expect senior management’s only question should be,
“What do you need and what can I do to help?” If they don’t have
enough trust in those charged to execute the project that they feel
they can take this approach then they should get a stronger execution team or cancel the project. ITA
George Grieve is a popular writer and speaker on the
subject of insurance technology solutions. He is the author
of the book “Shop Talk” and is CEO of the consulting firm
CastleBay Consulting. The views and opinions in this column are those of the author and do not necessarily reflect
the views of the Insurance Technology Association.