A few years ago, Lincoln Financial Group completed a project that was originally given the green light based on its ability to reduce head count within a particular department. The project, which resulted in customer service improvements and other benefits, was deemed a success -- that is, until Jason Glazier, chief technology officer at the firm, made an important discovery: No one had ever executed the layoffs.
Oversights like this highlight a major flaw in how projects are managed at many companies, Glazier says: the tendency to neglect important steps at the project's close that can make or break your ability to achieve a full return on investment. While lots of IT and business groups are all over ROI at a project's inception, it all too often slips off the radar as the project is winding down.
For instance, Glazier says, when projects are going through the approval stages, they are often given the go-ahead only when they can demonstrate a clear ROI. But as soon as they're under way, the focus switches completely to staying within budget, and few companies circle back to see if the original ROI expectations were achieved. As a result, it's all too possible for completed projects to appear to be successful based on adherence to schedules and budgets, as well as the delivery of benefits, even if they didn't meet the objectives that drove the original ROI case.
"At no point do you forecast whether you're still on track for your ROI, which means you might not achieve it," Glazier says, "especially if no one goes back and looks."
Lincoln Financial, a US$4.6 billion diversified provider of life insurance, retirement products and wealth management services in Philadelphia, has since implemented a process so that all major projects include the step of verifying that the original assumptions were met, Glazier says.
With the number of projects on many IT departments' plates, it might seem logical, even smart, to finish projects as quickly as possible, wash your hands of them and drive full-throttle toward the next one. "Demands are coming in quickly, and the tendency is, 'Get it done, meet the deadline, and move on to the new one,'" says Roger Agee, coordinating business systems manager at Jeld-Wen, a door and window manufacturer in Oregon.
It's true that many IT departments operate that way, but it's more important than ever to pay attention to a project's ROI, particularly as IT's attention turns from cutting costs to a new wave of innovation.
Many companies don't do project closures very well because they don't plan for them, says Gopal Kapur, founder and president of the Center for Project Management in California. It's crucial, he says, for the closing steps to be planned so that you've got the resources -- money, time and senior-level staffers -- to perform them when the time comes. Otherwise, you may create a functional system that never actually delivers the intended benefits.
"If you said you were going to reduce head count by eight people or eliminate 3,000 square feet of data center space or cut 100 licenses on a software package, who is taking care of doing that?" Kapur asks. "I've seen where people forget to tell the staff in charge of leasing that the contract has to be renegotiated or forget to tell procurement that software licenses have to be terminated."
To close the initial ROI loop, the actual users of the system need to be keenly aware of and enthusiastic about the project's objectives from the beginning, Agee says. Otherwise, when you involve them in collecting the data that measures whether objectives were reached, you'll meet with some blank looks and, very possibly, resistance.
Say the project was intended to reduce the cost of manufacturing a product, and you ask the people on the line to supply the data that measures the "after" picture. "If they don't clearly understand their role and the importance of collecting this information accurately, you won't get the data," Agee says. "Then you have to send someone to figure it out, which is a cost you didn't include in the project, so what ROI you may be getting can disappear."
In addition to failing to check on original ROI intentions, a related mistake is to move on before you've churned up all the benefits the project has to offer, says Karen Quirk, research manager at Nucleus Research, an IT advisory firm in Massachusetts.
This is what Kapur calls the "value extraction" stage, which is often skipped because people think of projects as temporary endeavors. "Most organizations disband the project team soon after project implementation, and the project goes into operations and maintenance mode," he says.
Not so at Lincoln Financial. Two and a half years ago, the company implemented Service Broker, a Web-services-based system that syndicates Lincoln-specific content and applications on its partners' Web sites. The project, which cost the company US$545,000 and took three developers four months to build, has exceeded its business objectives, according to Glazier. But as the system nears its third year of operation, he still continues to educate the business units on how they might extend the technology to reap even more benefits. "We're constantly looking for ways to spread that investment over more functions and expand the usage of it," Glazier says.
Lincoln Financial's focus on broadening ROI is right on the money, says Quirk. "Use the new technology in all the appropriate places rather than just sinking it into one part of the business and, when a new request comes in, putting in something completely different," she says. "You need to fully examine all the people that can potentially benefit from using it, as well as how far it can be extended to customers and partners."
Although Lincoln Financial's Service Broker project was designed for use by external partners, it quickly became apparent that some functions could benefit the company internally as well. For example, among the many functions the system provides is the ability to tag certain files, such as a particular state's tax form or a product prospectus, in a "favorites" file. "Once we added that, we used it everywhere, such as our internal sites, our director site, our planner's site," Glazier says. "There are all sorts of places to reuse if you expend the effort."
A culture that's looking for these types of opportunities doesn't just happen; it takes work. The Web group at Lincoln Financial holds quarterly meetings to discuss opportunities for reuse, and Glazier himself holds formal and informal meetings with business executives to reinforce the potential benefits of the Web architecture.
"You can't really assume that just because you demonstrated the technology a year ago that they're going to remember it," he says. "You need to tout your success and get additional momentum around the effort."
You can also build momentum by going directly to the users of the new system to brainstorm on additional functionality, Kapur says. In fact, this step should be formally built into the project plan at the outset. "It should be talked about as part of the planning process that four to six weeks after the project has been completed and basic fine-tuning has been done, we will meet quarterly to ask how to get additional value from what is running," he says.
The brainstorming sessions should be led by a trained facilitator, not by IT, Kapur says. Ideas might range from the refinement of a navigation protocol to decreasing the number of steps in a particular process. "The ideas might seem minor," he says, "but if you gather them every two or three months, and each incurs 2 percent to 3 percent savings, they progressively add up."
And good ideas should be rewarded, he adds: "If an idea ends up saving the company [money], a certain percentage should be given to the people who came up with the idea."
The important thing, Kapur says, is to create a formal process that enables these ideas to come to light. For instance, create an "ideas portfolio" to collect good ideas, and choose an appropriate person to broadcast ideas about completed or ongoing projects that can be applied to other parts of the company. "If there's no process to capture these ideas, many will slip away," Kapur says. "But at the right organizational level, people will know who else should know about it."
Reining in ideas
Of course, project management experts usually talk about the opposite problem: trying to rein in projects that keep getting extended by users adding new requirements or developers endlessly fine-tuning or testing. "I see projects that go on and on forever," says Johanna Rothman, president of Rothman Consulting Group in Massachusetts. "It's more a question of how to help people stop."
You can turn scope creep into an ROI opportunity, however, by collecting the ideas that come up midproject and applying them only after the original project is completed, Agee says. "When good ideas come up, you should write them down and assure people you're going to come back and look at them when the project is finished," he explains. "And when the project is done, milk the ROI through modifications and enhancements."
Clearly, it's time for ROI to become as important to a project's closure as it is to its inception, whether you're closing the loop on the project's original intent or squeezing out extra value after implementation. "It doesn't take as much time as people think," Agee says.
When calculating ROI on IT projects, it's just as important to consider indirect benefits as direct ones, according to Nucleus Research. Direct benefits include measures like reduced head count or increased sales, but indirect benefits - which include returns that can't be directly observed, such as worker productivity -- account for half of the return on your technology investment, Nucleus says.
Companies that overlook indirect benefits when calculating ROI could end up forgoing a competitive advantage, since indirect benefits can provide real business value. Increased worker productivity, for example, means that employees are doing their jobs in less time, enabling the company to avoid the cost of hiring additional employees.
If you're trying to estimate the proportion of indirect benefits from a proposed project, you should consider three key factors, according to Nucleus:
-- The technology you plan to implement. Some projects, such as implementations of ERP systems, tend to produce direct benefits. Others, such as deployments of collaboration software, portals and content management systems, tend to generate more indirect returns than direct returns. A Nucleus study on document management tools, for example, found that 84% of companies that implemented such systems saw measurable increases in user productivity, whereas less than half reported direct returns.
-- How the technology is being applied. Integration technology could generate more direct returns when used externally rather than internally. For example, automating data exchange with customers would attract more revenue through increased ease of doing business. In contrast, an integration platform used primarily for speeding internal applications may bring mostly indirect returns.
-- Your existing technology environment. Often, the magnitude of indirect benefits will depend on how much of a change the new technology exerts on the existing IT environment. For instance, in the case of a time and attendance application, companies that have relied largely on manually collecting time for hourly employees will see significant direct benefits by reducing the number of timekeepers. But if the company is just upgrading to a version of the timekeeping system with new auditing and reporting features, most of the ROI will come indirectly, through time savings.
Brandel is a Computerworld contributing writer in Newton, Massachusetts. Contact her at firstname.lastname@example.org.