IT Change Management – Improve your odds

diceThe software is selected, the hardware is installed and the training has been delivered.   Yet 70% of IT change projects never achieve desired results.  Worse, there is a general lack of agreement on how and why technology succeeds and fails in organizations, In 2010, I undertook a research project on the topic of IT change with the goal to improve the odds—to create successful IT change projects. 

Building on academic research, this project focused on factors of influence which work together to drive technology use in organisations.

Buyers, vendors, and even academics sometimes confuse technology acquisition with technology change—believing that selection and planning alone is enough to achieve the organisational strategy.  But, features don’t solve business problems, people do.

The reality is that 2 similar organisations can acquire 2 similar technologies and yet experience very different results.

Core to understanding these differences is the concept of ‘agency’—the people who influence technology use…the developers, designers, leaders, project managers and users.  They all come to IT change with expectations and goals. 

And, while we like to think we have control over these agents, the fact is people can be a bit…well, unpredictable.

Understanding technology use requires attention to people, their goals and, most importantly, their interactions. 

The factors are explained using the following case study:

You can also request a copy of the white paper or academic essay on the contact page of this site.

The case of the ad hoc database

 In 2004, iWork (a pseudonym) selected and implemented a new software for administration.  The system was being used by a number of similar organisations to iWork.   The software was intended to be a total solution that customers, partners, leaders, and employees could use to connect through a single application. 

However, one department within iWork did not fully adopt the technology.  Instead, they created a new technology—a database and user interface, which has now been in use for approximately 4 years.  A series of interviews conducted with stakeholders across the organisation were used to understand the factors that influenced the creation of this ad hoc database.

IT Change Lesson 1:

Align your goals

Goals—those internal ideas people hold that drive their actions. Everyone in your project has them…developers, designers, project managers, users, and leaders. The challenge is getting all of these goals to line up in a way that gets everyone focused on the same ones at the same time.

In technology implementations, we often get caught up in our project goals – meeting the deadlines, staying on budget, developing the features and training materials. But, don’t lose sight of the bigger goals – the reasons you started the project in the first place. You need people to actually use the stuff your are buidling and implementing. And using it means finding some goals in common between the users and the project team.

“When the technology does not help people achieve their ends, they abandon it, or work around it, or change it, or think about changing their ends.”*

The case of the ad hoc database…

The senior leaders at iWork planned to capture data across all departments in order to create effeciency and improve customer experience. But the new system performed slowly, was difficult to understand, and added time to users’ tasks, who were already feeling overworked. The users’ goals (to reduce time spent on tasks) did not align to the leaders’ goals (a central data repository).

goalsResearch has shown that individuals will be more committed to goals which are intrinsic (important to them) – not extrinsic (important to their boss or the project manager).**

Interestingly, this is especially problematic in implementations of vendor-created software when there designers may have embedded unwanted constraints into the system – interfering with users achieving their goals.

The solution? iWork needed to surface the goals and assumptions of both the project team and the leaders early and look for common ground – goals that were intrinsic to all. Then, they could have recruited end users to look for creative solutions that blended their goals with those of the other project stakeholders. But, that didn’t happen. When the users tried to discuss their goals, they felt ignored. In response they channeled their creative efforts into an ad hoc database that addressed their intrinsic goals. As a result, the organisation did not realise the benefits it set out to achieve.

IT Change Lesson 2:

Support Creative Problem Solving

Slow response, unclear terminology, and functional gaps – these are common constraints that introduce resistance to new technology. And why not? We all have limited time to learn new things while trying to get our jobs done. When technology feels constraining, rather than empowering, people tend to search for alternatives. And before you know it, you’ve got spreadsheets and off-system processing where you wanted automation.

To ensure that technology gets used as intended, the users must see it as helping them to reach their goals. To win them over, you need to respond quickly to their questions and encourage creativity and problem solving. Also, don’t forget that no technology exists in isolation. Make sure to consider how the new technology will fit with the other tools people are being asked to use.

The case of the ad hoc database…

When the users at iWork started using the newly deployed system, the first thing they noticed was the confusing screens. It took a long time to move between screens and the data they needed was scattered in multiple places. They tried to report their issues to the implementation team, but that team was faced with so many issues, they only had time to work on severity 1 and 2 items. The users concluded that this was not a system they could use. So, they built a separate database instead.
“For ERP implementations to be successful…end users must be recruited for creative change. This requires organisations to create environments where appropriate risks are rewarded and ideas are pulled from the bottom up.”*

The solution? With a little more planning, the implementation team could have co-located subject matter experts alongside the users to provide shortcuts and tools on the spot. They could have developed skills in brainstorming and idea generation. The project team would then have better understood the needs of the users and the users would have gotten learned from the experts – finding new ways to use the system.

IT Change Lesson 3:

Don’t celebrate too earlyIt's over

It is often at the point of ‘go-live’ where IT change actually fails. The project team is tired (and often over budget). They start to plan the celebration party and think about their next project or much-needed holiday. But, don’t celebrate just yet. The users are only just starting to use the software, and they need a lot of support in order to stick with the change.

Users often complain that they can’t get their questions answered or issues resolved. When this happens, they turn to older/more familiar ways of getting the job done.

Building knowledge and skills starts with good training, supported by procedure and process documentation. But, those tools must also be reinforced with support. Make sure you have allowed enough time in both the schedule and the budget to support and build skills for change after the system is live.

This includes quick turnaround on questions and problems, easy access to subject matter experts who can build technical skills, but also lots of communication:

  • Remind people of the vision
  • Keep people in a solution frame of mind and keep a look out for blame.
  • Make sure people are spending their energies on empowerment and problem solving.
  • Allow communication to include tension…this will improve the quality of the communication and the quality of the result.

The case of the ad hoc database…

When the users at iWork found problems with their new system, they turned back to the project team for assistance. But, there was not commitment to support them through the change. One user reported…

“There were still problems with the system and the support team had been through several business analysts. We would point out the problems, but there were just some things that never got resolved. It all became quite murky, so my team decided to create our own database instead – one that we could control.”

Visit the contact page to request a copy of this white paper

*Siau, K., & Messersmith, J. (2003). Analyzing ERP implementation at a public university using the innovation strategy model. International Journal of Human–Computer Interaction, 16, 57–80.

*Orlikowski, W. J. (2000). Using Technology and Constituting Structures: A Practice Lens for Studying Technology in Organizations. Organization. Science 11(4) 404- 428.

**Locke, E.A. (1996). Motivation through conscious goal setting. Applied & Preventative Psychology, 5(2),