Worth the Effort: Tackling the New Project Management

Although driving change through ambitious projects is essential to creating competitive edge and value, when it comes to successful execution of these projects, insurers need a better rallying cry than "Just Do It." Insurance company IT departments are reservoirs of intelligence and talent, but when it comes to planning and completing projects, they need to work smarter, not just work harder.

Happily, a cultural shift is underway in what Donald Gardner, principal, Gardner Project Integration Group (Hastings-on-Hudson, NY), calls "the last great frontier in the financial services industry in adopting project rigor." Gardner, who recently finished a four-year tour as chair of the Project Management Institute's (PMI, Newtown Square, PA) financial services-specific interest group, contends that at insurance companies, traditionally "projects were not aligned with strategies, finding the right people as project managers was not an understood need, and there were no consistent methodologies."

That has begun to change, as insurers facing an increasingly demanding marketplace have found they must respond to business demands more nimbly and rapidly. Gardner counsels that distinction in project management (PM) is a key to achieving that response, and good governance is the beginning. "Insurance companies have to understand that project governance needs to be focused—it's not going to happen by itself," he says. Whether companies decide they need a formal project management office (PMO) or not, "good PM begins with the prioritization of projects in a portfolio view," Gardner says.

Portfolio View

Even where good PM skills have been present at a carrier, they have been spread inconsistently across the enterprise, according to Paul McDonnell, managing director and insurance segment leader, BearingPoint (McLean, VA). "There are pockets within some companies, but we've seen few that have established a common discipline across the organization," he says. "We are now starting to see much more focus on defining a consistent approach."

One of the difficulties in establishing a consistent PM outlook is that "it cuts against what IT people would traditionally love to do, which is go out and play with technology toys," according to McDonnell. It's axiomatic that "a good project manager has no friends," he adds, "because oftentimes you're the bad guy that has to force people to do the things they don't want to do. You're the guy who forces people to do documentation, to fill out reports, and take on dependency on someone else's project."

What companies need to do is not only alter their organizational structure to foster PM discipline, but change the way employees are measured and compensated. "They need to create a career path within the organization for project managers, and make sure they're recognized and rewarded for what they do," McDonnell says. "They also have to put the support in place that's necessary for them to be successful, which is defining the common approach, the method that they're going to use, and put thetools in place that will help them be successful."

And investment in one of the increasingly sophisticated tools on the marketplace for project and portfolio management—from vendors such as Primavera, PlanView, Microsoft and Niku—can be a worthwhile step, McDonnell says. Even the best of CIOs can use PM disciplines and tools "as the vehicle to getting an effectively managed organization to the next place," according to McDonnell.

Project LESS Means More

MetLife arrived at a new place by embracing new PM disciplines in addressing a major opportunity. In mid-2001, "in order to gain efficiencies, we looked at our systems portfolio and realized there were significant opportunities for us to reduce costs, increase efficiency and enhance speed-to-market," says Jeff Stoll, vice president, individual business, application development, MetLife (New York, $302.5 billion in assets). "We identified 53 systems that we could close, but the problem we faced was selling it to the business, since to save money, you have to spend it."

That sale of what came to be known as Project LESS (legacy system simplification) was based on a plan that depended on aggressive schedules in order to result in payback in two years or less. After an intense planning phase in the fall of 2001, the project was planned for execution between November 2001 and November '02. "The question we faced was how to take a project that was so large and put it into a manageable structure," Stoll recalls. "In order to keep Project LESS as a focal point, we realized we needed a management structure that paralleled our project structure."

Stoll implemented a PMO specifically for Project LESS and convened a steering committee composed of the business and IT representatives most directly affected. The chair of the committee was the business executive with the greatest number of projects and the largest investment within this environment. Stoll delegated day-to-day management of the PMO to vice president Bob Riggio, along with an allocated staff member. "Their responsibility was to keep all the project plans coordinated and follow the tasks across the entire universe of the project through weekly meetings with the committee."

The project was broken into four systems tracks: annuities, life administration, remittance, and compliance and marketing. "Each one had a business and a project lead who coordinated activities for the projects," Stoll says.

Each project manager was accountable for maintaining project plans on a standardized format using Microsoft Project project management software. "We were able to consolidate those projects on a task base, and detect any conflicts, since a lot of the systems needed to talk to each other" in the migration stage, according to Stoll. The PMO also looked at three functions horizontally. "We had a QA [quality assurance] support function, because we wanted to standardize our process across all of Project LESS. We also had a data conversion process, which was necessary because so many systems were being closed. Finally, we had what we called a road-map function," Stoll relates. "In doing something as extensive as this, we decided we wanted to develop a documented repeatable process. That way, if we acquired another company and wanted to merge systems, we wouldn't have to reinvent the wheel."

In order to meet aggressive targets, it was necessary to address major milestones with "deep dive" meetings to keep the team's focus sharp, according to Stoll. For example, when closing down an annuity system on the West Coast that handled more than a million contracts, all the concerned parties would meet in MetLife's Denver facility that supports the carrier's group annuity system, to which the closing system's data would be sent. "We would bring together the 'send' team, the 'receive' team, the business owners and the QA people, and spend a day or two going over all the tasks and asking, 'What are the issues? What are the open questions? What's our strategy for testing? What is the impact?'" Stoll explains.

Given the overall impact of the project on MetLife's systems, a liaison relationship was also forged between the PMO and the company's enterprise technology office, which manages all IT support, including data centers, networks and software technical support. That relationship was key during the deep dive stages, Stoll recounts, when "we executed dress rehearsals for the [data] conversions in order to get better timings and impacts."

Project LESS concluded on time in November 2002, "reducing our applications portfolio by 53 apps and returning a bottom-line impact that justified the investment," Stoll says. Given the focus provided by the PM structure, and resulting partnerships, "this was probably the most successful effort I've seen run," he adds.

Business necessity resulted in a different kind of invention at Columbia, GA-based AFLAC ($37 billion in assets). The carrier received a recommendation from the Gartner Group (Stamford, CT) in 2000 to implement governance measures and formalize PM discipline, according to Joe Weider, PMP, director, enterprise project office, who arrived at AFLAC in January 2001 to develop a center of excellence, having worked on the Y2K problem at Coca-Cola. "The center of excellence is where all the project infrastructure lives, including policies, process, and procedures, as well training, coaching and mentoring project managers. It's the blocking and tackling of PM," he says.

Snapshot of the Universe

In October 2001, AFLAC reached a major milestone in its PM rigging by implementing Primavera's (Bala Cynwyd, PA) TeamPlay solution, according to Weider. "Any time you look for a PM tool you're looking for three things: the ability to manage individual projects, control of your resources, and an aggregate view of everything you're looking at-in other words, resources, PM and portfolio management," he says. The tool that had been in place at AFLAC was dodgy for the first two tasks and non-existent for the last, which is ultimately the most important for establishing consistent PM across the enterprise, Weider argues. "The real bang-for-the-buck comes with portfolio management," he says. "We can take a snapshot of our universe to see where every single resource is deployed. With that power, we can make quick decisions about prioritizing those resources according to demand, keep programmers writing and maximize their efficiency."

In addition to the cultural challenge of building disciplines and establishing PM as a career track in the carrier, justifying the initial investment in the Primavera tool was an uphill climb. "We relied heavily on The Standish Group's (West Yarmouth, MA) CHAOS study to get the funding," including the West Yarmouth, MA-based research and consulting firm's reference to a 31 percent rate of project failure across all industries, Weider says. "When you start to think about sub-costs, resource time, turnover, etc., there are tremendous dollars embedded in that statistic," he adds. "After a year of use, we're working on formalizing payback to the organization. We're doing that through train wrecks we avoided through the value of the portfolio management being brought before the steering committee on a monthly basis, and the accuracy of the estimates we can now verify through the plan."

One of the reasons project "train wrecks" have occurred so often is that at most companies no one knew the engine was in trouble. "In the past, 31 percent of projects may have failed, and probably 25 percent of the time, we didn't know they were in trouble until it was too late," says Michael Heuer, vice president, applications services, Premera Blue Cross (Mountlake Terrace, WA, $985 million total assets). Achieving that prescience was a major reason Premera instituted a resource management group (RMG) in 2001 and implemented the PlanView (Austin. TX) portfolio management tool by the end of that year, along with PlanView partner Gantthead's (Fairfax, VA) methodology models. "Now I can tell you which projects might fail and which ones I have my eyes on—that's huge," he says.

Process Before Tool

Heuer emphasizes that the tool itself is not as important as the process involved. Where companies have "gone to the tool selection piece before having solid processes in place," he says, "they had problems implementing because they hadn't arrived at a well-defined process of how to use the tool, and where."

Nevertheless, the benefits of the PlanView tool to Premera have been great, Heuer says. In addition to gaining awareness of the entire project portfolio, PlanView has been accumulating project history since the configuration and training were completed. "When we're estimating a project now, we can do it on the basis of the project 'actuals' of the past 15 months," he explains.

What Heuer likes best about the adoption of PM tools and process is that satisfaction is now much higher among his business customers. "People would come to me and ask me to do a particular project," Heuer relates. "I would tell them I couldn't fit it in, but had a hard time articulating why." Now he can easily indicate concrete reasons for turning away projects, tied into initiatives about which business executives are well-aware. "Their satisfaction immediately went up, and I still didn't do their project," Heuer quips.

In fact, seeing PM acumen demonstrated by IT can lead to IT being identified as a center of excellence for PM capability, according to BearingPoint's McDonnell. It's natural for PM discipline to catch on in IT because it has "the biggest need for this capability," he says. "But what we've seen is, once this capability exists within the organization, the business quickly latches on to it and says, 'Hey, I'd love to have two of your project managers to run these two projects, even though there's no technology associated with the projects.'"

Still, that course is less than ideal, according to Tim Handren, executive vice president of enterprise business operations at USAA (San Antonio, $64 billion in assets), a unit instituted in 2002, but with roots going back to the arrival of Bob Davis as USAA's CEO in 1997. Handren has an IT background and operates enterprise business operations independently of USAA's IT company; he ranks as a peer of its president, Steve Yates. Handren believes his disinterested status is key to maintaining transparency regarding projects' true status. "If I worked in the IT group and had a project 'going south' I might be reluctant to surface that to the table. But as an objective, neutral party, I'm not protecting any problems, whether in the IT group or the business area," he says.

Well-Defined Roles

With the PM function operating as an independent arm, it's easier to clearly define the roles of sponsor and project manager within projects, explains USAA's Reuben Fechner, vice president of property and casualty programs, and a member of Handren's organization. "If the business is engaged at a different level than the technology department, that puts an inordinate burden on the technology-oriented project manager," he says. "If the business focuses on that kind of priority, the technology team can focus on delivery, and that kind of focus makes a team extremely effective." The level of effectiveness may be gauged by comparing current Standish Group CHAOS figures (see related article on pg. 32) with Handren's claim of 86 percent of USAA projects on-time and on-budget and about seven percent that get stopped.

Handren cites an effort of "tremendous cultural change to get where you can operate in a process view as opposed to an organizational view." Achieving that transformation at USAA wasn't without pain, but, says Handren, "through projects you're defining your future business model and putting in place any productivity gains, whether in technology or otherwise. And if you're not building your future well, you don't stand a chance to survive."

--------------------------------------------

Not As Chaotic As You Thought

Discussions about how well projects are managed frequently yield citations of the rather grim statistic that 31 percent of projects fail. This statistic has been taken by many as a wake-up call, and is summoned as a reminder of how poorly projects are run. But the alarm clock needs to be reset: The figure is from the Standish Group International's (West Yarmouth, MA) 1994 cross-industry CHAOS Study, which analyzed the scope of project failures. More recent statistics show room for optimism.

According to updated CHAOS Study figures released in December 2002, project failures have declined to 15 percent of all projects, while success rates have climbed to 34 percent—a 100 percent improvement on the '94 rates. The study also found that these results correlate with fewer projects undertaken, and decreased spending. According to Jim Johnson, chairman, The Standish Group, "We estimated in 2000 that there were 300,000 project new starts; we estimate that in 2002 there are about 240,000 new projects. Half of these projects are under $750,000 in total labor cost."

Projects that the study qualifies as "challenged" have shown a three-fold improvement since '94. "This was a major contributor to our estimate of a 43 percent average overrun cost, down from 180 percent in 1994," Johnson reports.

However, the study shows time overruns are up to 82 percent from a low of 63 percent in 2000. While time and cost results tend to run in parallel directions, "the cause of the diversion, we believe, is a decrease in overall resources and increased timelines to cut costs with reduced budgets," according to The Standish Group.

Anthony O'Donnell has covered technology in the insurance industry since 2000, when he joined the editorial staff of Insurance & Technology. As an editor and reporter for I&T and the InformationWeek Financial Services of TechWeb he has written on all areas of information ... View Full Bio