When Libbie Bock weighs the costs and benefits of technology projects at The Hartford Financial Services Group Inc., she gets closer to the process than most of her peers. Bock is chief financial officer of The Hartford’s 2,000 strong information-technology unit — literally a CFO of IT. In that atypical role she rides herd on the company’s restructured governance processes for approving projects, from a new underwriting application to a full-blown claims administration solution.
Like many other companies, The Hartford ($22.7 billion in 2004 revenue) sought a more balanced view of IT projects and a methodology for ranking and approving them. “Any investment in a project over a couple hundred thousand dollars must go through a pretty rigorous process now,” says Bock from the insurer’s Connecticut headquarters.
Each month more than 20 proposed projects that require technology resources land on Bock’s desk, generally sent over by business managers but sometimes passed upward by the IT staff. Before overhauling its project governance structure last December, IT “acted more like an order taker and not a consultative partner,” says Bock. Today, she notes, “We spend nearly as much time assessing the business value of projects as we do executing them.”
Managing the Outcome Before Measuring ROI
There are three phases in the life of an IT project: 1) project development, which begins with articulating a business problem and a possible IT solution and extends through the building of the business case; 2) implementation, from selecting the vendor to the project’s “go live” date; and 3) assessment, when the project’s effectiveness and return on investment will later be measured and analyzed.
In recent years ROI has attracted more than its share of attention, but for finance executives who oversee technology costs, that first phase — when business needs are evaluated against the efficacy of IT solutions — is the most crucial. The project development phase “is where all the costs and benefits are explicitly, if not exhaustively, detailed to ensure management of the expected outcome once dollars are invested,” says Greg Balestrero, chief executive officer of the Project Management Institute, a non-profit advocacy association for the project management profession.
During that phase, business leaders define the business case for the project and estimate the expected value it will deliver. A project leader is selected, and he or she assembles a team that develops a budget, initiates the vendor-selection process, and frames a comprehensive view of project risks and how to mitigate them. “This is not just about project initiation,” says Balestrero, “it’s about aligning projects with strategy and then selecting from a portfolio of strategic projects the major initiatives that will propel the organization forward.”
It’s prudent, then, to recognize that ideas for IT projects “can come from anywhere, but they’re not all good places,” says Forrester Research analyst Margo Visitacion. A chief executive might have a “eureka moment” in the middle of a symposium or while reading a magazine. A manager may look at the business’s competitors (or listen to its customers) and recognize the need to do something better, faster, or simply different. And “some ideas bubble up from IT,” which has its antennae out for the next great technological breakthrough, adds Visitacion.
Early on, a little skepticism can be a good thing, says project-management expert Joseph Fusco of San Francisco-based Technical Pathways. “Just because some consultant is at the front of the room waving his arms around showing how great a particular IT project was for one of his clients doesn’t mean the project also would be great for you,” he counsels. “They’re trained to be stump preachers telling you how to get saved. You want to avoid testimonials of a technology’s promise and focus on what the technology can actually do for you.” Be careful, though, and watch for “business managers that act pretty emotionally when they talk about a project. It’s one thing to apply critical inquiry to what a vendor is promising and another when it’s your boss asking.”
Project ideas at The Hartford (and at most companies) typically emanate from business units, whose leaders “come to us in IT with a problem and ask us to frame and design a solution,” explains Bock. “We then work together on a feasibility study that looks at the project from four dimensions: financial return, strategic fit, architecture, and risk.” Bock’s capital management group analyzes the potential financial return; the business unit sponsoring the project assesses alignment with company strategy; IT addresses overall technology-architecture issues; and the project manager evaluates risks.
Bock works closely with chief information officer Michael Bernasky and the business units to nurture the development of projects, which must pass a gauntlet of staged gates before getting the go-ahead. Large projects are reviewed by Bock’s cross-functional IT governance committee that includes Bernasky, technology staffers, and business customers; smaller projects are reviewed by a similar committee within the line of business from which the idea emerged.
On the matter of staged gates, Visitacion also advocates that approach but warns that “it can be overarchitected to the point where you’ve wasted too much time and money.” Gary Curtis, global managing partner at consulting firm Accenture’s IT effectiveness practice, observes that “large projects like a new ERP system or a major HR outsourcing strategy are akin to a heart and lung transplant,” and in these cases, staged gates are appropriate. But for smaller projects like adding a new application, he observes, such an elaborate approach probably isn’t necessary.
At The Hartford, projects of all sizes are handled much differently now than they were before the restructuring of the company’s IT governance last December. Earlier, ideas were examined on a first-come, first-serve basis; today, all projects are pitted against each other for approval and must vie for financial and human resources. “We now have a disciplined process covering all IT investments, with far more rigor up front,” explains Bock. “That allows us to prioritize projects to ensure we invest our financial and human resources into areas that will offer us greater benefit.”
Start with Business Value
To separate the wheat from the project-proposal chaff, says Accenture’s Curtis, begin with those proposals that fail to make the business case comprehensible. “The most suspect IT projects are those where a knowledgeable businessperson can’t walk up to the project table and figure out the business benefits,” he explains. “If he or she keeps saying, ‘I don’t understand this, is that really a benefit?’ or ‘How did we get that number?’,” the project is suspect.
Even within an in-depth feasibility study that consistently articulates and quantifies the business value of an IT project, however, “business value” must be the focus. “A feasibility study that emphasizes technology at the expense of the business problem” is flawed, says Fusco of Technical Pathways. “Comparing products with each other is fine,” he adds, but don’t become fixated on checklists of what one product can do and another can’t; assess them against the problem you’re trying to solve.
The whole point of a feasibility study, adds Visitacion, is to enable you to add a proposal to your portfolio of projects, then evaluate it. “And the only way to provide an ‘apples to apples’ comparison is to have a common methodologyÂÂÂ that looks at certain business and technical criteria,” she says.
Many proposed projects fall short right there, says Mark Langley, chief operating officer of the Project Management Institute. Proposals are often “assembled in different business units and evaluated by different sets of criteria with different tools, different languages, and different ROI criteria,” he explains. “Companies need a single language for explicating project cost, benefits, and ROI and standard methodologies for assessment across the business units and with IT.”
Before The Hartford overhauled IT project governance, those companywide assessments gave more credence to proposals promising superior financial returns than to proposals offering nonfinancial benefits. “We’ve put more rigor around what we call the ‘benefits profile’ to be sure these benefits are trackable and measurable,” says Bock. “By analyzing each project for the strategic fit, architecture, and risk, in addition to the financial return, we have a more thorough understanding of that project’s value. Consequently, if a project is touted to have a 15 percent ROI, that doesn’t necessarily mean we will do it, and if it has less than 15 percent ROI, that doesn’t mean we won’t do it.”
Resisting a myopic focus on financial returns, Fusco agrees, is a project-management best practice. “There are many instances where a project doesn’t have a financial payback, yet there is still a strong business case,” he maintains. Financial returns for a new ERP system might not stack up well against those for your legacy system — until you consider, for example, that the programmer for that existing system has retired, so you can’t expand it to accommodate new elements of your business. Observes Fusco, “Now you have to analyze what this inability to expand will cost your company down the road.”
That big-picture view is the key to preparing a feasibility study, says Bock. “The financials behind any project are complicated, especially in the insurance industry, where some lines of business are short tail and others longer tail,” Bock explains. “Our governance model allows us to adjust for these differences — no matter the project. You want to ensure that no stones are left unturned.”