BI Rollout: Quick Wins

I was visiting a client recently to assess the status of their business intelligence rollout and plan some next steps.  This was my third visit over a two and a half year span, so one could expect that some progress had been made.  However, it seemed that they had not made as much progress as they should have given the time they have been working with the Argos product and the energy they have put into rolling out the tool.  In their defense, they (the IT folks mainly) were having trouble figuring out the right way to approach the user community to gain buy in and support.  They had been hit with a large number of requests for support from all of the administrative offices.  What this accomplished was a few mediocre reports and datablocks in a large number of areas.  As a result there was a sense of frustration among the user community (and in the IT area as well) and the tool was not being used as extensively as it could be.  As part of my recommendations, I told them to focus on getting some quick wins to help bolster their initiative as a whole and in an attempt to begin building back some momentum for the project; as we all know, adoption = success!

This led to additional discussions around how one can go about getting quick wins.  In my experience, the steps below (while not comprehensive) are a good place to start when thinking about who to approach and how to approach them, with the goal of knocking out a few solutions to gain some project momentum (quick wins).

1.       Focus, Focus, Focus:  The shotgun approach serves only to spread thin scarce resources (resources that, in most cases, are already spread too thin).  The result is a burned out support staff and frustrated users.  So, instead one should focus.  First, establish the departmental segments who will be part of the rollout project.  Then, from that list, try to determine those departments who are excited about the project (or at least not hostile) that also do not have extremely high expectations.  That combination will give your support staff the biggest “bang” for their time spent in support.  Once the “pilot” group is chosen, analyze their needs from the perspective of their business problems.  Another issue with my recent client visit was that the support teams answer to request X was to provide A-Z.  While this certainly included X, it took a long time to deliver because of the complexity involved in providing A-Z.  In the short term, following our focus mantra, it is important to deliver specific solutions to specific business problems.  Remember, our goal here is quick wins and momentum!

2.       Talk about the Problem, not the Solution:  Another difficult thing that my client was dealing with was the fact that the support team was being dictated to what the solution ought to be, rather than being allowed to do their job and take care of the solutions themselves.  This was partially due to the demand of their user groups and partially to the fact that the support team didn’t know how to approach their users in a way that focused them on their problem.  When discussing the needs of your user groups, keep them focused on their problems.  To do this, I often find myself asking questions like “what are you hoping to accomplish?”, “where is your longest process delay?”, “what single part of this process, if automated, would save you the most time?”.  These questions move the focus of the conversation from “I want every possible data attribute related to a student” to “I need to automatically generate a list of students for the current term who are on academic suspension, then email that list to their advisor”.  The latter is a specific problem that is clearly defined.  That information can then be consumed and addressed by the support team in a timely manner.

3.       Develop a Communication/Rollout Plan:  I assure you that momentum will begin to build as the pilot department begins to spread the word of their success.  In order to prevent further frustration from those folks who want support but are not yet part of the rollout project, develop a plan to communicate a logical process and timeline in which they will get the support they need.  While this may not make them happy (if you have to tell them they have to wait for several months), most people understand that resources are limited and will acquiesce.  However, they will only do so if they are told when and how they will eventually get what they need.  The difficult part for the team planning the rollout project is determining the proper order of development, after the pilot group.  Now that momentum is in place, it is my opinion that tackling the most data-driven part of the organization is probably the best plan.  Part of the communication plan should be a clear feedback mechanism for the administrative offices to provide change requests and requests for additional support after their “go live”.  They also need to be made aware of the support changes that may occur as the support team moves to another department after their go live.  In the best cases, a new staff member could be hired inside the department to handle support and development moving forward.

These same steps can be considered with going through any project implementation:  Focus, Talk Problems, and Communicate!  Remember that the measure of your success is not how awesome your BI solutions are, but how often/thoroughly they are used across campus.  Good luck, and happy hunting!