Adoption

At newScale we run a quarterly management review of every single customer. Our account managers and product managers sit down with our customers to review implementation status, upcoming expansions, issues, future requirements and most importantly, status of adoption by users.   

We focus on adoption, because most of the systems we replace have about 2% adoption by employees. Some are bad, some are bad and ugly.  All of them lack adoption by  end users -- it's like owning  a store that never rings  sales; how fun is that?

This led us to focus on adoption in all its facets. Are there enough services? Is there enough volume?  Is it deployed in the right way? Does it map what users know?

I asked Boaz Maor, VP for Strategic Program Management, the executive in charge of the group at newScale that works with customer post-implementation, for ideas on best practices for  adoption.  These are some of his answers. If you have other questions for Boaz, ask them here and I will have him answer them next week.

What are the key programs activities to drive adoption?

Reports (show successes through highlighting the incremental knowledge gained through the use of the system, savings achieved, etc,), customer satisfaction survey. Partnering with the helpdesk: customers will call the hd with questions and attempts to avoid the need to learn a new system.

A smart catalog team would train the help desk team how to walk the customer through the ordering of the service rather than order for them. This will help educate the customers and drive them to use the system on their on later.

Demo on site: many customers embed a demo on the catalog homepage explaining how the system work and what the customer needs and can do. This can be as minimal as a set of screen shots in ppt, or as intense as a streeming video.

Lastly, THE most important 2 contributors to adoption are: 1) customer focused interface that makes it easy for customers to order services and includes most of the high volume services, and 2) eliminating the other routes of making requests (like other systems).

What does a typical implemenation team look like? What tasks do they plan to
rive adotption?
A: 1 program manager (normally part time), 1 project manager (FT), 1-3 service designers (FT), 1-3 tech suport team members (can be PT), exec sponsor (PT). Key driver of adoption is the program manager whose job is to drive program expansion through roadshows, reports and  analysis of potential value areas, etc.

This is only for the initial design, build and roll out. The on-going group is smaller.

What works? What doesn't? What was thought to work but didn't?
A: works: see above
Does not work: build it and they'll come...

How long should the program be run?  Are there phases?  What are signs of
trouble?
A: Highly recommended to enable the phase 1 of the program to customers as quickly as possible to drive excitment. To that end, best way is to enable as many of the high volume services first, even if the workflow on the background is minimal.

Phase II can focus on enhancing the workflow, adding integration to improve customer and fulfilment team performance and adding additional services.

Once you have excitement, you win permission to do more sophisticated and larger catalogs.  Typically people are very cynical that projects will work or ever deliver anything real meaningful.  So having a quick hit phase 1 can be a huge win.

Bad signs:  endless discussion on team structure, workflows with too many variations for the same thing, trying to create complex configurators, trying to re-engineer processes at the same time.