Buzzwords are great. They give us an excuse to Universe Inform 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 most significant part of working in technology is that we are never at a loss for buzzwords or for meetings 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 technology IT implementation, we notice that most 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 part of our time on building and testing the technology. Consequently, most of the IT projects people are specialists in strategy, process, and technology.
So what is missing? Look closely to technology. 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 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 strategy and technology?
Aligning People
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. While these are all important activities to help achieve alignment of people, process, and technology, they don’t actually help us understand what alignment is. And if you don’t know what it is, how do you know when you have achieved it?
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. The key here is that the people must actually use the technology, and the people must even follow the process. This requires people ALL of the people to change their behavior to achieve the desired results.
Focus on Behavior Change to Improve ROI technology
“Did he 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?”
RELATED ARTICLES :
- Introduction to Designing Open Source Games for the Google Smart Phones
- Seven stop-of-12 months renovation tips for Apple machines
- Denise Robbins on Merging Technology and Fiction
- The Search for Life on Mars Should Go Underground
- Update Coinbase up with intermittent suspensions
Consider the relationship between user behavior and return on investment (ROI). When do we actually realize ROI technology from our technology projects? Is it when the technology is delivered? Sadly, no. We only realize our ROI technology when the people actually use the technology. If a system is shown but not used, it does not return any value to the organization. So, while successfully deploying the technology is on the critical path (pardon the gratuitous use of the buzzword) to achieving ROI technology, the essential way is only completed when the system is used effectively by our people.
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 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 technology 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.
The impact on the organization and to the customer’s experience was severe. The organization wasted vast amounts of time and effort performing unnecessary tasks, such as tracking down information that was not entered by one individual but was required by others to perform their jobs. The lack of complete and accurate data made it impossible for management to utilize the system reports to produce reliable, informed decisions. Executives and sales reps were unable to review vital customer activity data to prepare for additional sales meetings. The customer’s experience was degraded by delays resulting from having to repeat conversations that were not properly logged into the system.
It was only after the client had experienced these problems that management decided to address user behavior for quite some time. After users changed and demonstrated desired behavior, the system delivered significant value, and the customer experienced improvement. Had management proactively focused on driving desired behavior earlier, they would have avoided the period of poor performance and significantly increased their overall ROI technology 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 budget. While having on time and the store are real 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 technology, are we really successful?
This reveals several important questions. Who actually owns ROI? Who is responsible for ensuring we even change user behavior and realize our anticipated ROI? What are the consequences for not achieving forecasted ROI? We need to stop defining success at the midpoint of the critical path (delivering technology) and shift our focus to the end of the necessary way, achieving effective system use that has ROI.
How do we Change User Behavior?
So, how do we change user behavior? First, we realize people are unpredictable. Unlike process flows or code lines (which are linear, logical, and controllable), people are wildcards. They do not always act rationally or predictably. They can be influenced and encouraged, but they cannot be controlled. Is it any wonder that even though we define an obvious logical process and system that it is not always used as intended? So, how do we compensate for the unpredictable and uncontrollable? Who can help us do this?
To address these challenges, we need to learn more about people and how to influence their behavior. Expanding our knowledge of individuals to include an understanding of personality types, communication processes, conflict styles, individual motivation, and learning styles gives us many tools for improving our ability to change behavior.
Of course, we do not work in isolation. We work in small and large groups, which have their own unique characteristics and processes. People behave differently in groups than they do alone. We need to understand more about interpersonal relationships, group dynamics, and creating and managing high performing groups. We need to understand how trust, honesty, and ethics impact group behavior and how we can use this knowledge to create an environment that drives desired behavior.
Moreover, individuals and groups do not operate in a vacuum; they work in the context of a more extensive organizational system. We need to understand the impact corporate forces have on individual and group behavior and then align them to drive the desired action. Can we realistically expect people to behave in one way (like, use our system as designed) if there are significant organizational forces that drive them to behave in another way?
Who Can Help?
This may all sound exhausting and impossible, but some people can help: Human Resource (HR) and Organization Development (OD) professionals. These two groups have complementary skill sets that are perfect for aligning organizational forces and driving desired user behavior. HR professionals have the skills necessary to put together appropriate performance evaluation, feedback, and development plans. OD professionals are trained to conduct holistic organizational analysis and design appropriate interventions to facilitate the desired change.
Do we really need OD and HR people? Can’t we use our current project team? No! IT people do not have the required skills – their expertise lies in technology. Strategy people typically are not qualified either. The knowledge and skills they possess to develop business cases, process flows, and ROI forecasts are very different from those required to change user behavior. To align “people” with function and technology, we actually need to rely on professionals with expertise in “people” issues – HR and OD experts. But how do they fit within the development lifecycle, and when do we include them in the development process?
A Better Approach to IT Projects
We often assume that if we teach people what to do, then they will act as instructed. What if the problem is not just that they don’t know how to use the system? What if they can’t or won’t use the system for other reasons? Imagine you are sick and you go to the doctor. He doesn’t just say hello, shake your hand and then give you an operation. Instead, the doctor asks you some questions, runs some tests, gets x-rays, and inspects your body. Only after he has gathered data and made an informed diagnosis does he develop treatment plans. A (somewhat) similar approach is appropriate for IT implementations.
Current efforts to promote user adoption that only include delivering training and communication are akin to the doctor skipping the data gathering and just reaching for the scalpel when you walk in the door. Wouldn’t it be better to gather some data, diagnose what drives user behavior in our organization and then put together an appropriate treatment plan? That is exactly what we should do. We begin by gathering data from multiple sources, at multiple levels in the organization, to triangulate and identify the major forces driving user behavior. Once this is done, and our diagnosis is complete, we put together a treatment plan to determine appropriate actions (called OD “interventions”) to promote user adoption. Interventions may be conducted at multiple points in time: project start-up, during development, at go-live, and multiple intervals following system deployment.
Example: Structuring a Project to Drive User Behavior
So, how will this work? At the start of the project, an OD consultant leads the project team (IT and business SMEs) in group development work and helps them mature into a highly productive work team. The consultant also helps IT and business agree on a definition of project success and a plan for sharing responsibility for measuring and achieving ROI at various points after go-live.
The consultant then gathers data to identify the organizational factors that drive user adoption. He conducts interviews across all organization levels, leads focus groups with representatives from several user departments, surveys employees, and reviews various documents such as strategic plans and job descriptions. The consultant then facilitates leaders and business representatives in checking the data, diagnosing the situation, and developing an intervention strategy. Finally, interventions are held before go-live (to prepare users for the change), during the first few weeks of the deployment (to assist users during the change), and at multiple scheduled review points (to help users continue to grow by identifying lessons learned and by sharing best practices across the organization).
Including HR and OD professionals in IT projects is critical for aligning people, process, and technology. Conducting an organizational analysis, and more importantly, involving people in the process, helps drive desired behavior. It allows us to make sure we invest our efforts in conducting appropriate interventions and addressing the “right” issues. The time and effort required to drive desired user behavior to deliver significant value through improved system use, a faster realization of ROI, and an improved customer experience.
Final Thoughts
The next time you plan an IT project, ask yourself if you are doing enough to address the “people” issues. Are you focusing on promoting user adoption and achieving ROI, or are you just focusing on delivering the technology? How much would you increase ROI if you improved user adoption of the system? Do you have skilled HR and OD people helping you drive success? Do you have the right skills and understanding of individual behavior and group development processes to address the “people” issues effectively? Is there anything you COULD and SHOULD be doing to align people, processes, and technology?
