Return on Relationships
OBSERVATION
It is a common trap on many IT projects that team members are so focused on ensuring project “success” (typically defined as on-time and on-budget delivery) that team members forget the critical importance of developing and maintaining effective relationships. Ironically, forgoing the relationship building elements of the project (e.g. developing trust, ensuring effective project team interaction, etc.) often causes project delays, disagreements, and quality problems which ultimately lead to the project running late, over budget, or otherwise being deemed a failure.When project teams skip the critical step of building effective relationships:
- Project timelines are increased due to extensive time being wasted resolving disagreements, such as different views on scope of work, bugs vs. enhancements and performance measurements
- Stakeholders are unwilling to divulge important information with consultants and/or internal project team members, leading to ineffective solutions being developed and implemented
- Problems slowly escalate and disagreements become more intense as the project go-live date nears.
CONSIDER THIS
Investing time and energy to develop effective, trusting relationships with team members, clients, partners and others will deliver benefits that far exceed the costs. This is realized through proactive collaboration and teamwork, streamlined problem resolution, improved customer satisfaction, increased referrals and references, and maintaining long-term, profitable relationships (a positive Return on Relationships). Project team members should view time spent relationship building as an investment that will deliver future benefits. The perceived benefits of skipping or short-changing relationship building efforts are much lower than the very real costs when the project encounters the inevitable stress and disagreements that emerge (a negative Return on Relationships).THINGS TO THINK ABOUT
- Do you typically have a positive or negative Return on Relationships? What could you do to ensure you have a positive Return on Relationships? What additional benefits would you get from spending more time developing positive relationships with each stakeholder? What problems could be avoided by doing so?
- Do your project team members know how to develop effective relationships? Can they repair damaged relationships? Are they comfortable working with clients? Other departments? Senior executives? Many times project team members are great subject matter experts in their field, but they do not know how to develop and maintain effective professional relationships. Team members – even senior members – may need help learning to develop productive professional relationships.
- What can you do to build trust with each stakeholder? Trust is the ultimate tool for relationships. This tool can neither be granted nor created during a single meeting; it is built slowly and steadily over time through repeated interactions. What can you do to ensure that once it is earned, you maintain the trust of others?
RELATED RESOURCES
Check out these other resources for more information related to this topic:- Take the Tri Tuns User Adoption Challenge - a free online assessment tool
- Read: “Leadership: Are You Really Committed?”
- Read: “Does Your User Adoption Methodology Remove Barriers To Adoption?”
- Read: “Motivating User Adoption: Commitment, Compliance or WIIFM?”
- Read: “The Myth Of User Resistance”
WHAT’S WRONG WITH WIIFM?
OBSERVATION
For years many pundits have said that the best way to motivate user adoption is to “sell” people on what they get for using the new system. They argue that you need to constantly tell each person, “What’s In It For Me” (WIIFM). So, after many years of organizations beating the WIIFM drum, we find that most IT systems still suffer from low or ineffective user adoption. Is it time to re-think WIIFM? I strongly suspect that the people who first came up with WIIFM were management consultants, not psychologists.Back in the 1960’s Yale psychologist Victor Vroom[1] developed the Expectancy Theory[2] that basically states that employees will be motivated to take action if:
- There is a positive correlation between efforts and performance
- Favorable performance will result in a desirable reward
- The reward will satisfy an important need
- The desire to satisfy the need is strong enough to make the effort worthwhile
- The reward for adopting the system needs to be meaningful and desirable to each individual employee. Many IT projects do not actually take the time to learn what is a meaningful to the individual and just issue a one-size-fits-all WIIFM message.
- The rewards that we desire change over time and vary from person to person. For example, what motivates a young employee is be very different from what motivates an older employee who is close to retirement.
- Organizations with a poor track record implementing systems, often lack credibility. Quite simply, employees don’t believe the system will deliver the anticipated benefits or that they will benefit from using the system.
- WIIFM messages often push the benefits of adopting new systems, while ignoring the costs/effort involved. Many times it just “isn’t worth it” to the employees to go through the pain of adopting the new technology.
CONSIDER THIS
Instead of trying to sell employees on WIIFM, help them focus on the need to shift their behavior. The psychological theory of Cognitive Dissonance[3] shows us that when people hold conflicting views on a subject they are motivated to change (or justify) their attitudes, beliefs, or behavior. For us, this means we need to help people realize that the business needs, environment, performance requirements, and management expectations have changed and that the behaviors that made them successful before need to shift.THINGS TO THINK ABOUT
- How can you set the expectation that it is no longer business as usual and that employees need to change their behavior in order to succeed in the future?
- Have you explicitly stated what has changed and what are the new expectations for employee performance? For example, have you developed communications that state things like:
- Changes in the economy require that we become more competitive by doing X
- New government regulations require we do X,Y, and Z
- In order to be eco-friendly and good corporate citizens we need everyone to do A, B and C
- How can you shift from primarily 1-way, passive communications, to better engage employees in 2-way discussions? Do you engage employees in dialogue and ask them questions so that they are forced to think about what has changed and how they need to adjust their behavior to be successful in the new reality?
- Have you explicitly stated that how you perform your job is just as important as how well you perform? Do you communicate that it is no longer sufficient to be a great individual performer if the way you utilize systems and processes prevents others from excelling in their jobs?
[1] http://mba.yale.edu/faculty/profiles/vroom.shtml [2] http://www.valuebasedmanagement.net/methods_vroom_expectancy_theory.html [3] http://changingminds.org/explanations/theories/cognitive_dissonance.htm
THE MYTH OF USER RESISTANCE
OBSERVATION
Many people blame “user resistance” as the reason why their systems are not adopted. The prevailing attitude seems to be that if we provide adequate training and communication (often the extent of the “Change Management” effort), then it must be the users fault if the system is not used. I like to call this the “Train, then blame” approach to User Adoption. There is an implicit assumption that user choice is the sole factor affecting user adoption. However, when we look closer, we see that this is often not the case.There may be many other reasons why your people might not be using your system, and in many cases it is not their users fault at all. For example:
- Many times there are organizational barriers outside the users control that prevent them from adopting the system
- Design disconnects between the technology, process and users prevent users from adopting the system
- Conflicting priorities, misaligned reward systems, and the directives of immediate supervisors result in a situation of, “hoping for A, while rewarding B”
- The Change Management and IT implementation methodology were inappropriate for driving user adoption
- No action was taken after go-live to create and sustain full user adoption
CONSIDER THIS
Blaming poor user adoption on “User Resistance” may be convenient and it may shift the onus for taking action from you to the users, but it may not be accurate. There may be other factors causing your adoption problems and the responsibility for taking action may fall on YOU, not the users!THINGS TO THINK ABOUT
- What factors outside of the users’ control would prevent them from adopting the system?
- Have you adjusted reward & recognition criteria to reward people for adopting the system and penalize them for avoiding the system?
- What are the reasons (other than the technology itself) that people did not adopt earlier systems? What did you do to address these issues?
- Did you take appropriate action before, during, and after go-live to address user behavior and drive user adoption? How can you move beyond traditional “Change Management” efforts to drive desired user behavior over the long term?