Steps in Creating Buy-In for New Software and Technologies

In my last three posts, here (1st) and here (2nd), I’ve discussed the issues surround creating buy-in to new software and technology projects. Basically what that means is that you can spend a whole lot of money on the coolest piece of software for your company, but have used it better making a nice campfire if no-one uses it. Over the years, I’ve come up with some key points in helping to actually get this done, so rather than bather on about the problems and costs, I’ll share some of these points with you now. These are things that you as a project manager, or even better, a senior manager, should be thinking about and probably should be doing!

1. Make technology/software choices with a view to effective buy-in.

  • Work with shareholders in the company while choosing technology to identify the goals to ensure that users, needs and technology are aligned – e.g. do Boomer managers need and want PDAs or does a Millennial IT manager think they do?
  • Guide the organization on complexity design decisions before purchase: e.g. do they want or need minimal buy-in software (easy to learn, easy to use, and easy to re-learn next month) for tasks that are only done occasionally?
  • Assess software or tech options for ease of adoption, and recommend the most suitable choice on the basis of company culture and experience.
  • Assess other factors in user adoption: training materials, manuals, help files for user-friendliness; review issues such as the software/tech provider’s training and after-training service and back-up history, accessibility and reputation for service.
  • Assess the REAL cost of training to adoption.

2. Guide the pilot project, ensuring that the right people are involved, and the right data is obtained.

3. Define the training objectives and user goals effectively

  • Communicate training objectives and goals clearly and in a timely manner to users.
  • Determine what the users know before training, vs. what they need to know. (How big the gap is in total skill-sets)
  • Determine the minimum degree of functionality each user group should reach, sustainably, to achieve the desired business objectives.
  • Determine whether it is possible to create levels of functionality, so that certain users can achieve adequate functionality, while other functionalities can be trained later, according to confidence, need and interest.
  • Assess/monitor at what point a blanket demand for full functionality can lead to a significant percentage of any user group feeling “overwhelmed with feeling overwhelmed”
  • Create ways to show options to learners, so that they can choose their level of functionality before or during training.

These tasks may be determined during the pilot project phase.

4. Identify sources of concern: road blocks, resistance, “out of comfort zone”, anxiety, problems with degree of management buy-in to the system, degree of senior management support, concerns with training methods etc. Work through any issues.

Any engagement requires (amongst other things)

  • involving people,
  • listening to them
  • demonstrating that their opinions count (and are seen to count)
  • making sure that people feel successful
  • communicating, so people always know what they are doing, why and what is expected
  • giving them feedback
  • communicating in terms that people understand, and at a conceptual level which matches their phase of understanding.

5. Assess or monitor training, to ensure that it reaches a tipping point where the goal percentages of users reach and maintain the defined adoption standard.

  • Ensure that training accords with the laws of adult learning.
  • Ensure that training accords with the users’ needs and styles of learning
  • Ensure that training achieves specific goals, along clearly mapped learning paths,
  • Ensure that training includes teaching the users of the software/ technology to think of solidly useful and beneficial ways to use the new tools in their own daily work.
  • There are experts in this. Don’t think that because you are a great programmer or project manager that training people or designing retainable classes is easy.

6. Maintain use of the software /technology

  • Create a supportive framework for the implementation phase – with top-level go-to mentors (who can also act as system champions) and generally competent buddies (pairing buddies with slow adopters and resisters). The top-level mentors might be involved in the training itself.
  • Ensure that IT staff are supportive, that IT staff are working with users at their level, using vocabulary they understand and that they buy in to the mission of engaging the users with the new material or equipment. Ensure that IT department staff are provided with incentives, and rewarded for meeting the adoption and sustainability goals of the project.
  • Work with management to tie the technology to the key performance indicators of each position, in a way that the use of the technology is mandatory. Ensure that all managers use the technology or receive coaching if they themselves are slow adopters. Help managers to (a) reinforce the “what’s in it for me” factor for the users; (b) reward and give feedback on adoption and (c) apply a consistent, no-exception policy to use of the software/equipment.
  • Schedule on-going training until an agreed level of adoption is reached. Ensure that the company invest to the degree that the technology is critical to the business, in regular refresher bursts, assessments, rewards, games etc.
  • Celebrate early adopters, and ensure praise of others as they meet their goals.

7.  Measure the results of the implementation and training against the business goals

  • Assess the pilot project, and identify/report problems and solutions.
  • Survey users for frustration, comfort, opinions, problems, successes etc during implementation.
  • Measure the results of the project in terms of the use of technology/software and the achievement of the business goals it was put in place to achieve. (E.g. with project management software, one might measure the number of overruns or schedule misses since implementing the new program.)

Wow! Well I know that’s a lot, but if you have actually gone through these points you’ll at least have had the opportunity to think about your next big project in a different way.

You can read the whole series on Creating Buy-In for New Software and Technologies here: Part 1, Part 2 and Part 3

Share

Training and Project Management in Creating Buy-In for new Technology

In my last post I laid a foundation of doom and gloom as to how a good project can go very bad when people don’t actually use the cool new toys they’ve been given. Lets have a look at what is going wrong with this, and WHY it is going wrong.

Review project management:

So a central problem is that IT people omit the forecasting and contingency planning step.

They omit a specific part of forecasting and contingency planning:

The reason:

Certain people are much more likely to take human data into account when planning projects, and this tendency correlates negatively with the skills that make people successful in many IT tasks.

The tendency to view data in a way that minimizes the less logical human issues is measured by the “Thinker-Feeler” continuum of the Myers-Briggs test, and IT people are highly likely to score towards the Thinker end of the continuum. (That is most of us don’t take the people factor into planning very much.)

I have a background in I/O Psych, and believe that people are different and this just IS THE WAY IT IS, (I also believe that puffer-fish are better than regular fish, so I’m not sure how much belief should enter into these discussions.)

Reality Checks

Anyway! IT project managers who contingency plan well, look at the numbers (the probability of projects failing because of lack of buy-in – i.e. human illogical behavior) and the cost of this contingency, and work with people who can ensure that this does not happen in their own projects.

Once this reality check is passed, there is another we have to present to our clients. The work of attitude management is very high skill work.

The IT industry has experience in training that is about knowledge or skills. There is, however, another type of training that is about attitudes. This is the work of selling the choice to behave differently. Or, more succinctly… people gotta wanna, and the buy-in facilitator’s work is the work of helping them wanna.

So when it comes to training, the facilitator owns the problem of getting the end-users to choose to buy in to a new process, and to decide to commit to using it. S/he agrees what this must look like, in concrete terms, and what must be visible, on the job, within certain periods of time.

This frees the IT implementation team to achieve their IT goals without the very high risk of failure owing to factors that they do not have the time to deal with, or the inclination, or resources, or the training to use the most effective strategies. That does mean however that the two groups will have to meet, and *gasp* work together, at least a little bit!

Ok, with that all said, I think that my next post will give a few points on what steps should be considered for a large scale IT project roll out, which INCLUDES the human factor.

You can read the whole series on Creating Buy-In for New Software and Technologies here: Part 1, Part 2 and Part 3

Share

Issues in Creating Buy-in to New Software and Technology

There are few things more frustrating in business than putting in good new technology or software systems, and seeing them fail because your people will not use them.

The industry failure rate for new implementations is estimated to be greater than 50 percent, which is, quite a bit of wasted time, energy and money. This massive cost is the result of various factors, including uneven project management, unclear expectations, poor management commitment to new systems, and incomplete or ineffective training and guidance for end users.

There is one type of training that is about knowledge or skills. There is another type of training that is about attitudes. This is the work of selling the choice to behave differently. Or, more succinctly… people gotta wanna, and the trainer’s work is the work of helping them wanna.

The problem:

Software and technology implementation projects fail because end-users do not reach a critical point of buy-in.

There are few things more frustrating in business than putting in good new technology or software systems, and seeing them fail because your people will not use them.

Examples

You have calculated the value proposition of a great new system for customer relationship management, and invested in a database system guaranteed to improve sales and relationship management. But only 40% of your sales people are using the software, and the ROI is not materializing….

You’ve installed a web conferencing system solve your company communication problems, and trained your whole staff, in all of your locations, on how to use it. They hardly ever use it, and now they can’t remember how it works.

You’ve bought all your managers top-of-the-line PDAs, but only a few are using them. The rest leave them in their desk drawers and carry their cell phones.

Your new competency-based performance management software cost a fortune. However, after full training on how to use it, appraisals are not coming in, or you are getting them in everything from Excel to hardcopy. Managers say that no one ever trained them properly on the program.

The size of the problem?

The industry failure rate for new implementations is estimated to be greater than 50 percent.

The cost of the problem?

As high as the cost of 50% of new tech and software implementations.

Contributory causes:

  • uneven project management,
  • unclear expectations,
  • poor management commitment to new systems,
  • incomplete or ineffective training and guidance for end users.

The biggest cause:

Failures in forecasting and contingency planning

Well that’s it for now. This is just a look at how bad this problem is. Don’t worry, I’ve spent a fair amount of time thinking and practicing some solutions to these issues as well. My next post will look at some of the training and planning implications of these problems, and then finally, I’ll have a post talking about some of the steps to help create buy-in.

You can read the whole series on Creating Buy-In for New Software and Technologies here: Part 1, Part 2 and Part 3

Share