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!
Posts
