19 December 2014

Software Implementation – Why Users Are the Key and the Steps to Success

Download PDF

The purchase of new software often brings with it a range of emotions. Excitement about great new features. Promise that the software will increase efficiency, saving time and money.

And, relief that a final consensus has been reached. So, with all of the excitement, promise, and hope pinned on the new product, why is it that software implementations are more likely to be unsuccessful than successful?[1]

Read on to discover the true reasons that determine success vs. failure, and use them to prevent your next software purchase from ending up as “shelfware.”

Common Reasons Software Implementations Fail

First, let’s define what we mean by a failed software implementation. Failure comes in many forms, from a product never being used to it not being used to its full potential – and a whole range of in-betweens. Some of the most common reasons include:

  • Software did not deliver the expected features and functionality;
  • Implementation took longer than anticipated;
  • Setup was inadequate;
  • Total cost exceeded budget;
  • Application was difficult to use; and
  • Users received only basic training and never learned to use the product to accomplish the company’s real long-term objectives.

You can probably relate to the frustration created by these situations. Although each one is a legitimate reason for failure, the number one reason software implementations fail is often overlooked: Lack of user buy-in!

Starting at the End (User)

Despite a new product’s potential for boosting productivity and efficiency, it’s often the system’s end users who determine success or failure. Just look at it from their perspective: They are abandoning what they know and jumping head-first into a new world. Feelings of discomfort, fear of change, and a perceived loss of control are all natural reactions.

It doesn’t help that users are often considered last. Decisions are made to purchase new software without any input from the people who will ultimately use it. Sometimes they are not even told until after the software has been purchased! Obviously this can start the implementation process off on the wrong foot and make users defensive and resistant.

Instead, communicate the need for a change in concrete terms that relate to the user, as in: “We need a tool to help us streamline your data entry while providing more detailed reports to the PMs.” When you start with a defined goal and reason for the change, you can then work backward to achieve user buy-in.

Letting users know what’s about to take place and what to expect during the transition helps everyone prepare for a successful implementation. Without user buy-in, you might as well shelve the new product on day one and save yourself the aggravation.

Following are best practices for software implementation that involve end users from the very beginning to ensure they are on board before your company spends its first dime on new software.

Involve Users Early: Start with Software Selection

Involve users every step of the way, starting with product selection. Remember that users are being asked to learn what they may perceive to be complicated new software routines, in addition to their lengthy list of daily tasks. They may also be assigned new responsibilities that go along with the new software, which can create further apprehension.

Eliminate Fear of Change

Surveys have shown that more than half of all workers resist change and that “technophobia” is pervasive – even in the year 2010. According to adult learning theory, adults need to know why they should learn.[2] Adults commit to learning when they consider the goals and objectives to be realistic and important. A person who understands how a new technology will benefit the company overall, as well as how it relates to his or her day-to-day activities, will be less resistant to change.

For example, if you’re looking for a product to handle job cost reporting (which your company has never done before), your users will need to understand job costing structures and the accounting principles behind them before they can learn how to use the software for this function. Explaining these points and offering any additional training or support will aid in the transition.

According to a leading implementation services consultant: “Natural resistance to change is minimized when people feel part of the process.”[3] Including users in the selection of the software and later in the implementation planning will alleviate tension and fears.

Solicit User Input

Besides explaining the need for change, you should also actively solicit input from the people who will be using the new product. Find out what their current processes are and what could make their jobs easier. A software purchase made “in the dark” can lead to the discovery that the application does not offer what users really need to perform their duties.

Getting user input on which product to purchase ensures business needs are being met and gives the added benefit of reduced user resistance or sabotage. Buy-in happens naturally when people feel that their opinions have been taken into consideration.

Don’t Skimp on Due Diligence

You’ve narrowed down the contenders, and now it’s time to perform due diligence. Schedule demonstrations, talk to customers who are using the application, and consult industry experts. After all, you’re looking for the “best fit” product for your company and its users. Also, inquire about ongoing support and training. Be sure to check with references, including their experiences with the vendor in three key areas: company, product, and technology.

Company
Realize that an investment in a new software package involves a long-term relationship with the software vendor. Be careful not to underestimate the importance of this relationship. Before and after implementation, you will want to ask:

  • How long has the company been in business?
  • Has the company been sold or otherwise changed hands recently?
  • How many clients does the company have? Are you comfortable with that number?
  • How long have employees been there?
  • How long did the implementation take compared to how long the vendor said it would take?
  • Were your expectations met? Or, were you blindsided by the amount of time the implementation took?
  • Did the process go the way the salesperson and the trainer told you it would?
  • What was the response time in support? How long did it take to get an answer?
  • Was there consistency throughout the process from the salesperson to the trainer?
  • What didn’t you like about the process? Specifically, what would you change if you could?
  • Is the vendor the author/developer of the product or a value-added reseller (VAR)?

Product
The questions here will vary greatly depending on the type of software package your company is purchasing, but be sure to look for:

  • Powerful reporting and user-friendly report writers;
  • Flexibility in setup and day-to-day use; and
  • Intuitive and user-friendly interfaces.

Technology
Often overlooked, this area can have a huge impact on product performance, data security, and integration with other tools. Be sure to ask (or have your IT consultant ask) such questions as:

  • Is the vendor current with technology?
  • Are its back-end databases current?
  • Will your company’s data integrate easily with other products without requiring additional software or hardware?
  • Does the application run when Microsoft comes out with new platforms? Or, does it take months for it to catch up?

Understanding True Costs

Of course, cost is always a primary concern with any system purchase. But, be careful to compare not only measurable costs, but non-measurable costs as well, as shown in the chart below.

As you can see, many of the non-measurable costs relate to time, and this is exactly where many implementations go offtrack. A good rule of thumb: Estimate the time needed for each task – and then double it!

Implementation

The software implementation process should include three phases: planning, training, and wrap-up.

Planning
First comes the planning meeting – an absolutely critical step in your implementation process. Lack of formal planning is one of the most common reasons expectations are not met from a new system.[4] A thoughtful, step-by-step approach makes everyone’s job easier along the way.

Purpose
At this meeting (which can last anywhere from two hours to two days), you will sit down with a trainer to discuss your company’s specific needs, training and system expectations, and user responsibilities.

Ensure that everyone who will use or have involvement with the new software is present – from data entry staff to PMs to upper management.

This is a crucial time to discuss individual needs and wants. For instance, if a PM wants specific reports, now is the time to speak up. As one implementation specialist noted: “If users and their ‘wish lists’ are not sufficiently represented, they can end up revolting against the system.”[5] The ultimate goal of this meeting is to outline and agree on a structured training plan.

Be Prepared
To make this meeting as productive as possible, come prepared. Your trainer needs to know your key business requirements, as well as your key “pain points.” And, don’t forget to discuss the core functionality you currently have that you want to keep (i.e., what works).

Your goal should be to document 80% of your key business scenarios.[6] Be ready to discuss the system you want to replace and your reasons for wanting to change.

Defining Goals
During the planning process, you will find yourself starting at the end and working backward. Once your trainer understands the desired output (e.g., additional reports, improved efficiencies), he or she will know how to set the stage to make it happen.

Taking time at this stage to define the scope and detail the expected results will save time and money down the road. Some important goals of the planning meeting should be to:

  • Reinforce the time required to get up and running on the new system. (This should already have been discussed in the software selection process.)
  • Define roles and responsibilities for each stakeholder.
  • Establish the scope, goals, and objectives of the implementation. (These will later serve as benchmarks against which you will measure its success.)
  • Discuss current processes and workflows, and any changes/improvements that need to be made.
  • Schedule the implementation phases and define milestones.
  • Reaffirm user buy-in by emphasizing the benefits of the new system.

Implementation Timetable
Set a realistic timetable for the implementation and clearly communicate it to everyone. Most people greatly underestimate the time needed to get a new system up and running.

This process cannot and should not be rushed. During this time, users will need to carefully plan their duties and may need to put off some nonessential tasks so they can focus on setting up and training on the new system. Training will require users to be available onsite or online for a minimum of 2-3 hours at a time.

In addition, “homework” will need to be done between training sessions. If these tasks are not completed, the company’s “go live” date will likely be affected. Management needs to work with users to structure their workdays during this period.

Users are often surprised and frustrated after spending many hours on training that is accomplishing what they view as nothing more than setup. Making all of this known upfront will reduce their frustration level and increase cooperation between users and their trainer.

In order to grasp the timing, you should ask your trainer the following questions during your planning meeting:

  1. How much time should we allot for training?
  2. How can we expect the training to go (i.e., what is the procedure)?
  3. When can we start to see the results of why we purchased the software?

Communication
Once you’ve held the planning meeting, commit to providing regular updates to all stakeholders. It’s the surest way to keep your people – and your implementation – on track.

Training

Training is the implementation component with the highest payback. Well-trained users will use the software more effectively, be happier, make fewer errors, improve efficiencies, and enhance the likelihood that the company will meets its business objectives for your project.

The good news is that if you’ve done your due diligence in selecting a product and thoroughly planning the implementation – with your users involved every step of the way – then you will likely be pleasantly surprised by how smoothly the “training phase” unfolds.

Setting the Stage for Training
Unfortunately, the training phase is where the majority of companies begin. Users rarely learn about the product or what to expect until they first meet with their trainer. Essentially, they are going in “cold.” Compare this to users who have been involved from the very beginning using the methodology discussed in this article. Who do you think will be more successful?

Context
Learning a new and more robust application can be intimidating. So, the trainer should help all users understand the application, processes, and procedures within the context of your company’s business goals. Key benefits to the new system should be emphasized to create a positive learning environment and to generate excitement about the change.

For example, if users will be able to accomplish more in less time or with fewer key strokes, if spreadsheets or other external applications will no longer be used, or if processing time will be faster, then all of these benefits should be demonstrated and highlighted during training.

According to a best-selling author of practical leadership development books: “Trainees should immediately see the connection between their new skills and where the organization is going. This makes training more relevant – and gets everyone focused on applying their new skills to the organization’s key priorities and goals.”[7]

Training Phases
Training is not just about showing people how to use the system. Instead, there are phases of training that should occur at different points during the implementation:

  1. Conference room pilot or “hand-off” session. This is a high-level overview to demonstrate the system’s design and functionality to its users.
  2. Individual hands-on user training. During this phase,users learn how to set up and navigate the software and perform their daily tasks. Focus should be placed on individual tasks and learning the system’s workflow so that each user understands how his or her actions affect other areas.[8]

The trainer should also work closely with each user to perform his or her required setup (e.g., reports, customized default settings, and user defined fields) using a test company that contains your company’s actual data.

That way, users can practice performing their daily tasks – testing data flow, running reports, and troubleshooting – with data that is familiar and meaningful to them.

  1. Post go-live retraining (2-3 weeks after going live).Users typically have the most questions at this stage.[9] As part of the wrap-up process described on page 18, the trainer should determine the areas where users may still be struggling and offer the appropriate guidance.
  2. Ongoing training. To leverage your initial implementation training and to take full advantage of the new technology, most software vendors offer workshops, consulting, and user conferences. Consider all options offered by the trainer/vendor to ensure you get the maximum return on your company’s technology investment. Now may also be the time to purchase additional modules to help streamline your processes even further.

Wrap-Up

The wrap-up and follow-up session with the trainer should not be an afterthought. During this session, the trainer should sit down with each individual involved in the implementation in order to revisit all items covered in the planning meeting and determine if all expectations have been met.

The trainer should ask each person to evaluate the sufficiency of training received, how the system meets his or her needs, and how it addresses each of the predefined objectives established in the planning meeting.

While doing this, the trainer should refer back to that meeting’s notes to determine if your company is getting what it wanted from the system. For example, if you bought the system because you were looking for a specific type of report, are you getting it now?

Conclusion

Undertaking any new technology initiative is a huge challenge – one that requires time and effort. Implementations can fail for a variety of reasons, including cost, time, or poor product usability. But more often than not, these occurrences are merely a byproduct of a greater problem. Users are the real key to an implementation’s success or failure.

The best ways to get users to embrace new technologies are to include them in the decision-making process from the start and to set clear expectations of what will be involved. In summary, they need to understand:

  • The reasons for the change;
  • What to expect during the implementation; and
  • That it will take time to reap the rewards of the change.

Managing the natural resistance to change and helping users accept new technology must be a planned process. The model for success involves users in all steps of the implementation, from software selection to planning, training, and wrap-up. Thorough planning with user buy-in upfront and throughout the implementation process is your surest route to a successful implementation.

 

End Notes:
1. “Failure Rate: Statistics over IT projects failure rate.” www.it-cortex.com/ Stat_Failure_Rate.htm.
2. Gentry, Sarah. “Learning in Adulthood – Knowles’ Theory of Andragogy.” www.buzzle.com/articles/learning-in-adulthood-knowles-theory-ofandragogy.html.
3. True, Lawrence C. and Koenig, Kurt M. “Software Implementation Best Practices.” CFMA Building Profits, July/August 2009.
4. Binbasioglu, Dr. Meral and Winston, Dr. Elaine. “Are You Solving the Right Problem? A Study of Packaged Software Implementation.” International Association for Computer Information Systems, 2002. www.iacis.org/iis/ 2002_iis/PDF%20Files/BinbasiogluWinston.pdf.
5. Bhuta, Vyom. “Eight Mantras to a Successful Software Implementation.” April 30, 2001. www.gantthead.com/articles/articlesPrint.cfm?ID=18833.
6. Walia, Sandeep. “Top 5 Recommendations to Ensure Your ERP Implementation is Successful.” October 27, 2009. www.erpsoftwareblog.com/2009/10/top-5-recommendations-to-ensure-your-erp-implementation-is-successful/.
7. Clemmer, Jim. “Why Most Training Fails.” March 25, 2010. www.connectitnews.com/usa/story.cfm?item=4208.
8. Bhatti, T. R. Critical Success Factors for the Implementation of Enterprise Resource Planning (ERP): Empirical Validation. Speech presented at The Second International Conference on Innovation in Information Technology (IIT September 26-28, 2005), Dubai, UAE. www.it-innovations.ae/iit005/proceedings/articles/F_4_IIT05_Bhatti.pdf.
9. Walia, Sandeep. “Top 5 Recommendations to Ensure Your ERP Implementation is Successful.”

*A version of this white paper originally appeared in the Journal of Construction Accounting & Taxation July/August (2010) Thomson Reuters/RIA.

1233