Partner and Director, Technology & Digital Transformation
Related Expertise: Digital, Technology, and Data
For business leaders, the decision to embark on a large-scale IT initiative (that is, one with an investment of more than $10 million) is often fraught with angst. Their worries are justified. According to one large study, the chances of delivering such a project successfully—on time, on budget, and with the desired technical objectives met—are roughly one in ten. (See Exhibit 1.) And the cost of failure can be quite large: we estimate that the potential lost value from a major project delay, for example, can range from 100 to 170 percent of the investment cost.
Companies cannot run from the challenge, however. IT underpins an increasing percentage of essential business transformation initiatives, such as the establishment of digital business models and big-data capabilities. The need for substantial IT investments can also arise when large supplier contracts expire or legacy IT systems reach the end of their lives. Large-scale IT investments are therefore unavoidable. Can steps be taken to materially improve a large IT project’s chances of success? The answer is an emphatic yes—assuming that executives know where to focus their efforts.
Large IT projects are vastly more difficult to deliver successfully than smaller ones, because a project’s complexity, interdependencies, and communication challenges grow exponentially as the project grows in size. What works well for the execution of small projects rarely suffices for the execution of large ones.
Although every major IT project and its circumstances are unique, projects that are flagging often have common characteristics.
Inexperienced Project Teams. Experience matters in large projects. Something we commonly see among project teams that lack large-project experience is the inability to anticipate all the various activities that will be required as the project’s complexity grows. Such teams will underestimate the amount of testing activity necessary, for instance, or commit to aggressive milestones without underpinning this commitment with a bottom-up plan. Projects involving such teams frequently start to miss critical milestones and can even lose the confidence of senior stakeholders.
Lack of Engagement from Key Stakeholders. Projects that lack sufficient buy-in from the business—a situation often triggered by an absence of clarity about the project’s economics, scope, business strategy, or execution—can find themselves struggling for the necessary resources.
Requirements That Are Unclear or Too Complex Relative to the Business’s Needs. Many companies either fail to define (and document) projects’ business requirements at a sufficient level of detail—or define requirements that are too complex. They often make matters worse by pursuing development before all requirements are fully defined, which can result in “requirement churn” and lead to expensive redefinitions late in the game.
Insufficient Attention to Major Risks. Frank talk about project risks often gets “squeezed out” of the discussion in formal governance activities at status meetings or meetings of the project steering group. Those intimately involved in the project get so close to the details that they cannot see the forest for the trees. One of the most commonly shortchanged risks, and a particularly critical one, is the risk associated with data. Poor-quality data, or data designs that have not been sufficiently validated early in the project, can undermine the project, as can a failure to think through the risks of data migration. Another risk that is often insufficiently discussed and planned for is the set of challenges accompanying projects that span multiple markets or countries: there may be material differences in products, processes, languages, and regulatory environments that cannot be left to chance. Yet another risk that is often poorly prepared for and managed is the risk that project teams incur when they commit to a specific delivery date (for example, the date when a contract with a key supplier will expire) without giving themselves the flexibility to change the date if the project is delayed. Although a sense of urgency can help a team focus, an overly aggressive schedule can lead to suboptimal decisions and compromises that cause lasting damage.
Taking the Solution Live Without Sufficient Testing. Companies typically plan sufficient time for testing. What often happens, however, is that the time available for testing gets compressed because delays in earlier activities, such as development, lead to the shortchanging of critical testing activities, including performance testing. The resulting toll can be steep, because once a solution goes live, fixing problems is vastly more expensive and difficult. And the business consequences of poor-quality software can be severe.
Failure to Manage the Project Plan Effectively. Projects whose leadership fails to detect early warning signs of major problems or a growing risk of missing milestones tend to lurch from crisis to crisis—and repeatedly surprise stakeholders as milestones are missed.
Insufficient Attention to Change Management. Although much has been written about change management in the last 20 years, we often still see project leaders underestimating what is involved in managing the human side of change. Leaders will devote insufficient resources to this aspect of their projects or generally be unaware of the extent of behavioral changes necessary for a successful outcome.
Any one of these conditions can be enough to undermine a project. More commonly, we find that projects that are going or have gone off the rails are characterized by several.
Despite the long odds, large IT projects can be delivered successfully. In our experience, however, winning in this realm is not luck. Rather, it is the result of careful, rigorous planning and attention to detail. From our analysis of successful projects, we have identified best practices in five domains.
Agile-development approaches are often touted as an alternative to large projects, and a number of BCG clients have had success with them. The concept is to break system development down into smaller chunks, or short “sprints,” of coding, delivered by a “scrum” team of developers that is supported by analysts, designers, and business “product owners.” The aim is to create some working software within a compressed time frame—typically two to four weeks. Multiple such sprints are strung together to develop a complete working system. Given that there is a strong correlation between the size of the development effort (smaller is better) and a project’s success, this approach is logical and can be very effective with the right team, modern development technologies, and the right level of business support. In particular, agile approaches can promote significantly faster time to benefits delivery, as well as better testing and deployment practices, leading to higher-quality delivery.
Agile by itself, however, is insufficient. It can be a very effective methodology for the pursuit of one critical dimension of the quality assurance framework—namely, solutions and deliverables. But its success is dependent on good practices in the framework’s other four dimensions—namely, scope and objectives, business value and economics, governance and organization, and planning and execution. Some of the biggest project failures we have seen, in fact, involved agile development deployed in a context of poorly defined business requirements and an inexperienced project team; this unfortunate mix led to serious problems, such as major gaps in requirements, lack of documentation, heavily customized “standard” software packages, and poorly performing systems.
In short, agile approaches are not a silver bullet. But they can be very helpful, even critical, in the delivery of digital process transformation and big-data initiatives.
These best practices can be codified and “baked into” a project through the use of a quality assurance scorecard, which can be a powerful tool for encouraging their adoption early in a project’s life. (See Exhibit 2.) Such scorecards can also promote better practices during the project’s execution and spread them to other projects that the company is undertaking or planning to undertake. Presented at steering-group meetings, the scorecards can also reassure stakeholders that progress is being made and that the project is under control.
Paying attention to these critical success factors early in a project’s setup can make a sizable difference in the outcome. BCG recently played the role of independent quality-assurance partner to a major U.S. utility that was implementing SAP enterprise software. The company had a history of troubled projects. BCG worked with the project team and the sponsor to ensure that optimized critical practices were established at the project’s launch and were measured through scorecards, surveys, and in-depth interviews. This early intervention ensured that the project team got off to a good start. Although the project’s execution wasn’t flawless, and various “course corrections” were needed, the project was delivered on time and on budget, and proved to be the most successful large project in the company’s history. What is the size of the prize for successful execution of large projects? As noted, the potential lost value from a major project delay can range from 100 to 170 percent of the investment cost. In our experience, a 50 percent reduction in delays, cost overruns, and other problems across a portfolio of projects could easily produce economic benefits equivalent to 15 to 20 percent of total portfolio spending—significant money that could be devoted to other initiatives.
Business sponsors and the CIO can take a number of steps to maximize the odds of a large IT project’s success.
Challenge the decision to proceed with a large project; if possible, try to break the effort down into smaller, more manageable chunks, or “releases.” Assuming there is consensus on proceeding with a piecemeal approach, strive to minimize interdependencies among projects in the planning stage and be clear on the minimum viable scope for a first release in order to reduce that release’s scope and risk.
Get the right project leadership in place early. Select a project director who has significant experience with projects of this type and who will have the trust of senior executives. Seating the right leader should be carried out early in the project’s life to ensure that setup activities are properly executed, giving the project the maximum chances of success.
Make sure that the project team spends time up front defining and gaining clarity on the project’s scope, high-level business requirements, benefits, and costs. The urge to launch the project and demonstrate progress quickly is understandable, but lack of clarity regarding direction is frequently a root cause of failure. It’s often tempting to skip the definition of requirements in particular, but doing so almost always leads to trouble down the line.
Select a vendor that has done a large project of this type before, if possible, and establish the right contract. The contract should, for example, spell out risks and ensure that key members of the supplier’s team are available for and committed to the project. It should also ensure that the vendor is committed to delivering the project’s targeted outcomes.
Work to engage stakeholders. Try to ensure that the project has a culture of openness and transparency, and that business stakeholders understand their roles and responsibilities and are fully committed to them.
Confirm that the project’s risks are being proactively managed. Demand to see evidence of risk-identification and risk-mitigation plans and measures, and commit to staying informed.
Given today’s rapidly evolving business environment, the ability to deliver large-scale IT projects successfully stands to become an increasingly critical competitive differentiator for companies (as well as an increasingly used yardstick for gauging the performance of leaders, including CIOs). The levers discussed above should be viewed as essential enablers of any such project.