The key to IT project success is to use pilots, prototypes and early user engagement, writes Niel Nickolaisen, CTO.

Chief Behavior Modification Officer

Guest blog by Niel Nickolaisen, CTO of OC Tanner, and co-author of the book, The Agile Culture: Leading Through Trust and Ownership.

Niel Nickolaisen, CIO, OC TannerMy current title is CTO. In previous jobs, it has been CIO. But years ago, as I reflected on the many technology implementations I had led, I realized that the key to success was for me to think like a CBMO, or Chief Behavior Modification Officer. It's quite logical, after all. It is rare today that a new technology solution does not alter how people do their work, interact with others and transact business.

The unoffical role of CBMO can be very challenging, usually more difficult than dealing with the technology. Perhaps you have heard this quote: “Technology would be easy if there were no humans involved.”

As I came to appreciate the important role that behavior modification plays in the success of IT projects, I set out to learn all that I could about it. I studied the literature, engaged experts and collaborated with my peers to improve my CBMO skills. Then I distilled my newfound knowledge down to a rule set that has served me extremely well. 

Here, now, are my rules for behavior modification. Are you ready?

Rule #1: People prefer the familiar to the comfortable.

Rule #2: People prefer the comfortable to the better.

Do you feel enlightened and inspired? Do you now know what to do?

Perhaps I need to explain a bit more...

Rule #1 means that when it comes to human behavior, we tend to favor what we are doing today – even if it is uncomfortable – over doing something different, even if a small change will make things easier. Given a choice, it is hard to dislodge us from where we are.

 
"As CIOs we should recognize the inherent challenge of moving anyone from familiar to comfortable, and from comfortable to better."
 

For Rule #2, the situation becomes even more challenging. If we are comfortable where we are, it can be very difficult for us to transition to something that is clearly better – in spite of the fact that we know, logically, that the future state is an improvement.

The CIO Behavior Modification Challenge

These rules apply to most of what we do in our roles as CBMO. We are trying, at a minimum, to take away some pain by implementing technology that will get our human customers to “comfortable.” Or, we might be trying to get them to “better.” No matter what the goal, as CIOs we should recognize the inherent challenge of moving anyone from familiar to comfortable, and from comfortable to better.

How do we make the better both familiar and comfortable? Through early customer engagement, pilots, prototypes and demonstrations. When I plan and launch a project, I anticipate what behaviors we will affect and develop specific project pilots designed to make any and all changes familiar and comfortable.

As an example, let me share with you a tale of two projects, Project A and Project B. Both projects were deployments of a new CRM system at companies with about 2,000 users.

A Tale of Two CRM Implementations

For Project A, the IT leader used a traditional approach. He spent a lot of time in meetings to gather requirements and business rules. He launched teams that configured and engineered a CRM system that matched the requirements he had gathered. He then engaged his users in a large number of conference room pilots that exposed users – for the first time – to the new CRM system and trained them on it. Upon launch, he watched as the new system brought the company to its knees. Employees sat idle. Customers sat on hold. His team worked without rest to solve the issues. Users did not like how the system operated and so they refused to use it. The IT leader complained about the users but that did not change the results. The IT leader polished his resume.

In project B, the IT leader took a different approach – one that recognized the power of making the new CRM system both familiar and comfortable. He identified a horizontal slice of the user base for the new CRM system –30 people from customer service, sales, and support to be part of a pilot group. His implementation team worked directly with this cross-functional team for three months. The IT team sat with the pilot group at the beginning of the day to get feedback, then did whatever work they could complete in a day – yes, in just one day. Towards the end of the day, the IT team showed whatever was ready to the pilot group, who played with the new functionality. This process was repeated daily for around three months. Because the user team got to see and use the new CRM system as it was being built, they were very familiar and comfortable with the new system. When the pilot group declared that the new CRM system was sound, the project expanded to include a total of 90 CRM users. The 30 users from the first pilot group evangelized the new system and trained their 60 peers on its use. There were now 90 users who were familiar and comfortable with the new system. The pilot then expanded to several hundred users and then to the entire company. Along the way, the IT leader gave monthly project updates to the entire company in the form of “demo days.” This helped the nearly 2,000 CRM users not in the pilot to become familiar (and then comfortable) with the look, feel and operation of the new system. The IT leader held “open houses” where anyone could come by and play with the new system.

On the day that the entire company went live on the new CRM system, the implementation team was ready to be bombarded with support calls and issues. They had staffed up for the typical “go-live” panic. However, the go-live was a non-event. There were a couple of calls about system access and permissions but that was all.

Why had this project gone so smoothly? The project was done in a way that focused on making the new system familiar and comfortable to everyone.

This “pilot-centric” approach to technology has worked so well for me that it is now the only approach I take. I use this approach on everything I do – not only software but also infrastructure and cloud projects.

Subscribe to The Heller Report

Roles We Recruit


 

Read our weekly e-newsletter packed with career advice and resources for the strategic technology leader, and information about active searches.

The Heller Report

Add a Comment

Ask These Revealing Leadership Questions When Recruiting Digital Trailblazers

Mar 27, 2024

Mark Sander of Azurity Pharmaceuticals on Leading in Times of Dynamic Growth and Change

Mar 27, 2024