Listen to this article:
Over the next several weeks we’re going to dive back into Data Products. If you’re not already familiar with the concept, a refresher on the foundations of Data Products may be useful. Take a minute and check out some of my blog articles on the subject from the past couple years. Just click on the Data Products category. I’ll wait. … OK. Let’s continue.
When the conversation turns to Data Product Delivery, more often than not it starts with “the work”: identifying a domain, report, or KPI, developing a product charter, and assigning ownership. We dive straight into Phase Zero (because we’re all old C programmers). We have our deliverables lists and our RACI charts, and it’s all great stuff. The problem is that we’ve made an enormous assumption. One that is frequently incorrect. And one that results in the effort getting bogged down almost immediately.
Before beginning Phase Zero, you need to be sure that the enterprise is ready for Data Products.
Introducing Data Products into an enterprise is first and foremost a cultural change. It is not a project. It is the establishment of a new standard operating procedure.
Over time you will end up impacting most every part of the business and most every part of IT. Data Products are structured, intentionally if implemented properly, to be harder to ignore than the traditional cloistered Data Governance and Data & Analytics organizations. And let’s be honest, Data Governance and Data & Analytics organizations are too often ignored. That’s part of the problem.
But there’s good news! Someone at your company somewhere (maybe it’s you) has concluded that Data Products would be a good fit for the enterprise. Now, before launching into Phase Zero, there’s some preliminary work to do. Let’s call it:
Phase Negative One: Preparing the Enterprise
You might be convinced, but chances are nobody else is. Yet. That’s your key Phase Negative One task. The goal at the end of this phase is to have your first Data Product development team ready to begin. You’ll still be exercising the processes, so don’t go overboard on infrastructure. Of course, training will be required. Certainly for your partner teams, but also for yourself and for the enterprise more broadly. Not everybody needs to get down into the details at the outset, but a rudimentary understanding is necessary. Even for the executives. And speaking of executives, you absolutely need their support. After all, you’re going to be asking already overworked teams with often misaligned agendas to do something that they’re not already doing. Finally, to get that executive support you must have clarity of purpose and must be able to articulate the benefits and risks. Let’s look at these in more detail.
First Task: Vision
Your first objective is sales, and that’s going to take some homework on your part. You need to understand Data Products yourself. Take a class. Attend a seminar. Talk with others that are further along the journey on which you are now embarking. Next, prepare your pitch, and that requires above all else, clarity. Clarity about why the enterprise should be looking at Data Products in the first place. Clarity about the risks that they mitigate and the benefits that they will bring. Clarity about the roles of business, IT, and data teams, and their new standard operating procedures. Clarity about how the culture will change. Clarity about how the enterprise will function after you are successful. Where will investments need to be made? What is your elevator pitch? You won’t necessarily have all the implementation details yet, but you should be able to answer questions, anticipate objections, and prepare counter-arguments. You will be shepherding the organization, including the executives, and it will be clear whether or not you’ve done your homework.
Second Task: Get Your Executives On Board
It’s trite, I know. Pretty much every list of critical success factors for pretty much every project includes executive support. That’s probably because it’s true. In this case, it’s really true. Culture is established at the top, and the organization becomes a reflection of it. If your executives are not supportive of a Data Product culture, it’s not going to happen. You are looking to make standard operating procedure changes across the enterprise. Somebody is going to not want to do what you need for them to do. It’s inevitable. Their minds will need to be changed for them. (Actually, you’re asking them to do something that they’re already doing, but not very efficiently and they often don’t recognize that they are already doing it.) Getting the executives on board will likely require some convincing. Maybe a little. Maybe a lot. But you’re prepared and you’re clear. Your executives may also require a small amount of education. They don’t need to know the details of Data Product architecture styles. They do need a grounding in Data Product types. And they really need to understand the risks that are mitigated by Data Products. Benefits, too, and while they’re important they tend not to be as compelling at that level as risks. Frankly, if upper management is not supportive, it’s not worth doing.
Third Task: Education
Just as it’s important for your executives to have a cursory understanding of Data Products, the enterprise needs that same grounding. A common mental model and common understanding is required for you to be able to communicate clearly across the enterprise. In time, certain groups will require more advanced training, including the Data & Analytics team as well as the groups identified for the first implementations. But right now it doesn’t need to be super-comprehensive. Maybe an hour or two of introduction. DATAVERSITY offers Data Product training classes, but it doesn’t matter which curriculum you use as long as at the end of it you have a consistent vocabulary.
Fourth Task: Basic Infrastructure
When you’re preparing to develop your first Data Products, don’t get distracted by technology. It’s tempting (and admittedly fun) to do a whole tool evaluation and procurement project. Low-tech is fine for now. Use what you already have. (I’ll discuss in an upcoming article how this applies not only to technology, but also to process.) Remember, implementing Data Products is a cultural transformation much more than it is a technological transformation. Now, you do need some basic infrastructure, but it doesn’t have to be fancy. For example, store Foundational Data Product tables in a database or file system whose name is prefixed with DP. Put your Composed Data Products into a similarly designated PowerBI folder. Then, define your processes to ensure that only fully curated Data Products are placed in there. Incremental improvement will come over time, especially once you’ve delivered a few Data Products and have a better understanding of your needs. Then you can start looking at tools. For now, though, think of this like scaffolding at a construction site. It helps whatever it is get built and then it goes away. The point for now is to focus on the process, not the technology.
Fifth Task: Boilerplate Tasks (Agile or Waterfall)
One of the biggest mistakes that Data & Analytics organizations make when implementing Data Products (and Data Governance and Data Quality and …) is that they create a whole bunch of new stuff: processes, requirements, councils, meetings, approval flows, and more. And the overwhelming majority of this new stuff is independent of any existing stuff. It’s not surprising. How many times have you been told that, “You can require anything you want as long as it doesn’t impact my work.” You have your marching orders and you have Data Governance (or whatever) to deliver. Creating it all to operate independently is the path of least resistance and the approach that has the highest probability of delivery. But not the highest probability of success. The culture will resist and it will be ignored. Your objective is to take the specifics of Data Product implementation (I’ll talk about that in upcoming articles) and insert them into existing processes. If you’re using agile then create epics, user stories, and tasks. If you’re using waterfall, then insert them into the task list and phase gates.
Sixth Task: Identify a Pilot Project Partner
Be on the lookout for a sympathetic early adopter who not only understands but is enthusiastic about the prospect of implementing Data Products. If one doesn’t exist yet, keep looking. Doing something for the first time is always hard, and it’s hard nearly to the point of impossible if your partner is merely a grudging participant. Frankly, if you can’t find even one report or one KPI or one domain that is willing to work with you then it’s not worth doing. They’ll need to be patient, understanding that there will be bumps and hiccups. Even if you think you have everything worked out beforehand, something always comes up.
You’re now ready to start the pilot project where you’ll demonstrate and refine the Data Product development process. I’ll dive more deeply into that in upcoming articles. I don’t believe in throw-away pilot projects. Too often what starts as a throw-away pilot somehow turns into a production system; a half-baked production system. We’ve all been through too many of those. Do the first one right. Then do the next one better.
