How to choose exactly the right data story for your audience

The importance of stakeholders

I've always written about data work from a stakeholder perspective. In business terms, a stakeholder is a person or group that has any sort of interest in the success or failure of a given initiative. It may be a person or group with a vested interest in seeing the initiative succeed, or it may be a person or group with a vested interest in seeing the initiative fail. In either case, we need to be aware of their interest and take appropriate action to enable the people who can help us succeed and forestall the people who might cause us to fail. As I explained in my first book [Building the Agile Database, Chapter 1], a business has many different groups of stakeholders (including customers, vendors, dealers, employees and shareholders). Even competitors and regulators should be considered stakeholders. Engaged in the right way, a competitor can become an ally; handled in the wrong way, a regulator can become an implacable (and expensive) enemy.

Learn more about this
book from Technics Publications

Stakeholder management is the key to success, both in business and in every other field of human endeavor. Companies that don't treat their employees right won't have skilled (and dedicated) labor. Companies that don't treat their resellers right won't see increased market share. Companies that don't treat their shareholders right won't have needed capital for growth and expansion. Companies that don't treat their vendors right won't get quality parts at a fair price, timely deliveries or good service. Companies that don't treat regulators right will see endless (and expensive) litigation. Conversely, stakeholders that are treated fairly will become allies in the company's success. As I've often said, you will be successful only to the extent that you can convince others to want you to succeed.

Data professionals need to heed this warning: There are too many people, both in business and in IT, who would rather fry eggs on their fingernails than listen to a data modeler drone on about normalization and standards and semantics and ontologies and the best sort of notation to use, all while ignoring the actual concerns of business and IT stakeholders who are trying to successfully complete a project or deploy an application. As I said before, the story isn't about us or what we need -- it's about our audience and what they need. We will be successful only insofar as we can make them successful; if we do not help them succeed, they will help us fail.

Types of data management stakeholders

So what are the stakeholder groups that we, as data professionals, need to interact with, and how can we respond effectively to their needs? Here is a list (not comprehensive or complete) of the people we most often work with on projects, the kinds of stories they prefer to tell, and how we can help them tell their stories:

• Business people are most comfortable with process stories (that is, stories about how a process is being done or ought to be done). Business users want to know what data entities and attributes are associated with a particular business process. For this group, a data flow diagram (DFD) is often helpful in showing the association between business processes and data entities. DFDs are also useful for exploring and asking questions about whether or how a business process can be changed or made more efficient.
• IT people (such as application developers) are most comfortable with functional stories (that is, stories about what needs to be done and why). Developers want to be sure that the data structures we model and implement adequately support their object classes, methods, and APIs. For this group, a UML activity or sequence diagram is useful for showing the flow of functional activities associated with the users of an application. These diagrams also surface entities that will be needed in the data model. From these diagrams, a UML class diagram is created, showing the object classes, their data properties, and their associated methods. The properties portion of a UML class diagram is roughly equivalent to a conceptual data model.
• Data analysts are usually concerned with business rules stories (that is, the rules or semantic definitions that constrain the values of data). They want to know that reporting and analytics based on application data will make sense to line-of-business users and will be correct enough to base business decision-making upon. A logical data model is the best fit for these requirements. I usually extract metadata from the data model into either a Word document (suitably formatted) or an Excel spreadsheet to make the metadata more easily understood by business users.
• Project managers deal in historical narratives ("Here's where we started from, here's how we got to where we are now, and here's what we need to do to get to where we want to be"). From a data perspective, what project managers are most interested in is the association between data entities and user stories; for example, "How many entities do we need to model and deploy to support these ten user stories?” I will often argue to project managers that a certain set of entities should be modeled because they are needed to support common user stories in upcoming sprints. It is a good idea, on Agile projects, for a data modeler to capture the associations of entities and attributes to user stories; this way, when user stories are dropped or changed, we will know what changes need to be made to the data model. I use user-defined properties (UDPs) in my data model to capture the associations between entities/attributes and user stories. Then I print out and report this metadata to the project manager, showing how an entity impacts/supports the user stories.
• Quality assurance (QA) analysts and testers are more concerned with individual battle stories than an overall war documentary. They want to ensure that the software being developed satisfies user requirements and provides a positive user experience. To this end, they develop and execute test cases based on the acceptance criteria of each user story. With QA people, I've found that it's very useful for them to understand the data model (especially the physical model), the primary key, alternate key(s) and other data attribute constraints, and the (foreign key) relationships between tables. This metadata can also be extracted from the data model into report form for easier consumption. QA people will also benefit from the sort of report described above, showing the association of entities and attributes (or, in this context, tables and columns) with user stories. This helps them be aware of what data to check for in the database after the execution of each test, and what sort of errors might occur in the database during testing.
• Management prefers tales of epic accomplishments, such as, "This is what we have been able to accomplish, against all odds." What management wants to hear is that everybody is doing what is necessary to make the project a success. What management does not want to hear is that the project will be delayed for three weeks because the project team can't agree on the data model or the database design. Always make sure that the story you tell management is the story of how your contributions are enabling higher-quality work to be done more quickly!

(There is a more comprehensive list of project stakeholders in my book, Building the Agile Database, pp. 30-32.)

In other words, data professionals need to understand what sort of story is being told by each group of project stakeholders, and they need to know how best to help them tell that story. At the same time, we data professionals need to know what sort of story we need to tell, and we need to know how to get the help we need from the other stakeholders to tell it. The story we want to tell together is how the project was a success, and our end customers were made happy and more productive. So, whatever we, as data professionals, can do to help our project stakeholders and team members be successful (while still adhering to good data management practices) is important and worthwhile work.

Communicating with stakeholders

As indicated above, each group of project stakeholders will see the project from a different point of view. Each has different arenas of expertise, different areas of concern and different requirements. The definition of success is different for each group, and we need to understand what success means to each of them. When communicating with stakeholders, we need to keep in mind the following questions:

• What knowledge and experience do they have? What is their point of view?
• What is their interest in this project? What are they hoping to accomplish?
• What are they contributing to this project?
• What do they need to be successful?
• How can I help them to be successful?
• How can I best engage their interest and participation in my data management activities?
• What sort of education or context do they need to understand what I'm trying to do?

The most important rule of communicating with stakeholders is: Let people tell their story. Too often, we talk over or around people because we're more interested in what we're trying to accomplish than in what they are trying to accomplish. But if we don't listen to what they're trying to tell us, we will miss important information, make invalid assumptions and go off in the wrong direction. This will lead, later on, to project defects and expensive rework. We need to redirect our focus to what our stakeholders (our customers) need to successfully obtain their necessary contributions to the success of our project.

At the same time, we also need to communicate clearly to our stakeholders what we, ourselves, need to be successful at what we are trying to do and convince them that helping us succeed will enable us to help them succeed as well. We need to explain -- and demonstrate -- to our project stakeholders that a well-defined data model will contribute material value to the success of the project:

• It will help everyone on the project understand the business data requirements of the project and the business rules that the data needs to adhere to.
• It will assist the project team when discussing requirements, elaborating user stories and discussing application architecture and design.
• It will expedite the work of designing, creating and refactoring database structures and other database objects.
• It will also expedite migrating data from legacy systems into the new application's data structures and identifying potential data-quality issues ahead of time.
• It will help the QA team create, execute and evaluate test cases for the application.
• It will assist business analysts who will want to do reporting and analytics on the application data after it's created.
• It will assist DBAs and application support people who will need to maintain and troubleshoot the application and database after production deployment.
• It will facilitate the reuse of this data in support of other projects and business initiatives.

A true story

For stakeholders who are not convinced of the value of a well-defined data model and database design, I like to relate a story that was told to me by my good friend and colleague John Giles, a skilled data practitioner and data vault expert (who credits this story to Graham Witt, an Australia-based data modeler).

A school district created a student records database for its schools but designed it with only a single set of address-related fields for each student (operating on the assumption that the parent or parents of each child lived at the same address as the child). They failed to consider that, in cases of divorce or separation, the parents might be living apart. They also failed to consider that, in cases of abuse, one parent might not want the other parent to know where they were living.

This faulty assumption enabled one man, a domestic abuser, to find the shelter where his estranged wife and child were staying.

This is the sort of concern that a skilled data practitioner could have surfaced early on during data modeling, and probably forestalled by asking the right sort of questions and by identifying (and challenging) assumptions. This is an example of the sort of value a skilled data practitioner can bring to a project.

The principal responsibility of a data practitioner is to make sure the data story is told right! And also to make sure the data story is understood by the other project stakeholders.