Beating scope creep, the scourge of IT projects

Every year, companies invest hundreds of billions of dollars in large IT projects that fail to deliver on their promises.More than 60% of the IT projects conducted in 2010 fell short of their goals, according to Standish Group, either because they were late, over budget or didn’t have the promised features. Some are poorly planned; sometimes IT chooses the wrong vendors. Often executives don’t fullyrealize that these efforts are as much about transforming the organization and its operations as they are about swapping in new technology. They may lose sight of the project’s business goals or neglect to pick top-notch leaders with enough clout to motivate change.

Whatever the reasons, these costly failures remain among the toughest challenges facing CIOs and the businesses they help manage. Repeated disappointments undermine the credibility of IT and threaten the career prospects of IT leaders.

No single approach can guarantee success, but leading companies typically get five important things right. Proper setup, for example, includes choosing the right talent, especially leaders with the authority to deliver success. A well-planned rollout is also key, along with a plan for measuring uptake and benefits delivered by the new system. And, of course, no transformation succeeds without the guidance of a disciplined and smooth-running program management organization that can make sure critical milestones are met.

But one of the most insidious reasons for failure is scope creep – the tendency to add features before and during development that do little or nothing to meet the program’s goals. High-profile IT projects are particularly prone to this danger, so managers need to guard against it. Proper scoping that defines what the project aims to accomplish – and what it will not – reduces the likelihood of an overbuilt system or one that requires additional features be “bolted on” during later stages or after delivery.

Some expansion may be justifiable: for example, one large South American bank had to update requirements during a multiyear IT transformation project in order to keep up with regulatory and market demands.

But too often, these changes come from an ever-expanding wish list that can bog down the project or steer it completely off course. A common misstep – and the source of many IT project failures – is the tendency to invest in customization when off-the-shelf solutions would accomplish most of the project goals at drastically lower costs. Project leaders need the authority to resist demands for customization where it adds no substantial value. Users who lobby to add specialized functions and features tend to overestimate their value while underestimating the costs to build and support them over the project’s lifetime.

One way to guard against this is to put a gatekeeper in place. An IT services firm that was upgrading its ERP systems created a council tasked with reviewing and limiting code customization, to ensure any investment in coding served the program’s business goals. The council also made sure that the total amount of modified code stayed within a level that assured the system could remain on the vendor upgrade path – no more than 10% customization. Anything beyond these levels can make upgrades too costly, risky and time consuming, undermining a benefit of packaged software.

Scoping the project properly at the outset also lays the groundwork for more efficient testing. In some organizations testing is an afterthought. But designers should give almost as much thought to testing as they do to functionality. 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. In the mortgage department of the South American bank, developers were able to speed up testing by focusing on a subset of 12 tasks that made up the bulk of operations, rather than the entire test suite of 40 tasks.

Testing is a popular time for users to ask for new features, so project managers need to remain vigilant, weighing these requests against the project’s original goals. Throughout the process, they need to maintain as keen a lookout for scope creep as they had at the beginning of its design.

Christian Wessels and Jean-Claude Ramirez