Planning for Product Adoption – Step Three

Introduction

Depending upon the product (or service) in question, full product adoption can be a potentially quite complex and even onerous task to perform well. As with all complex tasks, the secret is to break it down into its constituent components and then to deal with each component one at a time (as much as possible at least). There are many ways in which product adoption could be divided up and broken down into separate parts. The steps I have divided up adoption planning into are shown below:

Step 1: Determine Adoption Requirements

Step 2: Identify Process Changes

Step 3: Create Impacted Groups (IGs)

Step 4: Document Practical Considerations

Step 5: Determine Communication, Training and Support Requirements

Step 6: Capture Adoption Barriers and Risks

Step 7: Create Outline Adoption Plan

Step 8: Create Adoption Proposal and Gain Acceptance

Step 9: Complete Full Adoption Plan and Publish Adoption Roadmap

In my previous article  I explained the first two steps in adoption planning, taken from Chapter 8 of my book Practical Customer Success Management. This week I’m focusing on Step 3: Create Impacted Groups (IGs).  As I mentioned in the last article in this series, being a chapter from the mid to later stages of the book, it does assume knowledge attained from previous chapters, and it also mentions downloadable tools that purchasers of the book have access to. But hopefully as a standalone series of articles it will provide a useful reference for CSMs who are looking for a way to break down the adoption planning process into a series of tasks and to learn how to perform each task efficiently and effectively. Also just to mention that of course adoption planning (and the use of the tools discussed herein) is also covered in detail in my Certified CSM Professional training program and within the upcoming Practical CSM Academy subscription site.

Step 3: Create Impacted Groups (IGs)

Determining which workers are impacted

Once all of the changes to processes within all impacted capabilities has been documented, the CSM and SPL can now review this information to determine who within the customer organization will be impacted and in what ways that impact will be felt. In less complex initiatives this task may be very obvious – even self-evident – from a casual glance at the process change related information contained in your documentation (for example in the second worksheet within the Adoption Requirements Questionnaire tool that comes as a downloadable resource when you purchase my book Practical Customer Success Management). However for more complex situations where many processes from within many business capabilities were identified as being impacted, and where many different types of users were identified as being involved in these processes the situation may be more difficult.

Understanding impacted groups (IGs)

An impacted group (IG) is simply a group of users that share the same impacts or changes on their activities. What the CSM needs to ensure gets completed is to group the impacted users into relevant IGs and to document the impacts for each IG. Grouping up users into IGs is just a matter of pattern spotting and it is done to simplify the process of planning change management needs for these users. As stated, an IG should contain all of the users who share the exact same impact on the activities they perform. So for example a customer organization might have a workforce of 500 call center workers, all of whom will impacted in the same way by the implementation of new call center software. Rather than worry about the change management needs of each call center worker individually it might make sense to treat all 500 of them as one single impacted group which can be given a meaningful name such as “Call Center Workers”.

Determining IG membership in more complex situations

Where the determination of IGs can get trickier is in more complex situations. Let’s use the same example of a customer organization which is implementing new call center software and which has a workforce containing 500 call center workers. Perhaps this workforce is divided between two physical call centers – one in New York and another in San Diego. Perhaps the 250 workers at each call center further divides up into 220 customer support workers who respond to phone call queries from customers, 22 customer support team leaders who also respond to phone call queries from customers but who also manage their team of ten customer support workers, and 8 call center managers who oversee the entire workforce at that call center. So the question is: “Are each of these different roles impacted in the same way by the proposed changes?” If the answer is “Yes”, then just one IG can be created that contains all 500 workers.

Creating IGs to cover different roles

However it is very likely that the answer is “No” in which case it might be necessary to create further IGs to define the different needs of all of the users, based upon their different roles. One way to do this may be to create an IG called something like “Call Center Customer Support Workers”, another IG called “Call Center Team Leaders” and a final IG called “Call Center Managers”. The correspondent workers can now be placed in their relevant groups.  Note that the “Call Center Team Leaders” act as team leaders to their teams of ten customer support workers but they also act as customer support workers themselves. Since these workers will be impacted by changes to processes in both roles, the team leaders should therefore be placed into both the “Call Center Customer Support Workers” and the “Call Center Team Leaders” IGs.

Creating IGs to cover different KSA gaps

Readers will recall the information about KSA – knowledge, skills and attitude – that was discussed in Chapter 7 of my book. For each IG the CSM needs to ensure that the knowledge, skills and attitude “gaps” are recorded accurately. These gaps are what will be addressed within the adoption planning that will come next, and therefore represent what will actually get implemented as practical assistance to the impacted users to help them perform their roles adequately.

KSA gaps can be defined as the knowledge, skills and or attitude that each impacted user within the group is missing (ie do not already have) but which will be required by them in order to fulfil their role once the planned changes have occurred. To calculate KSA gaps the CSM (and those they work alongside to perform this task) will therefore need to understand both what knowledge, skills and attitude are needed and what knowledge, skills and attitude already exist. This gap may be different for different workers, even when the role is the same. If this is the case then those workers may need to be further divided into separate IGs rather than all placed into the same IG which is defined purely by role.

Going back to our example situation, perhaps the situation at each physical call center is different. Perhaps the New York call center was recently acquired by the customer organization and currently uses completely different call center software than the new software which is going to be implemented during this initiative. Conversely perhaps the San Diego call center already uses a previous version of the same software. So for the New York workers the change they will undergo will be greater than for the San Diego workers, since the New York workers will need ground-up training and familiarization with the new software package whereas for the San Diego workers it may just be a matter of upgrade training that identifies the changes between the previous software version and the latest version. Note that the role the same workers in each call center performs remains the same, but the difference is in existing knowledge. The San Diego workers are already familiar with the software package in general terms, but for the New York workers the software is completely new. There may therefore be a need to create two entire sets of IGs – a set with “New York…” at the start of each title and a similar set with “San Diego…” at the start of each title.

Is that everything? Perhaps, or perhaps not. What about new employees? From time to time this customer organization will no doubt be recruiting new employees to work in its call centers. These new employees might be existing call center workers switching employers or might even be graduates or others with no previous call center work experience. In either case there may be a need for further IGs to be created that define the further and differing KSA needs of these groups.

Additional IG considerations

Going back to our example, another issue that might raise its head is availability. It would be unreasonable to expect all of the customer support workers and customer support team leaders in say the New York call center to be available to undergo training at the same time, since that would mean that no one would be left in the call center to manage customer calls. Since there are 22 teams at the New York site (each comprising ten workers and one team leader), perhaps the training could be arranged so that it will be delivered two one or perhaps two teams at a time, therefore always leaving the remaining 20 or 21 teams available to cover the telephones. The CSM could create separate IGs for each group, but in practice this will create a lot of additional project management complexity and is unnecessary since it is a consideration about how the training needs to be delivered rather than about any difference in actual needs. The recommendation here would therefore not be to create separate IGs for each team, but instead to note any such requirements as information about the IG so that when the time comes to determine how the training will be delivered this sort of practical consideration will be allowed for.

The importance of getting the IGs right

The above fictitious situation is purely an example of the types of complexity that the CSM may face when determining IGs and placing impacted users into those IGs. What it hopefully has illustrated is the need for CSMs to think very carefully about which IGs need to be created and which impacted users need to be placed into each IG. Performing this task well is very important, since the formulation of all change management services (communications, training, certification, coaching, support and so on) will be based on these groups’ change management requirements.

How to define accurate and useful IGs

In summary, to define accurate and useful IGs the CSM should follow these steps (or make sure that the customer has done so):

1. Thoroughly research all impacted processes and document how each impacted process will change
2. For each impacted process document which users are involved – these are your impacted users
3. Create IGs (impacted groups) where each IG represents a defined change that needs to be addressed within the change management process
4. Place impacted users into the IGs based upon role within each process
5. If necessary subdivide these IGs into additional IGs to represent different KSA gaps (eg the difference between workers with existing familiarity and those with no familiarity of a software package) and place the relevant users into each IG
6. Do not subdivide into further IGs that do not denote any difference in knowledge, skills and/or attitude gaps. Instead note any additional considerations (such as availability issues) as information about the IG

Documenting IGs

It is possible that some or even all of the above work on identifying impact users and grouping them by change management needs has already been accomplished by the customer prior to the CSM’s involvement. If this is the case then the existing documentation of this information may already be satisfactory to use as the basis for creating the adoption roadmap. However the likelihood is that whilst the SPL and/or other key stakeholders within the customer organization have (or have access to) the information, it is not all in one place, it is not all in one format, it is incomplete and it is not centrally stored and managed. If this is the case it makes sense to create new documentation that is specifically designed for the purposes of adoption planning and that is accessible by the CSM, the SPL and whoever else needs to view or edit it. A template for this purpose is provided in the third worksheet within the Adoption Requirements Questionnaire tool. This provides a way to list the different IGs that will be impacted together with impacted user membership for each group, KSA gaps for each group and notation of any additional information that needs to be considered at the adoption planning step.