This content is part of the Essential Guide: IT services management and best practices: An enterprise CIO guide
Manage Learn to apply best practices and optimize your operations.

Business Mentor: Truth Behind IT Project Failure Is Users Hate Change

How to help users accept change.

A few years ago, I hit a snag during an enterprise resource planning (ERP) project: Purchasing agents refused to change the way they created drop-ship purchase orders even though the legacy system required agents to create a separate purchase order for each site needing materials.

With the new system, purchasing personnel could create a single order with multiple ship-to addresses, an approach that would significantly reduce data entry. But rather than adopt a process improvement, agents held out for a customization that would make things the way they were before. Ultimately, however, they were pressured into adopting the new system and even thanked me for how much easier it was to create drop-ship purchase orders.

I recalled this experience as I reviewed research on IT project failure. Research indicates that the No. 1 reason for a project failing to meet its objectives has nothing to do with poorly defined requirements or project planning or scope creep; the most significant factor is people's resistance to changing their behavior. This factor is paramount regardless of project length or complexity or company size.

How to Bring About Change

I used to believe the conventional wisdom: If only we had a well-formulated change management strategy -- one with strong executive support, a solid training plan and performance metrics linked to project success -- the required behavioral change would follow. Yet after conventional change management plans failed me, I sought out one of my IT mentors. His career has been marked by a series of change initiatives, so I asked him to share his secret for successfully instituting change. He relayed these truisms: (1) We prefer the familiar to the comfortable, and (2) we prefer the comfortable to the better.

The first truth means that even though our current process is painful (i.e., the legacy system requires workarounds, so I have to create a separate purchase order for every drop-ship site), we are reluctant to reduce the pain (by implementing a more comfortable process). In other words, reducing pain may not be enough to motivate me to change.

The second truth means that even if we are presented with compelling reasons to change our behavior (i.e., change will improve customer service and response times and reduce costs), we resist it because we are comfortable with how we do things today. In other words, a promise of improved results may not be enough to motivate me to change.

The Comfort of the Familiar

If these two truths hold up under scrutiny, how can we successfully implement change? We need to make the new behavior both familiar and comfortable. To that end, we have instituted the following processes:

  • We conduct manual, paper-based simulations of workflows and transactions before we even test the new system.
  • We schedule the new system to go live only after we have instituted new workflows and business rules (for example, in the legacy system, we create a single purchase order with multiple ship-to addresses).
  • We pick pilot products and model the process and behavior changes before finalizing or expanding system usage.

Making what's better familiar and comfortable has reduced my project risks and added years onto my life.

Niel Nickolaisen is CIO and vice president of strategic planning at Headwaters Inc. in South Jordan, Utah. To comment on this story, email

Dig Deeper on Small-business IT strategy

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.