In the fall of 2017 I had the joy and honour of
hearing Bob Tipton speak on
engagement in a data science conference. He came in as the odd man out, and fit
perfectly within the group of speakers; nearly every speaker and every attendee
was struggling with this concept. How do we bridge the gap between the business
users and the technical users in our organizations? I am very much
oversimplifying here, but he spoke about setting the bar, not to getting “buy-in”,
but instead aiming for “ownership” from your business users!
I am not sure if I have a definitive answer, but I can
do my best to explain the model I have been using in leading engagement within
my organization. Deferred ownership!
Regardless of the nature of the initiative we work
with using our DataOps model, our ultimate goal with each and every one, is to
defer the ownership of the product to the business user. By doing so, we are
able to keep them engaged throughout the development process, and at the end of
that process, we transfer all ownership and administrastion directly to the
user or client. Once they have ownership, they have continued to champion that
product throughout the organization without any of my team having to be
directly involved. In doing so, they then build up increased organizational
awareness of the program I lead, and increase demand for more.
I am going to bring up a major example of how this was
accomplished. We began in the early phases of launching business intelligence
with a simple goal: to provide a dashboard to the college registrar’s office, on
total headcounts and demographics. In meeting this challenge, we apporached it thusly:
1.
Captured business requirements in a single 1 hour meeting,
discussing the elements to be reported, the source systems, and the basic
reporting layout questions.
2.
Designed the data
extracts and integrations into our staging area, utilizing a landing zone for
raw data, and a clean zone for transformed data. Engaged again with a 1 hour
meeting with the business user on the clean data tables, as well as the
Business Analyst for the area who had been providing direct from transactional
system reporting, that was previously used.
3.
Created a
prototype of the reporting object, and launched it into development. At this
point, we handed this prototype off to the business owner, and a maximum of 2
other delegates from the business area, to use. We provided zero training, with the exception of indicating to the
user that they use the report and do everything they could think of to break
it, mess it up, or otherwise misinterpret any of the report objects.
Simultaneaously, we scheduled a 15 minute weekly follow up with the business
owner.
4.
We met for 15 minutes with the business owner once
per week to discuss their feedback on both data element validations, and layout
and intuitive functionality. Each data validation that needed to be addressed
was removed from the prototype until it could be validated further and then
reinserted, and any areas of ambiguity were addressed with more easily
functioning and usable reporting visuals and interactions. Over the course of 3
weeks, from the initial prototype to launch, we were able to address all the
elements of validation and abiguity.
5.
Once the user was
happy with the data, the layouts and the functionality, we created a new active
directory group for the report, transferred adminstration of that group to the
owner, and officially handed the report over to the owner with the instruction
sheet on adding and removing people, and the noted that they owned that report now, and we would continue to support it,
but not claim ownership of it.
The outcomes of this exercise did, and have continued
to exceed my expectations. By having ownership of the report, and having been
involved in the design and validaiton of every element, we were able to move
the business user beyond buying into the product, and instead, they have taken
it, and championed it as the source of truth for the organization.
In the months since this was originally launched, the
user group has expanded from a small singular department of users, to being an
organizational level report, through the championship effort of the business
user, multiple demonstrations that I and my team did not have to be involved in
(saving us hours of time and effort) and we have increased the demand for our
program to expand and receive additional resources to accommodate the
organization.
This type of model flies directly in the face of the
standard BI models, where our department would zealously hold onto control of
each of the objects, and we would build complex reporting to reach our business
users needs, and what we percieve them to be. We would then be required to
train and socialize each piece within the organization, and build up the demand
through elevator pitches, and multiple conversations both in person and
documented.
All of our reporting models have continued along the
same vein, and as such, our program has been able to grow internally with
minimal effort from our (very) small team.
Our next big step is going to be enacting governance
and mastering through similar means, and the greatest success I have seen so
far, is not that people are willing to work with us on this, but the fact that
some areas, upon seeing how their reporting looks, have actually come and demanded that we support them in
enacting governance, and master data management on their behalf.
As always, I am open to questions, feedback and to
hear how things are working in your own organizations!
Cheers!
SQL Doch
No comments:
Post a Comment