CRM Guide - Implementation

 So research and scoping done, business case complete, system selected - now it's time to start implementing your new database!

If you have successfully completed all steps leading up to this point, you're in a really good position. If you are working with a partner, it is likely that they will still want to do some more discovery for you - this will largely depend on how detailed the output is from your previous steps.

In all honesty, when we start working with organisations - even those that have done a decent amount of prep work - we still need to run more discovery sessions. When we have been given processes they are often high-level, and requirements may not specific - for example 'manage case work'. 

1. Discovery / Design

 This will likely include some/all of the following:

• Workshops, 121s, review of forms and spreadsheets
• Building out detailed processes to match the new requirements
• Building/enhancing user stories
• Design the database structure and map from your old set to the new, to make sure nothing is lost or that it is consciously removed

If you are working with a partner, it is likely they will be looking for some kind of sign off at this point. 

2.  Configuration

• DIY or partner-led
• Build out the systems to satisfy all the requirements. This will likely include:
  • Data structure
  • Reports
  • Dashboards
  • Forms for collecting data
  • Automations
  • Notifications
  • Templates for comms

3. Training

 Following the configuration, your partner (assuming you are working with one) should run training sessions to ensure everyone knows how to use the system. At t{h}onix we like to run a few 'show and tell' sessions first, to show you holistically how the system will work. This allows people to see the new way of working before throwing them straight into training - going straight into training then testing can be too overwhelming for people. It also allows us to get some initial feedback and change anything obvious before going into detailed testing.

Training is often run in a train the trainer model, where your partner trains your systems champions who will then be responsible for training their team members.

At this point we would expect your partner to hand over some documentation to support your training. Each partner will be different. Some might provide long form documentation, some might provide process flows and data structures, some might provide short form videos - it will depend on the partner and your needs. What your partner won't document is:

• Anything that is already provided by the system providers documentation
• Low-level user guides, ie. step-by-step instructions with every click documented and screen shots of every screen
• Processes that extend beyond the scope of their work. For example, if you have an approval processes that runs through your finance system, but it is beyond the remit of their work, then they won't document this.

4. Testing

 If you are working with a partner they will do their own testing first which will be against the requirements; if it wasn't in the requirements it won't have been configured.

No matter who configured the system, you will have to test it against your user stories. This is your opportunity to make sure the system is doing everything you are expecting. Testing shouldn't be done by one person. At a minimum it should be your system champions, however this is also an opportunity to involve other team members. Before starting your testing, make sure you have the following in place:

• Test plan - what and who - this might be as simple as using your user stories with the acceptance criteria
• A way to indicate pass/failures and reasons for failure
• A robust way of raising bugs
• A way of triaging bugs

At t{h}onix we provide our clients with detailed guides on how to go about testing. It is likely that other partners will have similar resources they would share with you ahead of starting your testing.

You would work alongside whoever has implemented your system to develop an appropriate cadence for bug fixing and retesting. 

5. Processes and documentation

 Your partner will likely have provided you with some key processes to follow. For us, these tend to be flow diagrams with swim lanes to represent the different actors and systems involved, others might provide more wordier versions. Either way, you need to ensure that these processes are:

• adjusted to fit how you usually document
• include any additions that fall beyond your partner's responsibility. For example you may produce a case study after a programme you deliver ends - this is very likely to be outside the database.

If user guides are required then ensure these are ready before training. 

6. Extended Training

With your system's champions trained, testing completed and any documentation updated, you are ready to train the extended team. This is usually led by your system's champions in function-focused sessions. 

7. Data migration

 You're not live until mission critical data has been migrated. In all honesty, this process will probably have been instigated earlier by your partner, who will be encouraging you to start this alongside the configuration stage. How much you will need to do will depend on your partner. At t{h}onix we often take all of this work on, but more often than not partners will draw hard lines over what they will do under the scope of a standard project. Broadly the steps involved are:

• Extracting and centralising data of the same type - for example if you have details of contacts spread across four spreadsheets, your partner is going to want all data of the same type bringing into a single sheet.
• Cleanse data - remove things that aren't needed (columns and rows in spreadsheet language). So if you are capturing data that you no longer need, eg. a specific demographic, remove it (this would be a column). If you have records from beyond your data retention policy, or data that is meaningless - maybe just a name and nothing else - then remove it (this would be a row).
• Clean the data - after cleansing clean what’s left, eg. email addresses and phone numbers. "Call mum" is not a phone number!
• Map old look up values to new look up values - for example if you historically had a long list of locations, but you have decided to reduce the number of options, how does that set of values map to the new set?
• Create import templates - if you have a partner this is the minimum they should do. This is where we map from one data structure to another.
• Import the data - this will vary depending on the system you are moving to, but involves taking the templates and importing the data into its new home.
• Post-data migration checks - your partner should do a first pass on this, but you should look to do your own. This could take various forms, for example comparing an old report against a dashboard, comparing counts, spot checking records.

8.  Agree change management process 

 Once your system is live you need a process in place for handling change requests. No matter how thorough your testing, you will not catch everything. The reality is that until you use the system in real world situations, you won't have tested all your scenarios - this is when you spot tweaks and changes that are needed.It's important that you have a process in place to handle this. Here are some things to think about:

1. Who is authorised to make changes? Is this a single admin or are will there be more than one?
2. How people raise a change - by this we don’t mean what tool they use, we mean how do they provide the information in a way that you can understand the problem. You want to avoid people providing the solution eg 'I need a drop down for this thing'. Rather, you need a good way to accurately record the challenge. It’s fine for people to give their thoughts on what they think a good solution might be, but only after you have accurately understood the problem.
3. What the reporting needs/implications are of this change - do you now need new dashboard cards, filters etc.
4. How you assess the implications of the change across other users and how you handle competing requirements - this is why we would suggest more than one admin user. Changes can go to the group and be considered holistically from all angles.
5. How you test your change and ensure this satisfies requirements, before rolling it out across all users.
6. How you communicate these changes to the team and provide training and a space for questions.