AGOV Talks About Summiting Mount OBI

Posted on by

Previous blogs introduced the technology and processes to climb the metaphoric Mount OBI. Communications was alluded to but more fully discussed in this blog as well as the various passes AGOV engaged in to reduce its OBI footprint by two-thirds.

An age appropriate (and beautifully restored) bug makes its way up the Grossglockner High Alpine Highway
An age appropriate (and beautifully restored) bug makes its way up the Grossglockner High Alpine Highway

AGOV’s efforts to reduce its fleet of OBI reports involved six phases. This blog covers steps 4 and 5 and briefing considers step 6.

  1. Understanding Mount OBI [this blog]
    • Death of Mount OBI [Optional blog, history and context of OBI]
    • Tagging [Optional blog, inventorying an Organization’s Reporting Fleet]
  2. Prepare the Environment and Data [TECHNOLOGY]
  3. Measuring Mount OBI: How Will the Objects be Evaluated? [PROCESS]
  4. Initiate Communications and Change Management [PEOPLE, this blog]
  5. Conduct Increasingly Focused Passes with sign off [PROCESS, this blog]
  6. Integrate into an overarching Data Governance Framework [GOVERNANCE, this blog]
  7. Note: the above blogs can be downloaded as a single PDF: AGOV Tackles Mount OBI.

Communications Strategy

Why Trust is Necessary to Climb Mount OBI

AGOV managed to de-commission two-thirds of its OBI-Dashboards and a corresponding number of pages and OBI-Objects. While the organization knew the time was nigh for a cleanup, communications and change management played a central role in the project’s success.

Business was wary of losing their cherished reports and hoarding was the default strategy. To overcome this, the IT Department sought to establish trust in the process starting with a communication strategy that outlined Messages, Mediums, and Audiences.

Messages

  • This is a business-driven activity; nothing will be removed or changed without approvals, but
  • Retention has a cost including clearly defined Owners, Descriptions, and an evaluation of each key OBI Objects.
  • OBI-Rationalization is a fair and transparent process co-designed between IT and the Business.

Message Mediums (channels)

  • A focus group of business owners was created and called ‘OBI-Champions’.
  • One individual was nominated from each significant business area. These OBI-Champions helped to design the process.
  • Handouts, FAQs, presentations, and other focused content about rationalization.
  • Twice-Weekly drop-in sessions to train on the tool(s), explain the processes and focus on critical details and facts.
  • Emails and established web pages.
  • Senior management communication and support.

Audience – Actions

  • Senior management, buy in for the process and support.
  • OBI-Champions, agreeing to playing an ad hoc role and work within their respective Departments.
  • Report-Consumers, awareness of the project and the role of the OBI-Champions.
  • Organization, awareness and prioritization.

Climbing Mount OBI One Pass at a Time

Climbing real mountains is sometimes a multi-day or longer affair. Base Camp, and Stage-Camps are necessary for the long trek to the summit [1]. Mount OBI is no different although with a twist. The following stages start at the metaphorical top (Dashboards) and then descends through the Page and Object levels.

Just like climbing a significant mountain, however, adequate preparation is key. Finally, after ‘conquering’ Mount OBI, it will be time to consider how to preserve the efforts – so you don’t have to climb the DANG MOUNTAIN Again!

Passes or Review, Review and Review

A series of reviews or OBI-Passes were developed by the IT Department. These were communicated, modified, and confirmed with the OBI-Champions:

  1. Initialization: This was done by the IT Department. This gave the review team a good ‘feel’ for the data and allowed for a few different experiments in how to collect and organize the information. A series of SharePoint Lists were used, one each for each Dashboard, Pages, and OBI-Objects. Usage statistics were applied to the OBI-Objects as available.
  2. Mapping Pass: To reduce the burden on the OBI-Champions, an Initialization Pass completed the quantification attributes for the OBI-Objects. A QDIRF Log tracked issues.
  3. Dashboard Pass: Starting at the top of Mount OBI, the OBI-Champions reviewed the Dashboards and updated the quantification attributes. The qualification and ‘So-What’ attributes for Dashboards were optional for this initial pass.
  4. Page Pass: Moving down Mount OBI, the OBI-Champions reviewed the pages. Attributes from the Dashboard level cascaded down to the pages as the starting point.
  5. Report (Analyses) Pass: This final pass was optional and considered the individual Reports. OBI Reports can also be run directly resulting in some usage values not tied to a Dashboard/Page – this is the ‘Ledge of Direct Usage’ of Mount OBI.
  6. Sign Off: To close the project, the OBI-Champions revisited each of the levels (Dashboard, Pages, etc.) and signed off OBI-Objects. This provided project-closure and reduced the risk that a Dashboard (etc.) might get inadvertently archived (or preserved).
  7. Updating Mount OBI for Future Visitors: Now the actual work could begin including:
    • Hiding as a Deletion Strategy: Dashboards marked for eventual deletion were initially hidden. Hiding a Dashboard less than a minute to implement whereas deleting it would require a thorough (and very tedious) review of the constituent parts.
    • Tagging and Inventorying: One of the challenges of OBI is that there is not an easily referenced ‘asset-tag’ for the components. An unique identifier requires the combination of multiple fields (e.g. Folder + Name + Object-type). A tag was applied to the OBI Objects to aid in future identification.

Beyond the Mount-OBI

AGOV engaged in the above activities to prepare for a transition away from OBI. Even if this was not the case, the review helped to identify for eventual deletion about two-thirds of the OBI-Fleet. It also solidified ownership on the part of business. Hopefully, this is not a one-time affair and to this end, the following are recommended future activities:

Keeping the Proto-Report Catalog Up to Date

  • Expand the Proto-Report Catalog: created to support a review of OBI, the structures can easily accommodate other data visualization/reporting technologies.
  • Annual Ownership Confirmation: new business requests are accepted only after the report catalog entries have been re-confirmed by the respective Department manager.
  • Data Owners and Stewards: annual update with staff turnover.
  • New Reports: described first in the Report Catalog and THEN Built
  • Change requests: production deployment requires the sign-off of any report catalog entries.

Beyond the Proto-Report Catalog

  • Improve Container, Content, Governance, and Process: continuous improvement of the managing this data asset, ideally in the context of a data governance framework.

Conclusion

If your organization already has a sophisticated way to manage its data and things like its report or dashboard fleet – good for you and congratulations. If the lessons for the fictional AGOV Corporation seem daunting and beyond your organization’s abilities, hopefully you can take on even a portion of the above series of steps. Heck, how about just a list of a the REALLY good reports?

As always, let me know your thoughts and experiences in climbing your own ‘Mount OBI’!

References and Further Reading

  1. How to Climb Mount Everest (with Pictures) – wikiHow
  2. http://www.eiminstitute.org/library/eimi-archives/volume-1-issue-13-march-2008-edition/a-rose-by-any-other-name-2013-titles-in-data-governance.

This blog series is about a public sector organization ‘AGOV’; a fictional mash up of recent experience, past knowledge, and research. I like to blog to remember, and a good memory device is to tell a story. A story always works better with sympathetic characters, such as AGOV.

Leave a comment