Deferred Ownership for Enhanced Engagement

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