Digital business models and transforming core applications can drive strong business value. However, most large IT initiatives fail to meet expectations. McKinsey & Company found that 66% of big IT projects exceed budget and 33% run longer than planned[1]. Businesses need a new approach.
Many companies concentrate on defining requirements, then turn to engineering solutions. IT leaders often approach their organizations as a machine: specifications in, code out. However, initiatives such as legacy platform modernization or post-merger integration involving changing how people work, require new team capabilities, and bring new risks. Experience leading several large transformations shows CIOs should first motivate people, build required team capabilities, and structure processes to minimize risks.
Transform Attitudes, not Technology
Technology leaders can refer to some people as ten times as productive as others. However, many more have the potential, and the concept applies also to teams. Leaders unlock this productivity by focusing on people, rather than outputs.
Engineering managers are often selected for expertise as much as for empathy. A first step in technology transformation is equipping managers to lead change. A CIO should explicitly cultivate effective change leadership. The Kotter 8-Step Change Model[2] provides a straightforward approach. Ask for written change leadership plans to build confidence and encourage taking responsibility.
The American politician Tipp O’Neill said “all politics is local”. The same applies to transforming enterprise applications. Leaders should ensure every person understands what change means for them. Share positive opportunities such as broader career options or learning new technologies. People should understand that they are valued for business and customer understanding rather than technical skills.
Communication should explain why as much as what will change. Consider getting strategists and engineers together to explain the competitive landscape and how projects produce value for customers. Seek opportunities for engineers to join customer meetings: even with strong product managers, many design decisions, such as how to organize data, are best made by directly understanding the customer environment.
Offshore locations need to feel respected to achieve top productivity. People will deliver best when given full responsibility rather than serving as support. Consider assigning end-to-end responsibility for part of a project, with local managers accountable. At Citigroup, for example, we experienced a strong surge from an already-productive Sydney team when given responsibility globally for all retirement and superannuation analytics.
CIOs often get best results leading talented engineers to their own decisions. At Thomson Reuters, we formed working groups headed by junior managers that recommended how to implement change. This enables teams to self-attribute and “own” actions. Junior people will also often identify very concrete and immediate actions, which leads to credibility and early wins.
Realistically Assess and Build Capabilities
A simple test can assess capabilities: has a person or team recently delivered a similarly scaled project? Agile program management, quality assurance, and user experience design are most likely to need strengthening. Consider bringing in people from software vendors or companies that regularly deliver new versions. Avoid the temptation to save by having project leadership performed solely by managers.
The ultimate success of many large projects depends on quality assurance. Managers often assess the ratio of testers to developers, which is meaningful, but a small part. Quality (and cybersecurity, which depends in part on quality code) should be built into development from the start. Program managers should ensure test cases are defined, with developers creating small “unit tests” continually applied in an automated framework.
Early in a project, the CIO should collaborate with finance on investments for test environments. Consider using cloud services, which can shift capital expenditures to operating expenditures. Test environments and data should be as similar as possible to production.
Test case management and trend analysis is critical. Solid test case management checks the full spectrum of risks, identifies dependencies such as customer data, and identifies trends and emerging risks. Importantly, strong test case management enables accurately forecasting completion dates.
At the same time, do not rely wholly on structured testing. The intuition of senior engineers and client service people can be very valuable for identifying risks or behaviors not captured in test plans. Test plans should specifically include experts trying to break the application.
User experience design is increasingly important to product strategy. Professional design costs little relative to the value of elegant workflows, screen designs, and visualization. Designers are also critical to a “code talks” approach to agile development, where teams use frequent visual mockups to confirm evolving business needs.
Deliver Fast and Frequently
Waterfall methodologies are inherently mismatched to large projects. Annual capital budgeting cycles can prompt development teams to think in similar timeframes. However, customer needs, RFP details, or M&A are difficult predict over long periods. Big projects should use many, smaller iterations to show results early and confirm alignment regularly.
At the CIO level, insist on broad principles of agile delivery rather than a specific methodology: small phases of two to six weeks (monthly works well); emphasize mockups and pilots rather than documents; and have developers synchronize and perform automated tests on code each day. Individual locations may choose specific agile methodologies, such as Kanban or scrum, which work best within a given geographic location.
Business sponsors naturally focus on functional requirements. Technology leaders should treat non-functional requirements, such as scalability or cybersecurity, as equal priorities. These are achieved more cost-effectively early in the process, and often involve investments and tradeoffs best steered by the CIO.
All big IT projects are business projects. Transformational projects should involve all parts of the business. At the start, CIOs should involve peers in communication campaigns. An easy option is sharing short video interviews with business leaders. Each agile iteration offers to get the whole business involved. Gaining alignment does not end with development: QA is often strongest with test cases defined and performed by client services and others who will use the product.
Go Live Gracefully
Bringing new software releases into production is a critical point for motivating people and limiting risk. Consider a global credit card payment processor creating a new core platform. The waterfall plan called for development for six months, followed by four months of testing, and then a launch event coordinated with sales and service. However, several customers shared RFPs prompting the team to add features. Testing will be compressed. The CIO gets nervous, and demands more reports. Managers set additional meetings to prepare these updates. With pressure mounting, a key engineer gets sick. As the launch approaches, a salesperson calls a development manager directly to persuade her to add a feature; there will not be time to test this feature.
The team begins installation on a Saturday night. However, the application unexpectedly fails to communicate with a disaster recovery location. This was never tested in the small QA environment. Saturday gives way to Sunday as engineers frantically try to diagnose the issue. Senior managers consider cancelling the launch. However, reverting to the prior version requires manually reconnecting to dozens of other systems and the main expert is out sick. The team must continue the launch.
On Sunday morning, the CIO visits the operations team. Her presence further raises anxiety. The CIO overhears a senior developer complain that this is the fourth time a troubled product launch forced her to scramble to find child care on short notice. As the Asian day begins, customers are unable to use the application. The CIO feels her phone vibrate. The CEO is calling.
Alternatively, consider the same company using processes centered on motivating people and containing risk. Sales leaders saw IT consistently deliver new iterations of the product for many months. They trust IT will continue this pattern, and agree to defer some features until after launch. The CIO made the case to investment in test environments nearly matching production, and test case management has tracked non-functional requirements including disaster recovery for several months.
As the launch approaches, the team installs new software on a parallel production environment while keeping existing systems. Final checks are performed during regular hours in the week leading up to launch. IT plans a six hour maintenance window, but the actual cutover and final automated checks take about an hour. Many customers do not notice. The CIO wakes at home on Sunday morning, glances at her phone to check production volume, and reminds herself to ask the CEO to recognize key people.
Conclusion
Technology transformation comes from people. Rather than the traditional focus on business requirements and engineering, IT leaders starting large new projects should concentrate first on leading change and communicating effectively. Projects like legacy platform modernization bring new demands on an organization. Leaders need to assess whether the team has the project leadership, quality, and user experience design capabilities needed. With testing, consider the readiness of test environments and data as much as people capabilities. In development, break big problems into small parts delivered in a disciplined cadence of iterations. Tactfully insist that each iteration approaches production readiness. Finally, use automation, rehearsals, and parallel environments for graceful deployment. Each successful release will build team momentum and execution velocity.
[1] http://www.mckinsey.com/insights/business_technology/achieving_success_in_large_complex_software_projects
[2] http://www.kotterinternational.com/the-8-step-process-for-leading-change/