Insurers historically raced to deploy the latest information technologies, yet they continued to rely on older, established methodologies to build the internal business applications that they installed on those leading-edge platforms. Some, such as the step-by-step Waterfall development process, are becoming living fossils in the age of cloud computing and service-oriented architectures. Now, however, project managers within insurance companies are finally giving agile development methods, such as Scrum, PRINCE2 and others, a look. As a result, IT departments long accustomed to sequential development are being warned to tread carefully as they enter these new waters.
Like Cub Scouts around a campfire, assemble enough insurance technologists, and spine-tingling tales will no doubt emerge. However, the stories will have less to do with the proverbial axe murderer and more to do with the equally frightening prospect of technology implementations gone awry.
The reasons underpinning failed or budget-busting projects are as varied as the insurance companies that undertook them. Yet, generally, much of the blame tends to emanate from one of two sources: insurers ignoring or misapplying development methodologies, and insurers failing to adequately reconcile the project at hand with the underlying business need.
"For a long time, insurance companies have not been disciplined on the IT or business side about doing projects," says Mike Fitzgerald, senior analyst at Boston-based Celent, acknowledging things are improving in this regard. "In the last 10 years, the insurance industry has done better at taking an engineering-type approach, rather than just smart people doing good work."
Identifying and adhering to the proper methodology can help insurers avoid the time, cost and resource implications of badly run projects, says Rachel Alt-Simmons, research director in the insurance practice at Needham, Mass.-based TowerGroup Inc. "What's really changed over the last few years is that companies have recognized the value that process and discipline bring."
OVER THE WATERFALL
While the predominant methodology in project management has been the waterfall, or sequential method, agile methodologies first seen in software development are beginning to take hold.
In a waterfall project, members of the IT development team query business users at length over requirements, and then depart to build out the solution. Traditionally, this method has proven effective, but it runs the risk that when the project nears its end, certain components will not work together or, worse still, will not meet the current needs of the business, which may have shifted during the development process. "Nobody wants to work on a project that doesn't help the business - that's not anyone's goal," Fitzgerald says, adding that in a large organization, it may end up happening.
"There's a realization the traditional view of IT project execution where the IT teams sits back and interviews colleagues from sister functions to determine requirements, then IT goes off and builds it, flat out doesn't work anymore," says Mike McGarry, CTO of Richmond, Va.-based Genworth Financial Inc.
Alt-Simmons agrees that waterfall methodologies can often exacerbate the gulf between IT and the business. "The business often doesn't clearly articulate what the project requirements are," she says. "The IT department doesn't know what questions to ask."
GETTING AGILE
Conversely, agile development methodologies are designed to break deliverables into smaller chunks. Development sprints run concurrently and can last as little as a day. This incremental approach keeps business users more actively involved in the project, and development goals more closely aligned with ever-fluctuating business objectives.
Examples of agile methodology include Scrum and PRINCE2 (PRojects IN Controlled Environments), which organize project teams illustrative of agile development as a whole.
Scrum roles are divided into two primary roles, pigs and chickens. Pigs are employees, from both the IT and business side, who are primarily responsible for the success of a given project, while chickens are end users, managers and other stakeholders. The names are derived from a joke about a ham and eggs breakfast: whereas the chicken is merely involved in the offering, the pig is fully committed.
The cross-disciplinary nature of Scrum teams may go a long way to alleviating misalignment between IT and the business side. The constant contact demanded for agile development ensures that technologists keep business objects firmly in mind, while business users are afforded a better sense of what the technology can actually deliver.
"My job is to deal with fluid requirements as business conditions change," McGarry says. "As we learn the technology we're implementing, we need to be able to change quickly. My observation is that traditional waterfall methodologies do not allow for that."
McGarry, who ascended into his current position in 2003, says the increasing importance of Web interfaces has made agile development more appealing, noting one of his primary goals is to redefine the service experience for Genworth's customers.
"When I received responsibility for Web development, we took a hard look at project methodology and ended up making a move to agile development, particularly Scrum," he says.
While agile development arose as a software development methodology, it is gaining traction in project management because it provides transparency into development process, which is key as insurers embrace service-oriented architectures (SOA).
"SOA is something we've invested in the last few years and are now we're really realizing the benefits," McGarry says, noting the company's CIO also has embraced agile development, and uses it for the new product introduction process on the mainframe. "The principals of agile are technology-agnostic."
Yet, while an agile development methodology may be a good fit for many projects, it does not fit all. "You need to choose the methodology that fits the right project at the right time," Alt-Simmons says. "If you are delivering a policy administration system, you can't deliver it in pieces. It won't work."
She says analytics or data warehousing projects are better fits for agile development. "Data warehouses take forever to build," she says. "If you take three years to deliver anything, people might forget why they wanted you to build it in the first place."
CAVEATS AND CONCERNS
Fitzgerald also cautions that agile development may be something of a culture shock to companies long accustomed to waterfall development. "In order to do agile, you need to have an environment that allows you to make mistakes and recover from them quickly," he says. "In insurance, that is not how many companies are wired."
In addition to these issues, there are concerns that agile development, despite its name, can slow projects down by fomenting scope creep.
"The best part about agile is that you keep your customers engaged and, at the end of the day, they are going to get something meaningful to them," Alt-Simmons says. "The downside is that if you are constantly letting individuals change requirements, it can have a huge downstream impact on your project. That's where a project manager should step in and manage expectations."
McGarry says one of his primary objectives is to minimize the time before his colleagues in the business functions start seeing value from technology projects. "Our mantra is to be simple, fast and reliable," he says, adding that Genworth's move into agile development has forced IT more into the forefront when formulating business strategy. "We're playing a much more active role. We take a more holistic view than solely as technology specialists. That aspect of our jobs hasn't gone away, but we're now also looking at projects as business leaders."
PROJECT MANAGERS
Indeed, the degree to which any project is successful is due in the large part to the efforts of a project manager, who is asked to bring both technology and business expertise to bear to help guide the project. Project managers, with the Project Management Professional (PMP) certification from the Project Management Institute, are becoming prevalent in insurance, according to Alt-Simmons. "Project management is not just an IT discipline," she says. "We're now starting to see more project managers on the business side."
While methodology provides the science to project management, facilitating the communication necessary to keep a project moving apace is something of an art. A successful project manager needs to couple an innate sense of when things aren't going well with a willingness to crack the whip, Alt-Simmons contends. "It's about having tough conversations, but it's also about being positive and keeping people focused."
Indeed, this skill set is in high demand, according to a survey conducted by the training division of London-based Parity Group plc. The study, which questioned 225 IT professionals at 50 large companies in the U.K., found that project management is the most in-demand skill among IT workers, topping the list at 64% of companies queried.
For insurers, the question then becomes what to do with their project managers. Some insurers opt to consolidate their managers by establishing a project management office (PMO) as a formal organization within the company. The PMO will help with prioritization, eliminate duplication of efforts and lock in best practices across all projects, proponents say.
Others see a PMO not necessarily as a formal organization, but as a governance office there to provide standards, common set of tools for project managers to draw upon.
Genworth's McGarry doesn't buy the concept of pooling project managers into a PMO. "If you're in a pool, you are not close to the business functions," he says, adding that much like the term middleware, the term PMO can mean many things to many people.
Indeed, Fitzgerald contends if not properly implemented, a PMO will only add an unnecessary layer to the project management process. "It can ensure scientific rigor, but it can be way too bureaucratic and pedantic and get in the way of getting things done," he says. "You have to have a talented leader in charge of the PMO who recognizes that, at times, that rigor is going to slow things down, but result in a better product. That's why it's an art and not just science."
Scott Schenker, senior managing director of Devon, Pa.-based SMART Business Advisory and Consulting, says insurers can find a middle ground where they can manage IT projects in a structured way, but retain enough flexibility in their approach so that they can adapt to the particular needs of individual projects. "If you get too rigid you can lose sight of what is trying to be accomplished," he says.
Accordingly, insurers that can step back and view project management strategically will have the most success, says Schenker. "Organizations that do attempt to put every single initiative through a large scale project management approach tend to struggle because the value is not always there in the smaller projects," he says.
THE PROGRAM
Yet, one of the dangers of taking a strategic approach to project management is that its aims can be conflated with program management, which lumps projects into programs, and portfolio management, which bundles programs into portfolios.
Fully apprised of problems with past implementations, project managers are taking a more realistic approach to their initiatives, says Karen Furtado, insurance practice director at Burlington, Mass.-based Collaborative Consulting LLC. "People have become more pragmatic about what they bite off for an implementation," she says, noting that while two-year deliverables were once the norm, the focus on delivering value to business as soon as 90 to 180 days after inception is now becoming more commonplace. "People are trained to do shorter-term deliverables."
This modest approach has paid dividends, Furtado contends.
"Project management is succeeding," she says. "Things have improved. Before, you would read about train wreck after train wreck-projects that never came close to getting into production. You don't hear of that much anymore. It's program management that is challenged."
THE TOOLS
Yet, the many tools most project managers use to gauge their progress are beginning to show their age. The two most ubiquitous project management tools, Microsoft Excel and Microsoft Project, can both trace their lineage back to the early 1980s.
Schenker, too, sees some rust accumulating in project mangers' tool kits. "I still see Excel being used more than any other tool, even for large projects," he marvels. "I think the technology truly misses the mark in terms of managing projects and the work associated with them. If you're building something that has a strong, repeatable methodology, the current project management tools do a very good job on that. But I think IT projects are much more fluid."
What's more, he says, the tools, such as Mircosoft Project, are too strongly tied to dates. "Being forced into a start date and an end date on a task-level item is really restrictive," he says. "The software tools need to do a better job of helping projects run instead of forcing them into a particular paradigm. Things don't always work that way in real life."
Furtado concurs, and says although the ever-improving maturity and stability of the technologies being implemented has helped, by clinging to date-based tool sets, project mangers run the risk of myopia. "Some people think they can just plug their data into Microsoft Project and everything is good," she says. "The software told me so."
Interestingly, carriers are finding that business transaction management (BTM) tools, closely associated with testing and monitoring, can pay dividends in project management. Dave Thomas, director of technology support at Blue Cross and Blue Shield of Minnesota, says BTM software from New York-based OpTier, originally brought in to give him a better understanding of how applications are behaving, has found fertile ground elsewhere.
"We shared the tool with an application development team, and they liked it so much that they decided it would be a good way for them to monitor their application and start putting in performance enhancements in their release process," he says.
WEATHERING THE CRISIS
Ultimately, the key to any project is the financial metrics. Agile development shines in this regard. "If you have a system that increases the transparency of project financials, it becomes much easier to assess a project," Alt-Simmons says.
Indeed, as macroeconomic events force even tighter scrutiny of planned and ongoing initiatives, projects using agile development, which can show ROI quickly, may well earn reprieves from cash-strapped CFOs. "ROI is more important than ever...and it was important before," Fitzgerald says.
(c) 2009 Insurance Networking News and SourceMedia, Inc. All Rights Reserved.
