Don’t Let Your Implementation Become a ‘Debacle’ by Kelly Barner

Posted on November 7, 2013


Editor’s Note: In what is another great post from Buyers Meeting Point’s Kelly Barner, she talks about the reasons why 93% of all large technology projects fail.  While I am in agreement with the reasons she gives for these misfires, I believe that the underlying factor that ties them all together is an absence of collaboration and transparency involving all stakeholders.  In short, and until the framework of a true Relational Model has been incorporated into the process, failures such as will continue to be the rule as opposed to the exception.

The October 1st rollout of, the United States federal web marketplace for health insurance, has given all Americans a close look at a large IT project gone wrong. Although this particular ‘debacle’, as it was described in Congressional hearings last week, has been highly visible and thoroughly publicized, it is not unique. In fact, according to a study conducted by the Standish Group for Computerworld, only 6.4% of IT projects with labor costs over $10M are successful. In other words, over 93% of all large technology projects fail.

The Standish Group study was based on a database of 50,000 development projects that took place between 2003 and 2012. 3,555 of the projects cost over $10M. The unsuccessful projects included 52% that were ‘challenged’, coming in over budget, behind schedule, and below user expectations, and 42.4% that were deemed complete failures and were either abandoned altogether or started over from scratch.

Even though the majority of the projects in the study were software development efforts, the lessons learned easily apply to technology implementations of all kinds and sizes, including cloud or ‘software as a service’ deployments of eSourcing and eProcurement solutions. Just because you don’t plan to spend $10M on labor, don’t think you are safe from the risks that plague larger, more complex efforts.

Lack of Centralized Leadership

Cross-functional teams may be the best way to build buy-in and get a comprehensive list of requirements, but there needs to be one person that is ultimately responsible for making decisions and keeping the project on track. This need is amplified when solutions from multiple vendors are being integrated, whether one is already in place or both are being implemented in parallel. The person with this responsibility needs to have a sufficient level of authority to make the project a success. “The transformational power of technology needs a leader with the clout to make it work” (Mele). In fact, a special project-based appointment may be required in order to get the right combination of skills and influence.

Insufficient Testing

We’ve all been conditioned to expect upgrades or updates that contain overlooked functionality or bug fixes in our personal gadgets. Many software developers subscribe to a philosophy of releasing early and often, expecting that feedback from users will drive ongoing changes to functionality. This does not mean that users have low expectations of the technology they interact with, newly implemented or otherwise. In fact, the high level of technology adoption in our personal lives often means that our tolerance for slow speeds or non-intuitive interfaces is very low, and we are accustomed to having the option of quickly moving on to something better. Pre-release testing needs to address realistic traffic levels, security concerns, and a seamless match between established work processes and enabling technology.

The ‘Big Bang’ Rollout

Even when a proper testing effort is made, it is still wise to stage a rollout, starting with one category or business unit and allowing for the opportunity to learn and adjust before bringing other users on board. “Many large projects are rolled out slowly and incrementally to allow extended testing and feedback” said Jim Johnson, founder and chairman of the Standish Group. The higher the visibility of the project and the higher the expectations, the more is at stake. While there may be pressure to roll out as quickly as possible, if issues are encountered it is hard to pull back once the process has begun – and negative reactions often travel through a user population faster than neutral or positive ones.

There are many examples of poorly executed technology implementations and development efforts, and they include efforts in both the public and private sectors. Seemingly impossible scale, complexity and high innovation requirements can quickly affect a project team’s reputation and career aspirations. Just ask Kathleen Sebelius, who had to answer to her own ‘executive stakeholders’ this week, while the homepage of the website in question read,

“The system is down at the moment.”

Additional Reading:

Nicco Mele “Hidden lessons from’s failure” USA Today: 1 November 2013.

Patrick Thibodeau “ website ‘didn’t have a chance in hell’” Computerworld: 21 October 2013.

Tom Cohen, Holly Yen “All apologies: Biden, Sebelius sorry for Obamacare site debacle” CNN: 31 October 2013.