Lately there’s been quite a bit of talk about how an organization could - or should - implement a data strategy. One insightful example is a recent post from IBM providing a “six-step approach”.
A number of times in the past I have pointed out that I have seen many companies implement data strategies only to have them stalled or even abandoned soon after its inauguration. One main reason for this is that companies often let the strategy “deteriorate” by not maintaining it; yet I believe that the main cause of shelving a data strategy is that it was never an actionable one. That is, the adopted strategy did not produce a roadmap that was easily understandable, presenting logical units of work that could be aligned on and therefore was difficult to win funding and garner (and maintain) support from the organization.
To avoid this pitfall, you should keep several best practice concepts in mind as you begin formulating and evolving your data strategy. This will help ensure that ultimately the data strategy is an actionable one and can be supported both initially and on-going by key stakeholders. These concepts include:
Isn’t it Obvious?
With objectivity in mind, take the time to identify, assess and address any obvious disagreements or other related problems within your organization before heading into Data strategy development. For example, there could be strong opinions about (Data) platform alternatives, architectural approaches for Data integration, or even what the specific business priorities (or “reason”) for developing a Data strategy may be. To be successful, your Data strategy will need to resolve these issues, or these issues may limit the success of the data strategy or even be its reason for failing.
Divide and Conquer
Breaking complexity down into smaller (and smaller) less complex “pieces” is a proven approach to problem solving. It is advised that your Data strategy divide all work into workable units that can be simply executed, have an obvious correct and measurable result and therefore will have a higher probability of being funded within the culture of your company, since ROI will be easy to show. Another advantage of using this “break it down” approach is that once you have identified individual units of work, you may be able to assimilate some of these “units” into an existing project or even accomplish them within an existing operating budget.
There may be temptation to “font-load” your data strategy. In other words, during development of the data strategy, you may find that there are a large number of “immediate needs”, “wants” and “must haves” from a variety of areas within the organization. Even if all these requests are legitimate, experience has proven that trying to address everything, all at once, almost guarantees failure. The strategy must accept how fast an organization can implement a data strategy and then specify a plan with this reality in mind. Otherwise, the data strategy will set unreasonable expectations; thus, undermining credibility and causing loss of support. To avoid this, sort the requests into categories, then prioritize and reference them in a roadmap targeting them within a later phase with a realistic timeframe. This keeps stakeholders engaged, even if their request isn’t planned for immediate delivery or even in the first year. The bottom line is that everything cannot all be done all at the same time so strategically place deliverables and accomplishments across a realistic timeline and the odds of success will be better.
Seldom are an organization’s Data issues resolved by simply replacing a current product or tool that is already in use. Typically, what ends up happening is that the same challenges – delayed delivery, security, or quality – remain even after implementing (perhaps) the latest or most popular Data tool or technology (usually at a significant cost). To prevent this kind of scenario, try focusing on process improvement first utilizing the tools already in place, and only after you feel comfortable that things are operating as efficiently as reasonably possible, should you consider addressing any gaps between “have” and “need” with new technology.
An organization’s CEO or more likely the CIO usually will take responsibility for initiating and owning the data strategy. In today’s business landscape your organization should have a CDO (Chief Data Officer) who creates the data strategy vision and then leads its development and execution. If your organization does not currently have a dedicated CDO, appointing or hiring one is strongly encouraged before beginning the data strategy discussions. A CDO should be the resource responsible for enterprise-wide governance and utilization of information as an asset and should have proven experience in this space.
What’s in it for Me?
If the technology group is spearheading the creation of the data strategy, more often than not the strategy will be defined using technological terms with objectives related to that group. For example, it may list an objective as “controlling costs of data storage” by defining the specific type of storage to be used. Although this is a sensible goal for the IT group, it may not be an objective that a typical business executive will find valuable or even interesting. Data strategies need to get the business excited by listing items such as addressing a business pain point, improving overall system performance, or expanding analytical capabilities. Finally, the strategy needs to be communicated in such a way so as to state a clear and understandable business value so that the business will be more likely to fund and support the effort.
No matter the size or complexity of your organization, a well-planned and actionable data strategy will improve the chances of creating a successful organization-wide data culture.