Why Bigger IT Projects Are Not Always Better

Declarations like "We have a megaproject going on" seem designed almost entirely to justify one's existence or to boost one's ego.

When I talk with my counterparts about what's happening in their worlds, I'm amazed at how often they boast about the "huge" projects they're managing. Declarations like "We have a megaproject going on" seem designed almost entirely to justify one's existence or to boost one's ego.

In my experience, I've done everything I could to keep from taking on megaprojects. As a CIO, I worked hard not to embark on multi-year "death marches" that could stop things to the point of putting the business at risk. Instead, I tried to practice fiscal fitness every day -- rather than realizing too late that it was time to do something about those nagging symptoms. But despite the best strategy and planning, big programs are sometimes inevitable. In those cases, I made them as painless as possible.

There are a number of principles that hold true for big, multi-year projects:

1. Large projects fail more often than small ones. Using real-life case studies and other methods, The Standish Group looks at every facet of project management and identifies some key traits among successful and unsuccessful projects. According to its 2013 Chaos Manifesto, very few large projects perform well under the triple constraints of cost, time, and scope. In contrast to small projects, which are more than 70% likely to succeed, large projects have virtually no chance of coming in on time, on budget, or within scope. Instead, major initiatives are twice as likely to deliver late, over the budget, or without critical features. Finally, a large project is more than 10 times as likely to fail outright -- meaning it will be cancelled or will go unused because it became obsolete before it was implemented. Bottom line: The larger the project, the less likely it will be to succeed.


2. The bigger the scope, the less you control it. I compare a large project to a bill going through Congress. The longer it takes for the bill to pass, the greater the potential for added pork. Consider the Big Dig: the relocation of 3.5 miles of interstate highway in downtown Boston. The megaproject was expected to take about seven years at a cost of $2.8 billion. Instead, it became the most expensive highway project in US history, taking more than 15 years to complete, with a cost overrun of more than 190% (before adjusting for inflation). Some projections estimate that the project will ultimately cost $22 billion.


3. Advocates for a big project can (and do) move on. All too often during a multi-year implementation, the team -- and especially the sponsors -- change. By the time the project delivers, none of the original advocates may be there to see it put in place. In many cases, I've seen new leadership question the need for the project in the first place -- and then focus on the features and functionality that "should have been included." This sets up the organization for tremendous morale issues as the new system struggles to gain traction with a reluctant user base.


4. Many organizations have low thresholds for pain. Sensitivity to change and ambiguity often leads organizations to push back deadlines, add unnecessary functionality, or relax just as they should be sprinting to the finish line.

[Previously from Shields: Outsourcing IT Takes Three to Tango]

Even with the potential pitfalls, there are times when a major, long-term project makes the most sense. When that happens, there are some things organizations can do to minimize risk and improve their chances of success.

1. Take an agile, multi-phased approach. Though most large projects can be described as having multiple phases, businesses sometimes miss the point of breaking massive initiatives into smaller, more self-sufficient projects that are easier to manage. Some organizations also buy into the fallacy that they have to invest in an entire project. In reality, they need to identify incremental landing points. That way, they can realize value along the way and hold pat or adjust the long-term plan as the business climate changes. This approach can prove challenging, however, when there is "infrastructure" or other supporting work to be done.


2. Stay accountable to business goals. All too often, project managers fail to set real business goals for each phase of a project, and it's even more rare for leadership to hold teams accountable for achieving those improvements. Several years ago, I was involved in a system replacement project. The COO met with IT and business area leaders to identify the improvements, cost savings, and new capabilities we could expect. Each area had to quantify their projected improvements. Then the team committed to hard goals: a 20% reduction in maintenance support costs, a 15% percent reduction in product obsolesce expense, a 12% reduction in call center staff, and 15 fewer days to market for new products. Once the system went live, we had 12 months to deliver the improvements. There were no excuses: If we couldn't deliver returns, we were expected to find them somewhere -- even if it meant giving up our bonuses.


3. Staff with the best, not with the available. In big games, winning coaches play their best athletes, not backups or members of the practice squad. All too frequently, businesses staff projects with people who are available, and not with the best talent for the job.


4. Respect the 80/20 rule. When it comes to application systems and functionality, it is generally accepted that 80% of users use only 20% of features, and about 20% of functionality produces 80% of the value. This also correlates with cost and schedule. Assuming this is true, aim to deliver feature-rich functionality, but focus on added value over wizardry that compounds risk and cost. Do the 80% well, and then iterate as business value allows.


5. Put two in a box. Anyone who has ever been in a canoe with a child knows that it is frustrating (and dangerous) unless the pair can learn to work together. Choose two leaders for each major project: one from the business and one from IT. The duo must be equal in authority and in influence. They must be seen by all involved as true partners -- together "in the box" to deliver a full-featured product on time and on budget. And the "sink or swim" message must be communicated in words and in actions.

[Do you aspire to the C-suite or some other spot in upper IT management? Then bulk up your credentials around today's most pressing IT movement, digital business, at the InformationWeek IT Leadership Summit.]

In taking a more pragmatic approach to the massive megaproject, your business can avoid getting stuck in a doomed effort to deliver something that will be out of date before it ever goes live.

The most successful initiatives effectively balance scope, budget, and timelines -- all while advancing the business and adding measurable value. The bigger the project, the harder teams have to work to manage all the moving parts. So when an organization takes on a megaproject, it's imperative for leadership to set clear objectives and for stakeholders to work smarter and deliver incremental value.

Focus on business strategic objectives. Strive to move the organization forward on a daily basis. That way, your organization could eliminate the need to blow up everything and rebuild with a megaproject. The key benefit of this approach is stability -- in the business, the systems, and your blood pressure.

Gerald Shields is IT Practice Director for The Nolan Company. Gerald has over 30 years' experience managing enterprise scale IT functions, with a focus on enabling the business through effective automation. At Aflac, he served as CIO and in senior IT management for over ten ... View Full Bio