Buzzwords are great. They give us an excuse to nod our heads, act like we are paying attention, and then completely ignore issues without giving them a second thought. As long as we use buzzwords we appear (if only to ourselves) to know what’s going on and we are on top of the challenge at hand. Perhaps the greatest part of working in technology is that we are never at a loss for buzzwords, or for meetings in which to use them.
Three of the greatest buzzwords in the tech arena are “People, Process, and Technology”. Throw in a few other favorites, such as “alignment,” “change,” “culture,” and… well, you get the idea. While these words are more ubiquitous in a technology discussion than fish are in the sea, they are often overlooked, misunderstood, and generally ignored. This is dangerous.
Looking over the landscape of a typical IT implementation we notice that the majority of activities are focused on process and technology. We spend tremendous amounts of time and effort defining business processes and specifying functional system requirements. We focus a large amount of time building and testing the technology. Consequently most of the people involved in IT projects are specialists in strategy, process, and technology.
So what is missing? Look closely. Did you notice the vast majority of our activities, and the majority of our team’s skills, are focused on aligning process and technology? What happened to our first buzzword, “People“? Do we just nod our heads and forget to consider our people – how we can move them (that is, align them) with the process and technology? What does it mean to align people with process and technology?
For some, aligning people means providing training so employees know how to use the system. Others say you need to include communications to align their people. Some advanced organizations even extend their efforts to include mapping out changes to job descriptions and responsibilities.
Alignment only occurs when your people, process and technology all perform together in a symbiotic relationship that delivers the desired results. The people use the technology. The people follow the process. They key here is that the people must actually use the technology and the people must actually follow the process. This requires people, ALL of the people, change their behavior to achieve the desired results.
Focus on Behavior Change to Improve ROI
“Did he just say our technology project needs to focus on changing people’s behavior? I thought we were implementing technology, not disciplining children or providing group therapy. What is all this behavior talk anyway?”
Sounds pretty straightforward, right? Wrong. This simple idea has tremendous implications that require advanced thought. It means we need to rethink how we structure technology projects, who we involve in the process, and how we define success. Looking back over the landscape of a typical IT implementation we notice activities focusing on behavior change are conspicuously missing. Worse still, people with skills and expertise in behavior change are typically not even part of the implementation team. This is the problem.
Example: User Behaviors’ Impact on ROI and on the Customer Experience
I worked with a client who did very little to drive desired behavior when implementing a new CRM system. As expected, they had numerous behavior problems that reduced their ROI and degraded the customer experience. Sales reps did not see “what’s in it for me”, so they would often not use the system at all or they would only enter partial, inaccurate customer data. Customer service reps would not reliably create problem tickets, nor would they regularly update their progress on resolving customer issues. Managers would not use the system to track progress or to analyze department performance.
It was only after the client had experienced these problems for quite some time that management decided to address user behavior. After users changed and demonstrated desired behavior, the system delivered significant value and the customer experienced improved. Had management proactively focused on driving desired behavior earlier they would have avoided the period of poor performance and significantly increased their overall ROI from the start.
Defining Project “Success”
How is “success” typically defined for a technology project? Projects are often judged successful if they are delivered on time and on budget. While delivering on time and on budget are indeed causes for celebration, do they fully define success? How often do we actually go back and measure our results, our realized ROI, against the forecasted return defined in the business case that justified the project? If we deliver on time but never achieve the forecasted ROI are we really successful?