Relating the challenge of launching a new corporate process to a flywheel is a tired, overused metaphor. Probably because it so often applies. Like here.
It’s been hard getting started. Probably several false starts. Progress has been agonizingly slow. But now you’ve found a new ally. Hopefully several. They showed interest in working with you, allocated some time to pull together some definitions and expected content, and even got sign-off on the hour or two a week from their management. Maybe this time it will take off. The next step is yours:
Focus on consumption, seeking first to facilitate the work of the consumer.
When I was in college, I had the opportunity to participate in the Apple Macintosh II Seed Program. The school got a pre-release model of the Mac II, the first Macintosh with expansion slots, a separate monitor, and color video capabilities. Our job was to write applications for it. Like the previous Macintosh models, Mac II applications were built around asynchronous events and managers. Commonplace today, but at the time it was a revolutionary new programming concept. The introductory chapter of Inside Macintosh, the definitive developer resource, contained a section entitled “A Horse of a Different Color” that began:
On an innovative system like the Macintosh, programs don’t look quite the way they do on other systems. For example, instead of carrying out a sequence of steps in a predetermined order, your program is driven primarily by user actions (such as clicking and typing) whose order cannot be predicted. You’ll probably find that many of your preconceptions about how to write applications don’t apply here.
Seed Program participants from around the country assembled in Cupertino to learn how to write these applications. (No, we didn’t see Steve Jobs while we were there. He was not at Apple at the time.) The first speaker said something that remains in the forefront of my mind all these years later:
Providing a simple user experience is more complicated for the developer.
Too often we look to simplify our own work and then have the nerve to be surprised when our users don’t embrace the complicated or unintuitive solution we’ve presented to them.
Think obsessively about the user experience. Yes, give it that much attention. Create artifacts that serve your users and that make their jobs easier. Understand the questions that consumers will want to answer, when they will want to answer them, and the information they will need to answer them. Understand the details that development teams will have about new data, when those details will be available, and how that information will be used during development and testing. Recognize that information management is inherently tedious and try to make it as frictionless as possible.
Critically review your processes, especially those you’ve already implemented.
I’ve found that us data people also tend to be good at defining process. After all, we are detail-oriented. Yet, too often our attention returns inward and perfecting the process becomes the goal. We want the metadata and models and everything to be complete and accurate and reviewed and polished and tied up with a red bow before anybody else looks at them. We carefully map out every step, and each can be justified in the interest of metadata quality.
But would you want to use your processes? What if reimbursement or travel or procurement subjected you to processes like yours? Have your new friends review them. Would they use them? Are they intuitive? Do they answer the right questions? You may discover that you have to reevaluate the objectives of your processes if they conflict with your users’ needs.
One of the processes that may need to be revisited is the work product review.
Part of turning our focus outward is involving our new customers in our work product reviews. As I mentioned last time, any reviews that we’ve been doing have probably been for our own closed community. They probably involved stepping through a list of definitions or expected values or a data model projected onto the wall. This approach is not sustainable with our new audience. If we try to include them in those kinds of reviews, we’re going to lose them after the first meeting (if not sooner). We need a new way of communicating: storytelling.
Storytelling is the intersection of information, visualization, and narrative.
We have the information and visualization: the data elements or definitions or data models. We lack the narrative. The idea is not to gloss over the details, but to put them into a broader context. To establish a narrative thread that runs through the artifacts. Don’t just read definitions in isolation, relate them to their business purpose. Describe how they can be used to facilitate application integration and testing. It might be a little more work on our part, but it will greatly improve the customer experience. When done well, both you and your audience will have a deeper understanding of the content.
This article is not intended to be a primer on storytelling. There are myriad books, videos, and websites about storytelling with data. Although most are oriented toward reporting and business-side insights, the concepts can be applied to information management work products as well.
Data modeling is particularly suited for storytelling.
Many years ago, I worked with a data modeler who was brilliant at this. He would attend business requirements meetings and just listen. Occasionally he would draw some boxes, scribble some words, and connect up a few arrows. Eventually he would refer to his model and echo back a summary of the conversation. Something like, “So, each campaign can have multiple customers, but a single customer can only be part of one campaign at a time.” His interpretation would either be confirmed or corrected. If the latter, he would scribble out some part of the model, make the change, and try again. This would continue until the data model fully and accurately described the business scenario.
One of the greatest benefits of a data model is its use as a translation tool, allowing business and IT to communicate with precision in a way that is meaningful to both sides. Commercial software packages can translate a data model into a story, but it’s better if you do it for yourself for the time being. Don’t get distracted by tools. You’re making great progress and you’re so close to reaching the other side of the Data Chasm.
The key now is to make information management sustainable:
Incorporate information management (at minimum, expected content) into the application requirements.
This is your goal: partnering with your project management leadership and the business to make information management part of their standard operating procedures. Their processes, not yours. Leverage the value you’ve already demonstrated to secure support, especially from management.
It doesn’t matter whether you’re using waterfall or agile. Data modelers can sit with the business analysts as they develop the Business Requirements Specification. User Story acceptance criteria can be explicitly defined using data element expected content. You know your company’s processes. Engage your allies to help you find the best people to work with and the best places to plug in.
Equip your allies to articulate the benefits of information management to their teams.
It’s tempting for you to present the benefits yourself, but remember, to most everybody else you’re just somebody who parachuted in trying to make more work. Co-workers will have more credibility.
The point isn’t necessarily to create the task, “enter the expected content values into the metadata repository” (although that would be a good one), but rather to ensure that expected content is part of the test case definition so that later the details can be extracted and stored in the metadata repository (which, recall, might just be a set of well-organized spreadsheets on a SharePoint site). Eventually, and assuming you’ve designed your metadata repository for consumption, it will become easier to just put the details into the repository in the first place. But you need to make the barrier to adoption super-low.
I always make the following offer whenever I talk about information management to a project team: if you want to write the data element definitions in crayon on a napkin or whatever, I’ll type them into the repository. That’s how far you should be willing to go to facilitate the work of your customer.
Process integration completes your bridge across the Data Chasm. Maybe it’s just a rickety swinging rope bridge, but it’s a start.
And now may be the most precarious point of the whole journey.
You can begin taking advantage of some of the great resources that live on this side of the chasm, but please, please, please don’t rush headlong into new processes, deliverables, requirements, governance councils, and tools. Don’t neglect the connections that you worked so hard to establish.
You may want to use a framework like the DMBOK wheel as a roadmap for building out new information management capabilities, but focus expansion on the groups that are working with you. You don’t get bonus points for filling out all of the pie slices if they are not used (and we know what that feels like and we don’t want that to happen again). Keep doing everything you did to build the bridge. Continue to find and nurture new allies. Success begets success. Like a flywheel (there it is again).
Last week we celebrated the birthday of Martin Luther King, Jr. He concluded his 1960 Founder’s Day address at Spelman College with one of his most famous quotes, “If you can’t fly, run; if you can’t run, walk; if you can’t walk, crawl; but by all means keep moving.” This applies in so many areas of life. It applies here, too.
Never stop. Never lose focus. And in time that rope bridge will become a highway across the Data Chasm.
This is the final installment in a series of articles that explores the question of why we continue to see overwhelming numbers of analytics, artificial intelligence, machine learning, information management, and data warehouse project failures despite the equally overwhelming availability of resources, references, processes, SMEs, and tools…and what can be done about it.
