At first, the signs of a failed software project are hard to see. But they're there. Intensity drops. Interest wanes. Each week new problems bog things down. User adoption is slow. Phased rollouts stall.
That Sinking Feeling
This article is about how to avoid failed software implementations. You're nearing the end of the project. You evaluated why you should automate manual paper or Excel-based time and expense tracking system. You did all the right things. You did your business analysis. Worked hard to develop a consensus with your team on requirements. You searched for solutions. Narrowed vendors to a shortlist. Held demo meetings. Found a solution. Made the purchase.
You'd like to feel great about your choice. But in your bones, concerns remain:
- Did you select the right solution?
- Will your employees embrace it?
- Do you have the right resources to implement it?
- What if it fails?
There are a few keys to successfully implementing new software.
Global strategy consultant Didier Bonnet noted in the Harvard Business Review three common implementation barriers.
1. Lack of Senior Manager Buy-in and Follow Through
Lack of senior manager buy-in creates organizational resistance in a few ways. The benefits of new software might not be clear to the organization. Maybe the benefits, while sounding good, did not entirely ring true for the team. Maybe you didn't have the right budget for the purchase, forcing the purchase of a lesser solution. Maybe you didn't get the dollars you needed for proper configuration of the system. Or maybe you never got resources from the business you needed to ensure requirements were met in the software setup. The new software might be part and parcel of major organizational changes. But maybe you didn't have the resources to drive the change management needed. Maybe you didn't have the necessary resources for training or ongoing administration of the system. Ongoing system monitoring, maintenance, configuration updates, and reconfigurations require competent resources in the organization with management backing. Beyond the initial deployment, if your business is growing and changing this software system will need to grow and change with it. Beyond technical considerations, a new system must be driven by business priorities and strategy. This in turn should govern how the system is selected, configured, sold into the organization, deployed, accepted, maintained and extended over time.
2. Vendors Who Oversell
Generally speaking, software and technology vendors focus more on selling software and less on implementation. As Bonnet notes, vendors can be quite talented at getting customers to fixate on exciting new features. "Bright shiny tech objects" that provide the “promise of instant change through digital technology.” In the process, business requirements gathering can be given short shrift while key senior managers are made to swoon by salespeople over non-essential features that have a lot of sizzle. Important feature gaps, identified early on but dismissed by vendors as easy to close later, might never be addressed. A balanced "buyer beware" perspective helps. You want to leverage proven technology and features, but only those that best address your business priorities and strategy.
3. Limited Budgets & Resources for Adoption and Implementation
It looks like you've done everything right so far. You've successfully identified and concretely defined your business requirements. Your initial setup of the software looks like a dream. Everyone feels good. But critical steps remain: 1) porting your business processes to the new system 2) managers need to be briefed, made champions of the new system 3) end users need to be trained to use the new software. Training users and driving system acceptance requires adequate resources, and the right resources. It requires scheduling, time and commitment from the business. Assuming you have these, the training phase can hit other snags. You might have a hard time explaining the change. When you circle back to key stakeholders it can appear that everyone's not completely on board. Maybe they're onto new things. Or maybe you never had their buy-in to begin with. The training phase can be an exciting prelude to a successful rollout where managers and end users are pumped up . Or it can be a weak launch muddily communicated that snowballs into passivity, avoidance and apathy.
How to Successfully Implement New Software
Luckily, there are four things you can do to improve the success of your software implementations.
1. Pick the right solution.
A failed implementation does not always mean that the implementation process is what failed. You might have picked the wrong software. The point of software is to make your life easier. The right package will adapt to the needs of your organization.
Step one to finding the right vendor is to identify your business problems to solve and the needs that must be addressed by this new software. This has some unexpected twists and turns.
Requirements and features
Often, defining "requirements," or what the business needs, is a logical first step. However, doing it the wrong way can lead to working at a lower "in-the-weeds" level and missing out on the much bigger forest. At their worst, requirements can and often are broken down to the level of a specific feature. That's what software salespeople want you to do. The more requirements and features you define on your list, that they can say they have, makes a stronger case for you select them. Ultimately, big lists of requirements that describe small features can take over and obscure what's most important to the business. Think of how a Ticonderoga number 2 pencil has the key feature of being bright yellow. Why yellow? The bright color makes it easier to find. It also provides a sharp contrast between the sharpened and unsharpened parts of a pencil. But if a competitive price is most important to you, pencil color should not be on this list. Listing unimportant features and cosmetics of software can get confused with more important things.
The "feature-driven method" is the easiest way but not always the best way to select a vendor. This method requires researching standard software features available in the market and creating a features list with detailed descriptions in RFI or RFP documents. Features are categorized as "Gotta Haves" or "Nice to Haves." You want to be careful to cull your list. There is a natural tendency to inflate the need for features, marking "Don't Needs" as "Nice to Haves" and "Nice to Haves" as Gotta Have." This is due partly as a CYA in case a key stakeholder at a meeting wonders: "I read about shine new tech object A online. Why isn't that in the list?" If this happens, you should sincerely ask, "what's the business need or priority you're concerned about related to that feature?" If the stakeholder can tie the feature directly to the business, add it as a "Nice" or "Gotta Have." Eliminating the clutter of what you don't need might seem risky. But if you do you'll spend your stakeholder's precious time on what's most important to the business.
Defining Business Priorities and Pain Points
Alternatively, driving your vendor identification by business "priorities" is a higher-level approach. Define your business strategy top-down and identify your pain points and concerns bottom-up. Use these priorities to filter through what's available in the marketplace.
"Business Priorities Method"
The "business priorities-driven method" is a higher-level way to select a vendor. This method requires a top-down review by key stakeholders, perhaps through facilitated meetings, to define their business priorities and pain points. Business priorities should be defined and organized at a high level of business and industry considerations, e.g. stage of the business, the industry, key markets, customer needs, the state of the company's operations, IT and communications infrastructure, acquisitions or other growth strategies, and the timing of other key initiatives (e.g. moving to a new ERP system, strategic partnerships, changes in key customer accounts, etc.). Pain points are stumbling blocks to running the business that the software can mitigate or eliminate altogether.
Defining your Short ListYou can use your list of requirements to help you narrow down the list software vendors to your "short list." For example, if you are looking to improve time and job tracking for your field crews, it's a bad idea to go with a timesheet software vendor whose architecture does not currently support crew timesheets, no matter what the vendor says. You never want to select a vendor whose solutions don't have your "gotta haves." If their software's architecture, data model and their business logic does not support your core needs out of the box, you're buying a house without the proper foundation. If the implementation will take 9 - 12 + months to deploy, and your business is evolving, the software can be outdated from your business by the time you go live.
2. Involve stakeholders and representative end users.
In an MIT Sloan Management Review and Capgemini Consulting study, 63% of managers blamed the slow rate of technological change in their workplaces on “lack of urgency” and failure to communicate the true benefits of adopting new technologies and tools. If adoption is not prioritized and the benefits of new technology not clearly explained, your employees won't see the point of switching to a new tool.
The simple fix to make sure you involve key influencers, i.e. star employees who work horizontally across your organization and have good communication and networking skills, in any software evaluations. If these influencers adopt new software and tools early on in the implementation process, they can act as a positive influence on employees who are more resistant to the change. In addition, before you even begin evaluating software, you should survey managers and employees generally on the major "pain points" of your current processes and systems. Find out what they would like to see improved, changed or gotten rid of altogether. Integrate this information with your requirements documentation. When you start evaluating new systems, have key influencers and representative samples of managers and employees do a test drive. Note their reactions and opinions and feed this information back into the selection process.
Later on, your influencers will be on board early and will help with the general software training and adoption process when you roll out the software.
3. Evaluate vendor support services.
Some software vendors do not just bag the sale and move on. But some do. Be sure to ask questions about what kind of support vendors offer. Insist that the vendor provide a free trial that is fully supported so you can evaluate their support levels. Use their general technical support to ask questions. Are the support representatives highly-trained? Or are they merely reading prompts from their computer screens in a distant call center in India?
For example, at Pacific Timesheet we allow customers to experience or support levels during free trials and evaluations. We support free-trials as we would a paying customer.
4. Set realistic implementation deadlines.
You need to be realistic about your implementation schedule. Remember that your software vendor might tend to under-estimate the amount of time and effort you will need to implement their software. For your part, keep in mind that switching from one system to another is not easy. Poor requirements definition, sloppy evaluations, poor buy in, and inadequate training and implementation resources never speed up your schedule.
5. Budget for adoption programs from the start.
Having an adequate budget for training and implementation is crucial. It’s unrealistic to expect your employees to learn and effectively operate a completely new system without any formal training, especially if are moving from a manual to a software system.
6. Carefully design and schedule your training.
Finally, the end user software training requirement for time and expense tracking software is not very challenging. However, if you want to include changing time and labor policies in your time and expense software training, then your training development will be more challenging. Offer multiple training sessions to accommodate the range of employee schedules. You might also consider differ training content media for different types of employees. In addition to user guides you should consider the production of training videos to on-board new employees later on.
Ultimately, the best thing you can do to improve your implementation success is to have a solid plan. Developing your implementation plan should break down the most important phases:
- Phase 1: confirm system requirements.
- Phase 2: configuration of global system settings.
- Phase 3: development of any enhancements.
- Phase 4: pilot testing of major features.
- Phase 5: finalization of third party system integrations.
- Phase 6: development of custom reports.
- Phase 7: software roll out and follow up monitoring.