At AFLAC, Columbus, Ga., proposed IT projects need to meet certain criteria, such as surpassing a general cost threshold or number of hours required for completion, before it is elevated to official “project” status. “We size our initiatives before we take them to management,” explains Brian Abeyta, VP of AFLAC’s IT project management office. “Those initiatives that exceed or meet the size criteria, whether it is the number of hours, cost or, in some cases, visibility, we classify as a ‘project.’ If it doesn’t meet that threshold, like many of our routine software releases, it is handled at the operational level.”

Projects considered for project management status are subjected to a formal executive review, Abeyta continues. “Our largest projects go before a steering committee headed up by many of our senior C-level executives.” Typically, IT projects meriting this status at AFLAC are those exceeding $100,000 and 1,000 hours of development time, though most are far above these levels, he adds.

By putting such pre-qualifiers in place, AFLAC is tackling a problem that vexes many organizations across insurance and other industries: how to deliver IT projects not only on time and within budget, but also in line with business requirements. Studies over the years confirm that IT projects often fall short on all three counts. The “Chaos” study, conducted by Standish Group, West Yarmouth, Mass., and regarded by many in IT project management circles as an annual wake-up call, finds that 46% of corporate application development projects fail to deliver results on time, within budget or in-scope.

Other surveys report similarly dismal findings. CA, Islandia, N.Y., recently commissioned a study of 100 companies within the U.K., and found that one-third of typical IT projects came in over budget, mainly due to “inaccurate scoping and forecasting.” Another survey of 800 executives released by Tata Consultancy Services (TCS), Mumbai, India, had even more downbeat results. The TCS survey found that two out of three executives said their IT projects routinely fail to perform against expectations. A majority, 62%, experienced IT projects that failed to meet their schedules, and 49% said they had projects that suffered from budget overruns. At least 41% say these projects failed to deliver the expected business value and ROI.

In companies where IT projects had run astray, the TCS survey finds that most top-level executives expect problems, but would continue to support the effort. Nevertheless, one out of five report that budgets were either reduced as a result, or that the failure made it more difficult to secure funding for new initiatives.

These IT project failures tend to be more common among larger, more complex IT projects, says Bob Sydow, practice leader of program advisory services with the insurance and financial services practice of Ernst & Young LLC. However, more IT projects are growing in complexity as they serve more needs across the enterprise. “We’re seeing projects that are a lot more complex in a sense that they are broader and deeper,” he says. “Many insurance companies are re-evaluating their portfolio of applications, and trying to consolidate claims and other systems.”

For example, there has been a growing number of carriers moving to upgrade, improve or replace many of the policy administration systems that form the core of carriers’ internal operations. Celent LLC, Boston, Mass., estimates that the policy administration system market has tripled in size over the past four years. Much of the emphasis of this work is on consolidation of multiple and disparate systems resulting from years of acquisitions, mergers and growth. “On the life side of the industry, 10 policy administration systems still running would not be an unusual number for a large company,” says Donald Light, senior analyst with Celent.

The scope of many IT projects now extends across the enterprise, resulting in “a lot of confusion about who’s really responsible for the program,” Sydow explains. “If it has a heavy technology element, there’s a bad habit of trying to make the IT group responsible for that project. But the project’s success is dependent much more on just the technology. It’s really dependent on getting the right processes and organizational changes done at the same time you’re introducing new technologies.”


The insurance industry also has its own unique challenges to project management as well. Large legacy systems ripe for upgrade, modernization or consolidation are more commonly seen among insurance companies. In addition, a more complex regulatory environment means more complex project management challenges as well. “There are more regulatory demands that are put on the insurance industry,” says Celent’s Light. “That applies directly to IT project management because nearly all regulatory changes are going to require IT to help implement them. That’s another level of strain and stress to insurance project management environments.”

For example, one leading carrier, MetLife, has “50 states and D.C. that would require any changes we want to make to our products or pricing structure,” says Barb Lynch, VP of the business project management office for MetLife Auto & Home, New York. “In many states, we need to file those and have prior approval. Meeting each state’s requirements adds a complexity to the projects when we want to introduce something from a countrywide perspective.”

The insurance industry’s growing reliance on IT across its breadth of product lines also is putting the spotlight on IT project management. Steve Romero, IT governance evangelist for CA, observes that “insurance companies spend more on IT than any other vertical because the ‘products’ are now mostly technology based, and because the players are seeking to differentiate themselves through IT-delivered products such as Web-based quoting and service systems, automated rating systems and more.”

Abeyta, who served as a project manager in government and telecommunications organizations before joining AFLAC, observes that cultural differences shape project management priorities across industries. “The government is heavy on documentation,” he says. Telecom, with products being unveiled at a rapid rate, tends to focus on “quality and innovation.” The insurance industry lies somewhere in between these two approaches, he says. “We need to continue to roll out new products as quickly as possible in our sales force. We also recognize that our disclosure and documentation needs to be as accurate as possible.”

Increasingly, speed is of the essence for insurance carriers facing a competitive market landscape, which requires that IT projects be turned around much quicker. Much of this burden falls on the IT department, but new distributed or collaborative technologies also help to speed up the pace of project rollouts.

At MetLife, for example, moving to greater user enablement has increased the speed of project rollouts, says Lynch. “We’ve been able to reduce the cycle time from the start of a project until it was rolled out in all states by about 40% by making changes to our processes. But we also developed more user enablement, so from state to state with our product rollouts, we were able to put much of the build in the hands of our users without IT development.”

For example, MetLife was able to put rate-change functionality in the hands of its business users, she explains. “When we want to make a rate change in a particular state, there’s no IT development involved. That’s all within the hands of our actuarial team, within the user-enabled workstation.”


Still, most IT project management is a carefully planned and deliberate process, preferably left to professionals trained or certified in project management methodologies. Both AFLAC and MetLife maintain project management offices to coordinate the origination, planning, implementation and follow-up testing of IT projects. “Having project management discipline is one thing, but having the adequate knowledge base, and professional certification and development standards is something else,” Celent’s Light points out. A project or program management office provides trained managers “who can manage multiple interrelated projects together,” he says.

Lynch cites an example of how one recent major project moved through MetLife—a new pricing structure for automobile policies. First, the initiative was carefully reviewed by a steering committee to weigh its costs and benefits. Once the project was approved and turned over to Lynch’s department, the project managers looked at all the elements that needed to occur within the project. “If we look at the rollout for a new pricing structure that first includes, from a business area, how we want the pricing to work, we need to know criteria, policy conditions and price points.”

MetLife’s project managers then went out and “worked with all of the various business units to say, ‘how do we want this to work?’” Lynch elaborates. “We worked closely with our actuarial, corporate sales, underwriting and product development departments to determine what the pricing structure and product package would look like.”

MetLife’s project management office then defined “all of the business requirements and the rules that we would give IT developers,” Lynch continues. “IT worked on the building of the system to meet requirement needs, while we worked on the training and communications plans, and how we want to deploy that in the marketplace.”

The key to success in such projects is linking efforts closely to the business, and being able to adapt as business needs change. Often, projects that run over the course of years don’t have contingency management built into their goal planning, Sydow says. “Too often, big programs or projects force the original project estimate dates to become cast in stone—they don’t compensate for changes in the business, or changes to the project itself.”

MetLife’s Lynch sees the project management office’s role as an intermediary between the IT or technical department and the business. “Our organization plays the front end to IT, but we also bring all of the business areas,” she explains. “We take a ‘divide-and-conquer’ approach. On the business side, we do all of the tasking, and all of the work around what needs to be done to make decisions to define what our requirements are, and what training and communication will be needed. IT takes those requirements, and breaks out what parts of the system need to change. Are there any new data entry fields in our requirements? Where do they need to build those requirements? They figure out what data needs to move within the system, and manage all of that until it’s programmed and ready for us to test.”

At AFLAC, IT not only works closely with the business, but also has a say in what projects are prioritized by the business. “IT has a seat at the business table,” Abeyta says. “We are part of the decision making when it comes to any projects that are going to impact the organization.” He adds that business units rely heavily on IT “to do much of the coordination and planning for the new projects. There’s a large degree of trust between all the business units and IT right now—we are very fortunate to have that type of senior-level endorsement of that entire process. Without, it would be a struggle to be effective.”

Joe McKendrick is an author and consultant specializing in information technology, based in Doylestown, Pa.

Register or login for access to this item and much more

All Digital Insurance content is archived after seven days.

Community members receive:
  • All recent and archived articles
  • Conference offers and updates
  • A full menu of enewsletter options
  • Web seminars, white papers, ebooks

Don't have an account? Register for Free Unlimited Access