Putting processes into place is essential to the ongoing success of any analytics program. Most organizations can generate some isolated successes without the use of processes, and when you’re starting out, it is important to get some of those “quick wins” to gain momentum. Over time, however, miscommunications, inefficiencies, and just plain old mistakes can take their toll on your program and create significant hurdles to getting the maximum value out of your analytics. This is not uncommon – in fact, a survey conducted by Cutter Consortium found that 37% of the organizations that they surveyed did not have a formal strategy in place for extracting value from their customer data. Consider the following situations that stem from process breakdowns – have you ever experienced any of these in your organization?
1. You launch a brand new site, with all of the analytics tags and reports in place, only to discover that the CMO’s most important business objective was never documented or tracked.
2. Your organization has just finished running a major campaign, but you log in to your analytics tool to discover that none of your display ads were tagged.
3. Your site team makes some minor tweaks to how users can interact with a popular site feature, but no one ever checked to see if the tags were still working properly – and you didn’t realize it until you ran a report to determine if the changes worked, three weeks later.
4. You pull together a big site analysis to show to your boss, only to discover that none of the metrics in the analysis come close to matching any of the reports that he has received.
These situations are all extremely frustrating, but they can also be avoided most of the time with the creation of a few well-defined analytics processes.
When I create an analytics process, I usually start by asking the following questions:
1. What is the desired outcome?
2. Where have problems come up when this has been done before?
3. What exact steps need to take place in order to get to the desired outcome?
4. Who needs to be involved in order to do this successfully?
5. Is there anyone who is not directly involved with this process who needs to be aware of the progress or the outcomes, or who needs to give approval? When?
Sometimes, I don’t know the answers to all of these questions, so I need to start by looking elsewhere for this information. If you work in a large organization where many people are involved in planning, implementing, and reporting on your analytics initiatives, it is likely that you will need to set up interviews with the people who are most closely involved with these processes on a day-to-day basis. The benefit of talking to other resources who are involved in these activities is that you can gain some perspective from them on what their common pain points are, and hopefully avoid recreating them when you create a process.
Once I have gathered all of this information, I take the following steps to document a process:
1. Document the steps of the process, in order. I make sure to include steps for tasks, deliverables, meetings, and approvals – it’s best to list everything explicitly.
2. Define exactly what each step entails, and document it.
3. Determine what resources or resource levels are needed for each step. I make sure to document this, and include alternative resources when possible.
4. Review the process to determine if there are any inefficiencies, unnecessary dependencies, or other revisions that need to be made.
5. Pass the process through key stakeholders and resources who will use the process. This is critical – if the people who are going to use the process don’t like it or agree with it, they won’t use it. I often find that this is a great way to uncover other parts of the process that I hadn’t thought of before.
6. Make any necessary revisions, and then provide the process to all necessary resources and stakeholders. The more documentation, the better – and the easier the documentation is to access, the better. Remove as many roadblocks as possible to get as many people to adopt your process as you can.
Creating a process is not the end of your work (although sometimes we would really like it to be!). Once the process has been implemented and people have been using it for awhile, check back in – is everything working as expected? Are there common problems that are occurring, and can they be mitigated with a change to the process? Are the resources assigned to the specific steps still the right people? Obviously this is not an exhaustive list of considerations, but it is important to continually improve these processes in order to ensure that they run as seamlessly as possible – and don’t cause undue pain to those people who are performing these tasks most often.
If you have any questions regarding Stratigent’s approach to process creation, I would love to hear them. Please feel free to contact me at firstname.lastname@example.org.