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.
