Large-Scale IT Projects: From Nightmare to Value Creation

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.

Why Do So Many Large IT Projects Run into Trouble?

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.

Setting the Project Up for Success

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.

• Scope and Objectives. Time is invested up front to determine the right project scope and to make sure that all relevant parties are crystal clear on what needs to be developed.
• Business Value and Economics. A positive business case for the project is developed and validated prelaunch; then the case is tested against scenarios that reflect risks that might emerge.
• Governance and Organization. Leaders are selected who have deep practical experience with similar large projects, and they create a culture of openness and transparency. Stakeholders are actively engaged and accountabilities are clear.
• Solutions and Deliverables. Solutions are designed and validated in a well-structured, methodical way—whether through agile or waterfall development practices—and efforts are made to minimize the customization of standard software. (See “Is Agile Development the Answer?”)
• Planning and Execution. A strong, proactive project-management organization, as well as a project-design authority structure that seeks to identify and tackle problems early on, are put in place at the outset.

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.

Steps for Business Sponsors and CIOs

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.