Part 2 - Implementing Software Doesn’t Have To Be Painful (Part 2 of 3)

Come Prepared. Leave Satisfied.

This is the second post in a 3-part blog sharing the secrets to selecting and implementing the right customer interaction software for your company. Here in Part 2 – Implementing Software Doesn’t Have To Be Painful, we look at how to build synergy with your chosen vendor and keep your momentum going to power through the project with positive energy.

Going into a software implementation, it’s normal to feel a mix of excitement about the benefits your business will reap, but also nervousness at the unknown. There are things you can do to move your business away from “We hope it goes well” and towards “We’re looking forward to this.” You don’t have to be a technology expert to get there. But you do have to know your business needs and help keep everyone involved in the project on track about what success looks like.

In Part 1 – How To Pick The Best CRM Solution For Your Business, we covered two actions you can take to help you decide which solution is best for your business: creating a high-level process map and gathering your requirements with tags of out-of-the-box, configurations, or customizations. For the purpose of this post, let’s assume that you’ve gone through that process, that you reviewed vendor responses and selected the software you want.

Realistically, you can use the requirements gathering template and process described in Part 1 for software that goes beyond just CRM. Even if you decide to have software built from scratch, that list of requirements is excellent to use with your technology team or vendor.

The name of the game in Implementation (when you set up your solution and go live) is expectation management. It’s a fancy way of saying that your business team and your solution provider are on the same page about three really important things: Cost, Timeline, and Scope. If this sounds familiar that’s because it’s a standard project management concept, usually called a triple constraint or triangle. Using the idea of a 3-legged stool helps illustrate what happens when these aren’t aligned. The stool tips over and falls.

Cost and timeline are easy to understand. Scope is another way of saying what’s going to be done inside the price and schedule of the project. Looking at the requirements list you built in Part 1, if every item is met out-of-the-box, scope isn’t a big deal because you’re getting 100% without changes. For requirements that will be met with configurations or customizations, that’s extra work, which means some type of impact on the cost of your implementation and the timeline or schedule. The goal is to stay balanced. If the scope leg gets longer, the cost and timeline have to get longer too. If you can’t extend the schedule or you don’t have the budget, you might need to shrink (aka cut) scope.

Estimating what’s involved in implementation is the first place that expectation management can go off the rails… and that’s before you’ve even signed a contract! Using your requirements list and designations of how to get the needs met keeps everyone on the same page. The downloadable template from Part 1 includes a place to show the priority of each requirement. You might need this if you have to cut or defer scope due to time or cost constraints.

Let’s say that you and your vendor have agreed on the target scope, cost and schedule for the project. Another part of expectation management, and one that should be addressed during the contract step when you set up your statement of work (SOW), is to list out the assumptions going into the project. If your vendor puts assumptions into a document, now is the time to read those and make adjustments where they don’t align with your expectations. If your vendor doesn’t include assumptions in their statement of work, you can initiate that to protect the interests of your business. If you purchase a big-name product and/or don’t use an implementation vendor, this won’t apply externally. But it can be helpful to do this internally between your business users and IT team.

Whether the schedule for your software implementation project is a couple of days long and done by a single internal resource, or the project will take 6 months and a team of ten people, you’ll need to test the system to ensure it meets your requirements. On larger efforts using a vendor, you should expect a defined testing phase. Without going into the weeds in this post about different types of testing (unit, system, integration, etc.), the two biggest concepts to understand here are that no matter how great your plan or tester is, testing can't be done in a vacuum. Representing all stakeholders in this phase is important. The second is that finding issues as soon as possible is better because they’re cheaper to fix and less likely to delay go-live the earlier they’re found and addressed.

Going on a slight tangent here… in software development there’s a concept of the V-Model which demonstrates the relationships between each phase of the development life cycle and its associated phase of testing. You can see this waterfall approach has the biggest gap between the requirements and user acceptance testing – basically the start and end of the project. That’s risky. If you don’t find a problem until the very end of testing, it’s expensive to correct. One way to combat that is using agile and iterative software development methodologies. In these cases, software development is done in shorter cycles or sprints with smaller pieces of scope. The concept can be applied to configuring software as well. The premise is that by tackling work in small amounts with greater user involvement you will reduce the risk of a gap at user acceptance. It works, but only as well as the quality of the requirements, the business knowing what it needs, and the ability to connect the users to the end solution. In Part 3 – Help Your Users Love Their New System, we’ll look at what steps you can take to make it even better.

If you’re using a project manager, that person should be keeping track of status from start to finish. It’s okay to have an internal project manager and a vendor project manager. The key to making this work is… you guessed it… expectation management. They have to work together but need to be responsible for separate things. The more complicated these arrangements are, the more risk in the project due to miscommunication and conflict. But done well, they can be project accelerators by providing specialized support to the different groups.

Speaking of risk, there are 3 core components to good status: Activities Completed/Planned, Progress Against the Plan, and Issues/Risks. The first two are straightforward. The last, Issues/Risks, is interesting. “Issues” are problems right now and require a resolution. “Risks” are things that might happen. Issues and risks both have severity levels but risks also carry a likelihood or chance that the risk will be realized and turn into an issue. Project management support can help you mitigate risks to lessen the likelihood that they’ll occur or else reduce the severity if they become issues. There's no right or wrong way to write a status. But reviewing these items regularly will keep you informed and manage expectations of project success. Pick an approach to status that feels comfortable for you.

You'll know you’re in the home stretch of the Implementation when your vendor or technologists report that all configuration or customization tasks are done and tested, that any system integrations – where different systems are exchanging data inputs/outputs – are tested and working, and that it’s time to have the users start testing.

In the next post, Part 3 – Help Your Users Love Their New System, we’ll dive into user acceptance testing, training and adoption. But for the purposes of this post, we only need to focus on the idea that overall success is going to be tied to being able to Pass the test of each of your needs listed in your requirements and included in scope. Because you phrased your requirements as “what” needs to happen and not “how” it happens, during testing you’ll not only be looking at whether the needs are met but also how that’s going to happen in the new solution.

It’s pretty common that the way the new solution works will trigger revisiting your business processes to pick up additional efficiencies and take advantage of more opportunities. In fact, good software products are packed full of best practices. Your solution vendor should be able to describe those best practices and assist you in aligning them with your business needs. Adopting those changes into the “how” of your operating procedures is frequently to your advantage. After all, you decided that this new solution was going to be better than what you started with!

If you enjoyed this blog post, please read on to Part 3 – Help Your Users Love Their New System.

Hartary Consulting strives to build great client partnerships by providing practical business operations advice to small and medium-sized companies.