Etude

Five keys to IT program success

How to get the return you expect from your IT investments.

Par Steve Berez, Stephen Phillips and Jean-Claude Ramirez

First published on juin 22, 2012
min


Every year, companies invest hundreds of billions of dollars in large IT projects to enable strategic initiatives or to upgrade aging systems, but fail to reap their promised benefits. Sometimes those projects suffer because they aren’t adequately planned or correctly scoped. In other cases, it’s because senior executives don’t realize that IT transformations are as much about the organization and its operations as they are about the technology. They may lose sight of the project’s business goals or fail to put in program leaders who are senior enough to motivate change. In some instances, a poor choice of vendors or inefficient vendor management exacerbates the problems. Those costly failures remain one of the toughest challenges facing CIOs and the businesses they serve. According to the Standish Group, which measures performance success in IT projects, more than 60% of the IT projects conducted in 2010 failed to deliver on their goals because they either came in late or over budget, or they had fewer features than were originally specified. Since global investments in IT will total more than $2 trillion in 2012, according to Forrester Research, the total cost of this wasted effort is substantial. Given that the pace of change is quickening in information technology, it’s never been more important to understand how to make these transformations succeed. Companies can’t afford to waste time and effort on projects that don’t deliver. Our work with leaders across industries and regions has allowed us to identify five key steps to success—actions that may be simple to describe but difficult to execute (see Figure 1). Set up properly The first step in any transformation is to make sure that managers and teams—whether they are from the business, IT or operations side—understand the investment rationale and the business goals they are pursuing. Goals should be quantifiable in the form of top-line growth, cost savings or mitigating the risks associated with running obsolete systems. Before committing to the project, it’s important to have consensus that investing in IT is the best way to reach these goals. Sometimes organizations look to technology to solve problems that are actually more about process, organization, talent or even business models. Comparing the cost of an IT investment with other solutions, such as process changes or outsourcing, can give company leaders a clear understanding of the trade-offs. And sometimes, it directs them to try other solutions that are less expensive or risky. Another key to proper setup is getting the right people on the team—especially the right program leaders— from both the business and technology sides. Overinvesting in talent at the beginning can save time, money and effort in later phases of the project. When EMC, a leader in data storage, information management and cloud computing, decided to replace its old financial and manufacturing systems with a new system from SAP, it tapped two senior executives to lead the transformation: the worldwide controller’s direct report and the manager of its largest factory. The opportunity cost of pulling these leaders out of their positions for two to three years was high, but EMC recognized that managers of this stature were essential to the program’s success. To reassure them that this tour of duty wouldn’t derail their careers, top management stressed the program’s importance to the company’s strategic vision and the impact they would have on EMC’s future performance. Top management also outlined the path they would take back to the day-to-day organization once the program was completed. The care that EMC took, placing senior financial and manufacturing executives at the helm of its new IT initiative, underlines the necessity of having program leaders who understand the company’s business goals, can clearly articulate the project’s value and can mobilize the troops to deliver. Unlike some other large investments in infrastructure—new manufacturing facilities, for example—IT projects often struggle to find a business sponsor, even though they may cost several times as much as more visible projects. Investing in the best available technical talent—system architects, analysts and software developers—also pays off with systems that are more robust, user-friendly and adaptable to future needs. Equally important is choosing the right vendors and ensuring they are properly managed. IT projects often falter because vendors fail to meet their commitments, either because they don’t have the right capabilities or won’t commit the resources they had promised when they won the bid. IT program managers have a responsibility to vet the vendor thoroughly and to create the ongoing conditions for success through active communication and efficient coordination. Design, build and test effectively No complex project can deliver on its goals unless the internal team and outside contractors communicate effectively, track their progress with agreed-upon metrics and are held accountable for delivering results. Since high-profile IT projects are particularly prone to drifting off course, managers need to be vigilant against scope creep, which can cause projects to bog down or deviate from their original goals. Some expansion in scope may be justifiable, as was the case at Banco Bradesco, currently Brazil’s third-largest bank: During a multiyear IT transformation program, managers had to update requirements to stay current with market and regulatory demands. But in general, proper scoping that defines what the project will and won’t accomplish reduces the likelihood of an overbuilt system, or one that requires that additional features be “bolted on” during later stages or after delivery. A common mistake is investing in customization when off-the-shelf solutions would accomplish most of the project’s goals at a lower cost. Program leaders must have the authority to resist demands for customization that adds little value. Users who lobby to add customized features during the design phase tend to overestimate their value, while underestimating the costs to build and support them over the project’s lifetime. At EMC, program managers created a council for reviewing and limiting code customization, to ensure any new coding served the program’s business goals and remained at a level that would keep the system on the vendor upgrade path. A good guideline is to limit customization to no more than 5% to 10% of code, and those modifications should focus on core capabilities that are essential to success. Customization beyond these levels can make future upgrades too costly and time consuming, undermining a fundamental benefit of packaged software. Scoping the project properly at the outset also lays the groundwork for more efficient testing. Designers should give nearly as much thought to testing as they do to functionality, and ideally they should define both during the planning phase. Trials need to be robust enough to ensure the new systems can handle everyday demand once they are deployed and include stress testing that subjects them to peak loads. At Bradesco, developers were able to speed up testing of new off-the-shelf solutions for the bank’s mortgage department by focusing first on a subset of 12 tasks that made up the bulk of operations, rather than the entire suite of 40 tasks. This way, piloting the commercialization of mortgages with the new systems—in order to further stress test them— could start well before the entire test suite was complete. Because acceptance testing proves to be a popular time for users to request new features, project managers should be prepared to evaluate those requests in the context of the project’s original goals—and with as keen a lookout for scope creep as they had in the initial design. Manage change actively Successful change management has as much to do with the work that teams do six to nine months before rollout as with efforts put forth at the time of launch. As in the planning process, company leaders should articulate and reinforce the project’s business goals long before the actual transformation, but at this point, their audience should be expanded to include all of the employees who will use the system. Bradesco planted the seeds of change well in advance of the phased rollout of its new IT systems by creating an entire department to prepare business areas for each new system rollout, as well as to capture its benefits and measure the uptake after rollout. The bank also provided user teams with detailed plans describing how daily operations would change, as well as how, where and when it would pilot each new system. System business owners and program “evangelists” were trained in the new processes so that they would be ready to coach others, and help-desk staff was prepared to support the transition. This enabled frontline employees to easily support the organizational transformation when the new systems arrived. Realize the benefits Without proper training and motivation, people tend to underutilize new tools, whether they are a consumer’s new digital camera or a corporation’s advanced enterprise resource planning (ERP) system. When new IT projects are rolled out, old habits and processes can sabotage the realization of the benefits the project was meant to deliver. Employees may continue to do things as they have been doing them, often manually or on spreadsheets, until they are trained in and fully embrace the new system. Insurance brokerage Willis Group anticipated this problem and took measures to avoid it. Project leaders recognized that the new IT platform it was building for its core transactions would change the way more than 1,000 people carried out their daily work. Program managers spent as much effort to understand and prepare for the organizational changes that would accompany the new system as they did for the technological and operational changes. Months before the rollout, they invested time, informing staff how their tasks would change with the new system. Willis also recognized that without proper training, positive reinforcement and incentives, people would become frustrated and fail to adopt the system. Most employees were eager to trade in the old green-screen system for the newer one with a graphical interface— even though the demands of legacy policies required them to run the new system beside the old for more than a year. Meanwhile, Willis encouraged user feedback on the new system and released updated features every few months, which showed employees their issues were being heard and addressed. Once the new system has been rolled out, it’s important to continue to measure the operational and behavioral changes that will lead to the sought-after benefits. In the short term, measuring uptake can be a proxy for seeing how well the project is moving toward its goals. Willis had clear goals for its system, including improving client services and processing efficiency, and it measured its progress on achieving them during the rollout and beyond. Manage the program efficiently The key that unlocks success across a transformative IT project is the work of a rigorous, disciplined and smooth-running program management organization (PMO). While project leaders guide the progress of the actual implementation, the PMO works at a level above to ensure that critical milestones are met. If the program begins to miss its goals or threatens to veer off track, the PMO flags these risks and has the authority to make decisive changes to restore progress. An effective PMO needs senior management’s visible sponsorship and active support to resolve conflicts. EMC’s decision to appoint senior executives from the business and IT sides ensured they had the credibility and authority to work effectively with managers across different functions and keep the project within scope. The PMO works with project leaders to clearly define the project’s goals and keep the program’s business requirements in sight, making sure that the business side continues to own the project. In cases where the IT side begins to dominate a project, it may try to make decisions that it lacks the authority to make. Program managers can arbitrate in these situations, tilting control back in favor of the business side. Program managers can also help project leaders set realistic deadlines. Without their assistance, a can-do culture sometimes leads project managers to agree to deadlines they can’t meet. They then struggle to make a heroic effort and deliver projects that meet only two-thirds of the requirements. Effective program managers also empower project leaders to make decisions relevant to their domains. But when bottlenecks begin to form, they use their authority to make decisions that keep projects moving. Sometimes that requires managing interdependencies across the company—for example, between the transformation program and other initiatives that may also be underway. All the while, the PMO is making sure the necessary resources are in place and managing relevant risks.

Every year, companies invest hundreds of billions of dollars in large IT projects to enable strategic initiatives or to upgrade aging systems, but fail to reap their promised benefits. Sometimes those projects suffer because they aren’t adequately planned or correctly scoped. In other cases, it’s because senior executives don’t realize that IT transformations are as much about the organization and its operations as they are about the technology. They may lose sight of the project’s business goals or fail to put in program leaders who are senior enough to motivate change. In some instances, a poor choice of vendors or inefficient vendor management exacerbates the problems.

Those costly failures remain one of the toughest challenges facing CIOs and the businesses they serve. According to the Standish Group, which measures performance success in IT projects, more than 60% of the IT projects conducted in 2010 failed to deliver on their goals because they either came in late or over budget, or they had fewer features than were originally specified. Since global investments in IT will total more than $2 trillion in 2012, according to Forrester Research, the total cost of this wasted effort is substantial.

Given that the pace of change is quickening in information technology, it’s never been more important to understand how to make these transformations succeed. Companies can’t afford to waste time and effort on projects that don’t deliver. Our work with leaders across industries and regions has allowed us to identify five key steps to success—actions that may be simple to describe but difficult to execute (see Figure 1).

Set up properly

The first step in any transformation is to make sure that managers and teams—whether they are from the business, IT or operations side—understand the investment rationale and the business goals they are pursuing. Goals should be quantifiable in the form of top-line growth, cost savings or mitigating the risks associated with running obsolete systems. Before committing to the project, it’s important to have consensus that investing in IT is the best way to reach these goals. Sometimes organizations look to technology to solve problems that are actually more about process, organization, talent or even business models. Comparing the cost of an IT investment with other solutions, such as process changes or outsourcing, can give company leaders a clear understanding of the trade-offs. And sometimes, it directs them to try other solutions that are less expensive or risky.

Another key to proper setup is getting the right people on the team—especially the right program leaders— from both the business and technology sides. Overinvesting in talent at the beginning can save time, money and effort in later phases of the project. When EMC, a leader in data storage, information management and cloud computing, decided to replace its old financial and manufacturing systems with a new system from SAP, it tapped two senior executives to lead the transformation: the worldwide controller’s direct report and the manager of its largest factory. The opportunity cost of pulling these leaders out of their positions for two to three years was high, but EMC recognized that managers of this stature were essential to the program’s success. To reassure them that this tour of duty wouldn’t derail their careers, top management stressed the program’s importance to the company’s strategic vision and the impact they would have on EMC’s future performance. Top management also outlined the path they would take back to the day-to-day organization once the program was completed.

The care that EMC took, placing senior financial and manufacturing executives at the helm of its new IT initiative, underlines the necessity of having program leaders who understand the company’s business goals, can clearly articulate the project’s value and can mobilize the troops to deliver. Unlike some other large investments in infrastructure—new manufacturing facilities, for example—IT projects often struggle to find a business sponsor, even though they may cost several times as much as more visible projects. Investing in the best available technical talent—system architects, analysts and software developers—also pays off with systems that are more robust, user-friendly and adaptable to future needs.

Equally important is choosing the right vendors and ensuring they are properly managed. IT projects often falter because vendors fail to meet their commitments, either because they don’t have the right capabilities or won’t commit the resources they had promised when they won the bid. IT program managers have a responsibility to vet the vendor thoroughly and to create the ongoing conditions for success through active communication and efficient coordination.

Design, build and test effectively

No complex project can deliver on its goals unless the internal team and outside contractors communicate effectively, track their progress with agreed-upon metrics and are held accountable for delivering results. Since high-profile IT projects are particularly prone to drifting off course, managers need to be vigilant against scope creep, which can cause projects to bog down or deviate from their original goals. Some expansion in scope may be justifiable, as was the case at Banco Bradesco, currently Brazil’s third-largest bank: During a multiyear IT transformation program, managers had to update requirements to stay current with market and regulatory demands. But in general, proper scoping that defines what the project will and won’t accomplish reduces the likelihood of an overbuilt system, or one that requires that additional features be “bolted on” during later stages or after delivery.

A common mistake is investing in customization when off-the-shelf solutions would accomplish most of the project’s goals at a lower cost. Program leaders must have the authority to resist demands for customization that adds little value. Users who lobby to add customized features during the design phase tend to overestimate their value, while underestimating the costs to build and support them over the project’s lifetime.

At EMC, program managers created a council for reviewing and limiting code customization, to ensure any new coding served the program’s business goals and remained at a level that would keep the system on the vendor upgrade path. A good guideline is to limit customization to no more than 5% to 10% of code, and those modifications should focus on core capabilities that are essential to success. Customization beyond these levels can make future upgrades too costly and time consuming, undermining a fundamental benefit of packaged software.

Scoping the project properly at the outset also lays the groundwork for more efficient testing. Designers should give nearly as much thought to testing as they do to functionality, and ideally they should define both during the planning phase. Trials need to be robust enough to ensure the new systems can handle everyday demand once they are deployed and include stress testing that subjects them to peak loads. At Bradesco, developers were able to speed up testing of new off-the-shelf solutions for the bank’s mortgage department by focusing first on a subset of 12 tasks that made up the bulk of operations, rather than the entire suite of 40 tasks. This way, piloting the commercialization of mortgages with the new systems—in order to further stress test them— could start well before the entire test suite was complete.

Because acceptance testing proves to be a popular time for users to request new features, project managers should be prepared to evaluate those requests in the context of the project’s original goals—and with as keen a lookout for scope creep as they had in the initial design.

Manage change actively

Successful change management has as much to do with the work that teams do six to nine months before rollout as with efforts put forth at the time of launch. As in the planning process, company leaders should articulate and reinforce the project’s business goals long before the actual transformation, but at this point, their audience should be expanded to include all of the employees who will use the system.

Bradesco planted the seeds of change well in advance of the phased rollout of its new IT systems by creating an entire department to prepare business areas for each new system rollout, as well as to capture its benefits and measure the uptake after rollout. The bank also provided user teams with detailed plans describing how daily operations would change, as well as how, where and when it would pilot each new system. System business owners and program “evangelists” were trained in the new processes so that they would be ready to coach others, and help-desk staff was prepared to support the transition. This enabled frontline employees to easily support the organizational transformation when the new systems arrived.

Realize the benefits

Without proper training and motivation, people tend to underutilize new tools, whether they are a consumer’s new digital camera or a corporation’s advanced enterprise resource planning (ERP) system. When new IT projects are rolled out, old habits and processes can sabotage the realization of the benefits the project was meant to deliver. Employees may continue to do things as they have been doing them, often manually or on spreadsheets, until they are trained in and fully embrace the new system.

Insurance brokerage Willis Group anticipated this problem and took measures to avoid it. Project leaders recognized that the new IT platform it was building for its core transactions would change the way more than 1,000 people carried out their daily work. Program managers spent as much effort to understand and prepare for the organizational changes that would accompany the new system as they did for the technological and operational changes. Months before the rollout, they invested time, informing staff how their tasks would change with the new system.

Willis also recognized that without proper training, positive reinforcement and incentives, people would become frustrated and fail to adopt the system. Most employees were eager to trade in the old green-screen system for the newer one with a graphical interface— even though the demands of legacy policies required them to run the new system beside the old for more than a year. Meanwhile, Willis encouraged user feedback on the new system and released updated features every few months, which showed employees their issues were being heard and addressed.

Once the new system has been rolled out, it’s important to continue to measure the operational and behavioral changes that will lead to the sought-after benefits. In the short term, measuring uptake can be a proxy for seeing how well the project is moving toward its goals. Willis had clear goals for its system, including improving client services and processing efficiency, and it measured its progress on achieving them during the rollout and beyond.

Manage the program efficiently

The key that unlocks success across a transformative IT project is the work of a rigorous, disciplined and smooth-running program management organization (PMO). While project leaders guide the progress of the actual implementation, the PMO works at a level above to ensure that critical milestones are met. If the program begins to miss its goals or threatens to veer off track, the PMO flags these risks and has the authority to make decisive changes to restore progress.

An effective PMO needs senior management’s visible sponsorship and active support to resolve conflicts. EMC’s decision to appoint senior executives from the business and IT sides ensured they had the credibility and authority to work effectively with managers across different functions and keep the project within scope.

The PMO works with project leaders to clearly define the project’s goals and keep the program’s business requirements in sight, making sure that the business side continues to own the project. In cases where the IT side begins to dominate a project, it may try to make decisions that it lacks the authority to make. Program managers can arbitrate in these situations, tilting control back in favor of the business side.

Program managers can also help project leaders set realistic deadlines. Without their assistance, a can-do culture sometimes leads project managers to agree to deadlines they can’t meet. They then struggle to make a heroic effort and deliver projects that meet only two-thirds of the requirements.

Effective program managers also empower project leaders to make decisions relevant to their domains. But when bottlenecks begin to form, they use their authority to make decisions that keep projects moving. Sometimes that requires managing interdependencies across the company—for example, between the transformation program and other initiatives that may also be underway. All the while, the PMO is making sure the necessary resources are in place and managing relevant risks.