One of the pressures every Services Leader faces is the seemingly opposing objectives of shorter time-to-value and quick adoption.

Implementing more quickly is the desire of every ELT team because:

• The sooner the customer is using the software, the sooner they can start thinking about expansion – which means increased SaaS bookings.
• Churn risk increases the longer it takes to implement. Customers’ procurement departments will start to ask why they are paying an annual SaaS fee for a system that hasn’t been implemented.
• Fast, easy implementations are fodder for reference calls and marketing copy.
• The faster you implement, the faster you are able to recognize revenue.
• And, depending on your staffing model, faster implementations result in lower cost to deliver.

Adoption has only just started at go live.

For the customer, the project is not over at go live even if your team disengages. There is so much hype around system go live that adoption can easily be overlooked.

All of these things take time and consume hours, resulting in slower revenue and higher cost.

Balancing these two objectives should focus on reducing time to implement in areas that don’t negatively delay or impact adoptions, such as:

• Faster design
• Faster configuration
• Faster data conversion
• Fewer issues found in UAT

When looking at ways to reduce time-to-value , the temptation to reduce time spent supporting customer adoption is a short-term gain made at the expense of long-term adoption.

 How to Drive Adoption

Building specific activities into your Delivery Framework that support customer adoption creates a repeatable formula that can be executed efficiently.

Objectives

Starting at the handover from Sales, gather information about the customer’s objectives. Fully understanding what they are trying to accomplish allows you to set the tone for the remainder of the project.

When you are throwing a party, you can decide if you are going to play classical music, Reggae, or Pop. A party underscored by classical music has a distinctly different feel than one blasting “One Love” through the speakers.

A project driven by a customer’s desire to find efficiency through consolidation of different systems onto a single platform is very different than a project driven by the need to move from manual processes to automated processes.

Once you understand the underlying motivation for the project, you can adjust the project approach to align with the customer’s objectives. This alignment is subtle but creates a better customer experience which leads to higher adoption.

 Training

Creating a training plan that effectively trains customers on your tools is fundamental to adoption. If they don’t understand how to perform tasks in the tool they will struggle to adopt it.

Especially if the project is moving them from a manual process – which can’t be decommissioned and therefore is always available as a fallback option.

Making an investment in training will have long term benefits. Yet, it is often de-prioritized in Professional Services organizations. People tend to get caught up in the org structure (does training belong in Services or Product?). If you compare the cost of training to the Prof Services revenue, you are being too myopic. Training is a cost of adoption of the product, not a cost of the implementation.

When planning training activities as part of your delivery framework, ensure you are considering your different stakeholder groups. Think about the key points of your product delivery and what training will support them.

Early in the project – what training is needed for the customer’s project team in order to get them familiar enough with the product to make future conversations effective?

Throughout the project – what training is needed for the customer’s system administrator? How do you train the person who is going to become responsible for your system within the customer’s organization?

Toward the end of the project – how are you going to train the end users so that they have a smooth transition from their current solution to your solution?

Organizational Change Management

Most Services organizations leave Organizational Change Management to the customer. That means you are also leaving adoption to the customer.

It is almost guaranteed that your customer does not have a change management expert who is going to drive an effective change plan for their implementation of your solution.

As you think about your delivery framework, consider the tools and tasks you can deploy to help your customer do a better job of change management in their organization. One tool that every Professional Services organization should include is a Change Management Guide. This is a generic guide (not specific to your solution) that educates the customer on the principles of change management. This is provided at the start of the project and helps the customer understand some of the tasks they should be planning for.

Another tool is to create a set of communications that can be provided to your Project Sponsor. These are specific to your solution, but will be altered by the Project Sponsor to make them specific to their situation. By providing these draft materials, you are taking the burden off the project sponsor to come up with a communication plan without adding responsibility for change management to your team. The bonus is that you are influencing adoption by focusing the communications on topics that are going to help drive adoption.