A few years ago, Life insurer Lincoln Financial Group completed a project that was originally given the green light based on its ability to reduce the headcount in a particular department. The project, which resulted in customer service improvements and other benefits, was deemed a success — that is until the firm’s CTO, Jason Glazier, made an important discovery: no one had ever made the layoffs.
Oversights like this highlight a major flaw in how projects are managed at many companies, he says: the tendency to neglect important steps at the project’s close that can make or break getting 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 example, Glazier says, when projects are going through the approval stage, 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.
“At no point do you forecast whether you’re still on track for your ROI, which means you might not achieve it — especially if no one goes back and looks,” Glazier says.
Lincoln Financial has since implemented a process so that all major projects include the step of verifying that the original assumptions were met, he says.
Many companies don’t do project closures very well because they don’t plan for them, says Gopal Kapur, founder and president of the Centre 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, the result may be a functional system that never actually delivers the intended benefits.
“If you said you were going to reduce the headcount by eight people or eliminate so many square metres of datacentre space or cut 100 licences on a software package, who is taking care of doing that?”, Kapur says. “I’ve seen [situations] 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 licences have to be terminated.”
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.
This is what Kapur calls the “value extraction” stage, which is often skipped because people think of projects as temporary endeavours. “Most organisations 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’ websites. The project, which cost the company $US545,000 (NZ$800,000) and took three developers four months to build, has exceeded its business objectives, Glazier says. 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,” he says.
Lincoln Financial’s focus on broadening ROI is right on the money, Quirk says. “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, put 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 “favourites” file. “Once we added that, we used it everywhere, such as [on] 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 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.”
It’s also possible to 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, participants 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-3% savings, they progressively add up.”
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, he 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 organisational level, people will know who else should know about it.” 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. “It’s more a question of how to help people stop.”
Scope creep can be turned into an ROI opportunity, however, by collecting the ideas that come up mid-project 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 says. “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.
AT A GLANCE
* Calculations of ROI at the beginning of a project often aren’t done again at the end
* After a project is completed, ongoing monitoring of the results can yield further ROI than originally anticipated
* Changes suggested during a project can be advantageous if they are noted during the project and applied afterwards