Translate Request has too much data
Parameter name: request
Translate Request has too much data
Parameter name: request
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?
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. 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?"
Consider the relationship between user behavior and return on investment (ROI). When do we actually realize ROI from our technology projects? Is it when the technology is delivered? Sadly, no. We only realize our ROI when the people actually use the technology. If a system is delivered, 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, the critical path 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 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.
The impact to the organization and to the customers 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 make reliable, informed decisions. Executives and sales reps were unable to review vital customer activity data to prepare for additional sales meetings. The customers experience was degraded by delays resulting from having to repeat conversations that were not properly logged in the system.
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?
This reveals several important questions. Who actually owns ROI? Who is responsible for ensuring we actually 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 critical path, achieving effective system use that delivers ROI.
How do we Change User Behavior?
So, how do we do we change user behavior?
First, we realize people are unpredictable. Unlike process flows or lines of code (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 a very clear 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 operate in the context of a larger organizational system. We need to understand the impact organizational forces have on individual and group behavior, and then align these forces to drive desired behavior. Can we realistically expect people to behave in one way (like, use our system as designed) if there are major organizational forces that drive them to behave in another way?
Who Can Help?
This may all sound exhausting and impossible but there are people who can help: Human Resource (HR) and Organization Development (OD) professionals.
These two groups have complimentary skill sets that are perfect for helping us align organizational forces and drive desired user behavior. HR professionals have the skills necessary to put together appropriate performance evaluation, feedback and development plans. OD professionals are trained in conducting holistic organizational analysis and in designing 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 that required to change user behavior.
To align "people" with process 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. But, 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 test, 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 if we 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, in order to triangulate and identify the major forces driving user behavior. Once this is done and our diagnosis complete, we put together a treatment plan, that is, 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 at 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 levels of the organization, conducts 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 reviewing the data, diagnosing the situation, and developing an intervention strategy. Finally, interventions are held prior to 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 are investing our efforts in conducting appropriate interventions and in addressing the "right" issues. The time and effort required to drive desired user behavior delivers significant value through improved system use, faster realization of ROI and an improved customer experience.
Final Thoughts
The next time you are planning 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 effectively address the "people" issues?
Is there anything you COULD and SHOULD be doing to align people, process and technology?
Comments :
Post a Comment