 |  |
Jason Glazier, chief technology officer at Lincoln Financial Group Image Credit: Scott Nibauer | |
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 $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.
Closing Steps
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 Inc., a door and window manufacturer in Klamath Falls, Ore.
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 San Ramon, Calif. 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."
Revisiting Success
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 Inc., an IT advisory firm in Wellesley, Mass.
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 $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."
Circling Back
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% to 3% 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 Inc. in Arlington, Mass. "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.
Brandel is a Computerworld contributing writer in Newton, Mass. Contact her at marybrandel@verizon.net.