Change Management (i.e. Helping clients adapt to the change)

How to start designing change management materials

According to a study of failed Deloitte projects, the main reason that projects fail is people's resistance to change; therefore, helping your client manage the change involved with implementing a new system is critical. In addition to soliciting input from your main client and main users during inception and the development process, it is important to consider what materials you can create to communicate necessary changes and transitions to the many other people impacted by the new system. A key element of the success of your change management strategy depends on your ability to create useful materials for each type of user or developer community. Use the outline below to help you assess the specific needs of these communities, and how to select and create the best supporting materials for these communities. The reading is organized into the following sections:

  • Communities affected by the new system
  • Assessing each community
  • Identifying appropriate materials for each community
  • Types of materials
  • Training 

Communities of People Affected by the New System

When creating materials to help manage the change introduced by the new system that you're creating for your client, you will need to consider three communities of people:

  • Users - these are the people who will use the system once it is completed. They may be internal employees who use an entirely internal system, or they may be external customers who visit the organization's website. These users will not be expected to make updates to the system or maintain the system in any way.  
  • System administrators - these are the people who will maintain the system after it is delivered. Common maintenance tasks include system backup, data backup, and management of user accounts. If the client incurs monthly or yearly fees to host or access a software product, the system administrator will be tasked with ensuring those payments are made in a timely manner. Depending on the type of system being developed, system administrators may also be responsible for adding new information to the system, such as adding new product details or updating existing product details. 
  • Developers - these are the people who will modify the system once it is completed and delivered. Common development tasks include fixing bugs as they arise, improving system performance, and adapting the system as the organization's environment changes.

For all three communities of people, it is important to consider both the current community as well as future members of the community when designing and creating the materials they will need to successfully use/maintain/alter the system.

Assessing the User Community

The materials that you create for the users of the system should allow them to complete an entire process independently (i.e. without asking you, other developers, or other users how to do something). In order to create the type of materials that will be most valuable to a particular set of users, it is important to consider the following for each user group:

  • Are the users internal or external to the organization?
  • How much are the users impacted by the system (e.g. significantly, not at all)?
  • What is their role in the organization?
  • What is their level of business experience?
  • What is their level of technical ability and experience?
  • How often will they use the system (e.g. daily, weekly, monthly)?

Assessing the System Administrator Community

Similar to users, you will need to create developer materials that will allow them to maintain and make changes to the system without having to contact you for future support. Since the level of technical and business experience will vary significantly for those responsible for maintaining a system across clients, you need to ask the following questions:

  • Who will the system administrator(s) be (e.g. someone on the IT team? Your client?)?
  • What is their level of business experience?
  • What is their level of technical ability and experience?
  • How often will they perform administrative tasks on the system?
  • How does this inform documentation/training?
    • Format
    • Process frequency - how much detail?
  • Are they aware of the project and on board?

Assessing the Developer Community

Developers will need materials to support the enhancement and evolution of the system that you created without having to contact you for future support. Since the level of technical and business experience will vary significantly for those responsible for developing a system across clients, you need to ask the following questions:

  • Who will the future developer(s) be (e.g. someone on the IT team? Your client)?
  • What is their level of technical experience?
  • How often will they perform development tasks on the system?
    • Did you clearly comment the code/areas you customized?
    • How will users report issues? Is a feedback loop built into your application?
  • How does this inform documentation/training?
    • Can they follow installation guide or make changes to the code/system?
    • Format
    • Process frequency - how much detail?
  • Are they aware of the project and on board?

The answers to the questions above will help you determine the type of documentation and training you must provide as well all the level of detail that you must provide across all support materials for your client. For example, what level of detail must you provide for the administrator to be able to back up the system or manage user accounts within the system? Do you need to provide screenshots and detailed steps? For the developer, what level of detail must you provide so that they can follow the steps that you've included in the installation guide to set up their environment and migrate code to the production environment? How much detail must you provide in order for them to make changes to the system itself (e.g. fix a bug)? What level of commenting do you need to provide in your code (e.g. much more detail for a less technical person)? 

For all three communities, the answers to the questions will help you determine the type of materials required for the community as well as the type of training required for both current and future members of the communities. You'll be able to select the best format(s) and the required level of detail for each type of materials that you create.

Identifying Appropriate Materials for Each Community

The answers to the above questions will help you determine what type of user materials will be best suited for each type of community (users, system administrators, or developers). We first need to consider the level of detail needed by each group. For example, if internal users have a lot of business experience, use the system daily, and are fairly technically savvy, reminders of common tasks (typically in a QRG) will be most relevant for this group. Alternatively, if the internal user do not have much business experience, are new to the organization, only use the system monthly, and are not very technically savvy, detailed user documentation will likely be more useful for this group. Also, groups with less technical experience may prefer documentation utilizing screenshots or videos to illustrate the system and the steps they should perform.

After determining what level of detail is required by the various user groups, it's important to also consider the format of the documentation. For example, if you're building a website for external users, user documentation would likely be most effective if you embed it in the website itself (e.g. help/instructions included within a particular page for a particular process; pop-up tips within the page; link to a comprehensive pdf accessible on all pages). Internal users with extensive experience and are technically savvy may prefer a small printed and laminated QRG that they can easily access at any time at their desk.

Finally, for all types of user documentation, be sure to evaluate the ease of maintaining the materials. If your client plans to evolve and make changes to the system after you deliver it to them, providing documentation that is easily editable will be most valuable to them (e.g. editing a Word document that can be converted to a new pdf file is easier to modify than a YouTube video).


Types of Materials

Manuals - A manual is a comprehensive guide through all functions and processes that are part of the new system, and should have a comprehensive table of contents to help the person navigate the document. Each system process is covered to the extent that the user/system administrator/developer can follow the steps listed in the manual to accomplish the process/function without having to ask questions of you, their peers or the developers for how to do something. The level of detail required to describe the steps in the process will depend on their roles, their business and technical skill level and experience, and the level of organizational turnover (e.g. volunteers that come and go versus employees who work at the client for years). Many clients value pictures or screenshots to help illustrate processes in manuals (ask your client for their preference). Whether you incorporate pictures or have a "text only" manual, providing detail for every step is key.

When creating the manuals, be sure to consider how the user/system administrator/developer will access them. For example, is there a link to a pdf file accessible from every screen in your system? Is the manual hosted on an external website? Will the manual be printed for each user and stored in a binder? Be sure to consider how the users/system administrators/developers perform their work and what would be most feasible for them (e.g. a road warrior likely doesn't want to carry a heavy printed user guide from location to location).

Quick Reference Guide (QRG) - Quick reference guides provide assistance for the most common and frequently performed tasks. QRGs are typically shorter and easier to reference than an extensive manual, and should not have a table of contents due to its brevity. Most QRGs are restricted to one page (sometimes not even a full page) to maximize the ease of finding relevant information. For example, at HEB, each checkout clerk has a QRG that contains all produce PLU codes so they can quickly reference the PLU # for each item. Refer to class slides for QRG examples. Like extensive manuals, be sure to consider how the user will access the materials (link to pdf? Print and laminate the QRG?).

Online help - Depending on your client's needs, it may be helpful to embed helpful instructions or tips into the app or website that you create. It may be helpful to utilize small pieces of a comprehensive user manual and embed them as pop-ups throughout the system (e.g. when a user clicks a question mark next to a particular field or link on a screen in the system). Tool tips that appear when users hover over different parts of your system can also be helpful. Depending on the nature of your system and how it will be used, consider creating a separate FAQ page that can be accessed from every screen in your system.

Videos - Some clients are very visual and would prefer watching a very short demonstration over reading through pages of written instructions for how to perform a task. The ease of creating and hosting short video clips to demonstrate specific actions allows this to be a realistic option for your client. Consider what the video would encompass - voice over, screen capture, team member making a presentation - and work with your client to determine what would be most effective. There is a wide range of freely available software to help you create relatively professional videos for your client. Before shooting the video, create a detailed plan and script (if necessary) for what to include in each video, and determine with your client the appropriate target length of the videos to ensure they will use them after project completion.

The types of materials listed above can be used to support any of the communities: users, system administrators, or developers. For example, you could create three different comprehensive manuals for each community. The user manual would explain how to use the new system, including written descriptions explaining the purpose of each function/feature and step by step description of how to use each function/feature. The system administrator manual would explain how to perform maintenance tasks, such as how to managing user accounts in the system, make recurring payments, and how to perform system and data backup. At a minimum, the developer manual would include detailed coding standards, installation instructions, system backup restore/reinstall instructions, and instructions for upgrades and maintenance. The length and level of detail required for the different manual types depends entirely on your client, the level of complexity of the system, the experience level of the communities, and the degree of support needed after the project ends; therefore, work closely with your client to assess their needs and create materials that will be most useful for them.


Training

Training is an activity that is performed, and is different than the materials described above. While you will likely create materials to support the training, training refers to the process for how you will teach the user how to use the new system. It may be helpful to think about the user training as a "class" that you will conduct with your client. You may need to create multiple trainings or classes for your client depending on that will be covered. For example, you may have one training for internal users to teach them how to use the system. You may have a second training just for system administrators to teach them how to use the system. Depending on the skill level of the future developers, you may have a third training to teach them how to alter the system and utilize the materials that you've created for them.

Because training is a process, you should consider the following logistics and create a plan for executing each training session you plan to hold with your client:

  • When will you schedule the training/class?
  • How long will the training/class take?
  • Who will attend the training/class?
  • Will you need to have multiple training/class sessions?
  • Where will the training/class be held (both physical location, but also the room - e.g. will you need a projector and screen? Do users need access to computers and/or the Internet?)? 
  • What materials do you need to create for the training/class?
  • Can the training/class be repeated when you're gone? (Train the Trainer)

The most effective trainings/classes allow the attendees to perform tasks on their own. As you have likely experienced as a student, a professor can perform a demo and make you feel as though it is straight-forward and you can repeat it on your own, only to find that you have many questions when you sit down to perform the task yourself. Consider how you could create multiple exercises for the client to perform using the materials that you've created (e.g. users: create a donor report; admin: add a new user to the system; developers: follow the steps to set up the sandbox environment on their computer), and see how well they can follow the instructions. Be sure to have a team member record all questions asked during the training/class so that you can improve the materials before final delivery.

In addition to referencing the support materials during the training/class, you may also need to create additional materials, such as PowerPoint decks to help organize your training sessions. You may also need to create additional materials to "test" your client on their ability to use the system that you have created. If you are unable to train future users, be sure that the training materials that you create can be used by your client for future sessions, and that you teach the client how to run the training session(s). This is often referred to as "training the trainer".


Conclusion

Like the other aspects of the development process, it is critical for you to consider your client's needs, their background, and how they will use the system when determine the type, format, and level of detail to include in the support materials and training that you create. To help you brainstorm, use the  Download Change Management Template

to ensure you thoroughly assess all stakeholders. In addition to the examples of materials used in past 374 projects below, please utilize the following links for more information about how to create effective support materials:

Examples

House of Songs(Hosted Wordpress solution)

Asset Mapping (Custom solution)