The Super-Users

The so-called super-users are end-users of the tool who have been chosen from among their peers, who are too numerous to involve en masse, to participate in the CRM project. Their role is to give detailed input and feedback on how the job is done and how the tool can support the job. They have a role in defining requirements, evaluating the tools, and conducting usability testing. They are expected to be representatives of the larger user community, so they will likely poll their colleagues on various issues and give informal status reports in return.

Role

The main function of the super-users is to give detailed input to the project team on how the tool will really be used day-to-day. Although the functional managers are involved on the team (they are the business owners discussed above), there is often a big difference between the way end-users interact with a tool and the way their managers use it. Therefore, it's essential to go to the actual end-users to get accurate information, especially in larger organizations.

The super-users should be able to describe:

the data they use to do the job, including data that may be hard to come by today, but should be supplied more easily through the new tool;
the way the information should be presented to make the most sense to them;
how the process flows;
what information is needed at each step;
the most common tasks , which are the ones that should be streamlined in the finished product.

The super-users should also be able to prioritize project options to match their priorities on the job.

Occasionally the super-users' priorities will conflict with those of the business owners, which is always an interesting event during a CRM project. Such conflicts can be a great opportunity to identify process bottlenecks, if handled appropriately by the project manager. (I should have mentioned that project managers must be great diplomats on top of everything else!)

The super-users have the important task of defining the business testing criteria, often called the "use cases." This awkward phrase hides a very useful concept: defining a comprehensive set of criteria that the tool must meet even before any customization is created (or, in some cases, even before the tool is selected, although that is a bit extreme). The super-users have the required hands-on experience to define the criteria, which are task-based , and, down the line, to perform the hands-on testing. It's always a good idea to ask other end-users to participate in the testing, as the super-users have become too familiar with the tool to be truly objective by the time the testing is performed.

The super-users are also the natural team to test the training program and documentation for the tool. As for the testing of the tool, the super-users know entirely too much about the tool to be good judges of either by the time the training is developed. It helps to bring in some additional, fresh volunteers at that point to make sure that the level is right for people who have never used the system. Whatever their limitations may be when testing the training materials, the super-users make good trainers or trainer assistants since they understand the process being automated and have intimate knowledge of the new tool within the business context. They can also be of great help in the early stages of the rollout to provide ad-hoc support to their peers.

Although super-users will provide a lot of the input straight from their experience, sometimes they will have to consult others in their groups. The project manager should be sensitive to this specific need and should select individuals who are willing to work with the rest of the team. The project manager should also provide the super-users with the practical tools they need to gather feedback from their team. For instance, the project manager should make it easy for end-users to access the development or testing system when required to give feedback to the super-users. This issue of access is one of the big headaches of CRM implementations .

Super-users also serve as the project's informal ambassadors within their teams . The savvy project manager understands that keeping them informed and reasonably happy can go a long way towards creating a positive attitude in the larger team.

Requirements

Whom should you pick as super-users? First and foremost, super-users should be real and current users. Taking an individual from the field or the support center and placing him or her on the project team on a full-time basis is going to be a disaster. Within a few weeks of the transition, the individual gradually forgets the specific rhythm and frustrations of the job, while processes and conditions change in the field or the support center without the individual being aware of the changes. Whatever you do, do not remove the super-users from their day jobs.

This can cause interesting dilemmas, since, after all, real end-users have real responsibilities, some of which are sure to conflict with the very real work of being a super-user. Some scheduling finesse is required here. The project manager should be sensitive to the ebb and flow in the super-users' workloads, while the business owners must schedule some slack in the super-users' duties for the duration. For example, it's not a bad strategy to assign to super-user status an individual who, for whatever reason, needs a breather, perhaps because of travel burnout or a specific personal situation that requires a limited schedule. Just make sure that the individual is indeed performing a real end-user job when not playing super-user.

An added difficulty is that the super-users should be chosen from among the high performers. Business owners can be tempted to volunteer marginal contributors since they will be missed less than their high-contributing peers. The problem with that approach is that there are reasons why the marginal contributors are marginal. One reason may well be their lack of knowledge of how the job should be done when done well. The last thing you want is to replicate that lack of knowledge in the tool. Additionally, marginal contributors rarely generate any respect from their peers, so putting them on the team deprives you of the important ambassadorship aspect of their role.

Which brings us to another aspect of selecting super-users: tapping into the informal leadership of the group to select those individuals who have the respect of others without necessarily having a special title or place in the hierarchy. If the project manager is not familiar with the group, as would be the case for a consultant, the business owners should help identify the informal leaders and choose within that group the ones that would make good super-users.

Using informal leaders has two advantages. First, and obviously, because they are well connected to others, informal leaders will bring better information into the project, and they will be very effective in spreading the word about it. Second, informal leaders reach that status in part because they do their jobs in ways that are recognized by others to be superior , so that when they share their techniques with the project team to be automated in the tool, they contribute techniques that are likely to work for everyone. On the other hand, top performers who are not informal leaders often use techniques that are highly idiosyncratic and may not be suitable for others, so that modeling them into the tool may be counter-productive. If you happen to find informal leaders that are also top performers, you've hit the jackpot !

How many super-users should be on the team? One factor is the user population. If there are four different groups using the system, the right number of super-users is higher than four. Another factor is the maximum desirable size of the super-user team. Twenty super-users are too many, at least if they are all focused on the same specific tool. The right number of super-users is one or two per business owner, and business owners can't be many more than a half- dozen . As long as you identify high-performing informal leaders, adding more will not increase the quality of the project, only the confusion and coordination overhead, so know when to say enough.

One short note here about dissenters. You may find that some informal leaders can be thorns in the side, always having an opinion about everything and always raising issues. They don't belong to the school of only speaking out when it's important: they find something to speak out against in each and every initiative! If you find that you have such dissenters among the informal leaders, I recommend placing them on the super-users' team under the theory of tackling problems early.

Here I'm talking about dissenting informal leaders, not lone dissenters, who can be identified and handled by the business owners as they see fit. Dissenting informal leaders happen to have an audience, which is a sure sign that at least on occasion they are right on, and they are right on in a way that is recognized by others. Placing them on the super-user team makes for much more interesting team meetings, to be sure, but with enough attention from the project manager and the business owners the dissenters can bring you two wonderful benefits.

Because they are contrarians they will identify problems that no one else has thought about. Sometimes, the problems will turn out to be moot, but often enough they will turn out to be absolutely critical. Dissenters have a talent for identifying neglected issues and small but insidious problems, and they do great testing. The quality of the end product will be much improved through their contributions.
The second benefit is that, if you can bring them to the point that they are actually happy with the system (not totally happy, it's not their style!), then you will have effectively disarmed a lot of the negative reactions from the user community.

Bring dissenting informal leaders into the team. They will increase both the quality and the acceptance of the project, the two reasons why you need super-users in the first place.

How much time should the super-users schedule for their work on the project team? Quite a bit, and quite a bit more than the business owners although their participation should never reach the point of full-time involvement since the whole idea is to involve actual, current users of the tool. Let's take an inventory.

Super-users must be a part of defining the initial requirements, which will take several hours to several days. They will spend more time than business owners because of the level of detail required.
Super-users should evaluate the candidate solutions. A decent strategy might be to have a couple of super-users participate in the initial review for each candidate, only involving the entire group when a particular candidate is deemed promising . Thoroughly investigating one vendor may take a couple of days. This is, again, significantly longer than business owners must spend since there is more hands-on work required.
Super-users must participate in the implementation requirements workshop: a day to a week depending on the complexity of the project, just like the business owners.
Unlike the business owners, super-users need to be involved throughout the implementation to test the system and to give feedback on technical decisions. The time requirements can be high, as each testing session requires several hours, and this doesn't include the work required to get feedback from their teams.

If testing requires travel to the development center, time adds up quickly. I believe that the project manager should set up the necessary environment to cut down on travel. Yes, there are lots of benefits to getting the super-users together physically in one room, but I don't believe you can recruit the best super-users if you require big chunks of their time doing low-outcome tasks such as sitting in a plane.

Although the testing time required is high, super-users have very little to do during focused development periods, so the scheduling for the more intensive requirements such as testing can be done so as to minimize conflicts with their real jobs.

Overall, a serious super-user may spend 20-30% of his or her time on the CRM project, although this will vary from none at all (during coding period) to full-time (during testing, for instance). It is a significant burden .