Paul Jones: Data, Strategy, Innovation

In Part 3 of this series, I explained a bit more about how the answers to the high-level executive questions about data need to be compiled, to enable even more insightful steering of your enterprise data transformation initiative.  In this post, I continue the exploration of the “list-based” approach by explaining how to compile your list of systems. Please read my Disclaimer by clicking here. Why systems? Before going into how to compile your list of systems and how “OK” they are, some people may be wondering – why do you need a list of systems, if you’re trying to manage your data? This may seem obvious to some, but I’ve been challenged on this in the past, so it’s worth addressing up front. The answer is very simple: your systems contain your data.  If you don’t do anything with your systems, you are working in theory land.  You can spend as much time as you like on defining your metadata and agreeing data quality rules and all those lovely, data management...

In Part 2 of this series, I outlined the initial questions that senior management should ask to start to get a sense of the scope and scale of the work, so that they can start playing an effective steering role.  In Part 3, I’ll explain a bit more about how the answers to these high level questions need to be compiled, to enable even more insightful steering of the work.  I’m deliberately keeping this to data, systems and issues at this stage: more on how this approach can be used more widely in future posts.  This is where the “list-based” approach starts… Please read my Disclaimer by clicking here. Answering the executive questions: the list-based approach So, the executive-level questions have been asked.  How do you go about compiling the answers? In simple terms, by creating a set of lists, with clear status, priority and ownership against each item in the lists. This bit requires someone with a bit of data management knowledge to lead, if you want it...

In Part 1 of this series, I introduced the challenge that senior executives often face when trying to get a handle on large-scale data transformation initiatives.  In this post, I’ll outline the questions that senior management should ask to start to get a sense of the scope and scale of the work, so that they can start playing an effective steering role. Please read my Disclaimer by clicking here. The simple steering questions As a senior executive, what do you need to know about your data? This is where you should start: the all-important scoping and status tracking questions. Don’t worry about how your teams will work out the answers – we’ll get to that later.  The important thing for you at this stage is to start with the right questions, because they will help steer the actions of your teams in the right way, to get to the right outcomes. So, I would suggest that some good first questions, at a high level, could be: What data is in scope? How much of the i...

A common challenge for senior executives when sponsoring a large-scale data management initiative, is how to get a handle on just how much work there is to do, how long it will take and how much value it will drive.  In this series of posts, I'll introduce a simple approach to enable senior management to do just that, without needing to become data experts themselves.  I call it the “list-based” approach… Please read my Disclaimer by clicking here. Is it all just too big a problem? With an increasing number of laws and regulations forcing companies to make data management a Board-level priority, providing senior management with the mechanisms to understand the state of their data and enabling them to steer actions to manage it appropriately are imperative. More importantly, it is now increasingly widely recognised that businesses not only run on data, but can use their data to drive massive value.  The ability to leverage new digital services, Artificial Intellige...

In Part 4 of this series I explained that including details on “how” your Data Strategy will be achieved is critical to making it effective.  In this final post, I wrap-up the three most common mistakes and ask: what are the lessons we can take from them and how might you apply them to your Data Strategy, now? Please read my Disclaimer by clicking here. Bringing it all together In summary, the Top 3 Data Strategy Mistakes (and How To Avoid Them) are: Mistake #1: Unclear (or missing) Business Outcomes - Always start your Data Strategy with a clear articulation of what your Business is trying to achieve and map every recommendation to whatever those target outcomes are. Mistake #2: Unbalanced or Biased Capability Mix - Make sure the broad range of potential Data capabilities are considered and recommendations are aligned to Business Outcomes with clear rationale explored and explained. Mistake #3: Missing the "How" - The inclusion of practical steps to deliver t...

In Part 3 of this series I explained how a Data Strategy needs to be balanced and consider a variety of deliverables and capabilities in order to be most effective.  In this post, I explain the last of the three common mistakes in this series... Please read my Disclaimer by clicking here. Mistake #3: Missing the "How" A Strategy is a document that articulates how to get somewhere.  It is not just a Vision statement with no concept of how your Vision will be achieved.  Vision is important; and as described in Part 2 , must be linked to Business Outcomes.  However, a Strategy without some concept of the steps to achieving an end goal, is not really a Strategy at all. So this is the next obvious thing to look out for. Some Data Strategies are just pure theory.  They're really an elongated Vision statement, without any detail on a roadmap to getting to the described outcomes. Conversely, some Strategies are super-detailed plans; so, beware the opposite ...

In Part 2 of this series I explained that the first common mistake in writing a Data Strategy is being unclear on business outcomes.  In this post, I move onto common mistake number two… Please read my Disclaimer by clicking here. Mistake #2: Unbalanced or Biased Capability Mix The second mistake is another common one and manifests itself in several ways, often caused by the background of the Strategy’s author. Does your Data Strategy put a massive emphasis on governing and controlling your data, about legal and regulatory compliance and making sure Data Quality is at the centre of everything you do, without really explaining how doing this will drive any real value for your organisation? Is your Data Strategy super-focussed on Data Analytics and Insight, about creating new Data Lakes and Data Warehouses and Data Marts and doing whizzy new things with the Data, without referencing anything to do with how Data is captured and processed across your business before it reach...

In Part 1 of this series I outlined what a Data Strategy should generally consist of and suggested that spotting a good one is easy.  In this post, I introduce the first of three common mistakes, how to spot it and how to avoid it in order to deliver a better strategy. Please read my Disclaimer by clicking here. Mistake #1: Unclear (or missing) Business Outcomes The first, most glaringly obvious sign to look out for when reviewing a Data Strategy is where the Strategy's business outcomes are articulated. In the most extreme cases, I've read Data Strategies that talk a lot about the capabilities and structures and technologies that need to be deployed, without saying a single thing about why, or what these new things need to be put in place to achieve. If the Business Outcomes of your Strategy are not clearly articulated in its first few pages, then I'm afraid that I'd be willing to bet that your strategy is a dud, without even needing to read the rest of what...

A Data Strategy is a great way to set a clear direction and get the right people on board to sponsor and support the delivery of strategic change.  If you’re trying to do anything strategic with Data, then you’re going to need the support of senior management and are therefore going to need some kind of strategy or articulation of plans to gain their support.  In this series of posts, I present some tips on what a good Data Strategy should contain and then delve into some common mistakes that I’ve seen made when attempting to create a Data Strategy and how to avoid them. Please read my Disclaimer by clicking here. It’s easy to spot a great Data Strategy! I've seen a lot of Data Strategies over the years.  I've even written a few of them. The thing amazes me to this day, is how often the same mistakes are made, across various different types of businesses, of different sizes and different industries; with different aspirations and different organisational make-ups....

In Part 4 , I explained why data ownership is still needed and how Data Owners depend on the other roles to be really effective in fulfilling their obligations.  In this final part, I explain what Data Custodians and Data Stewards are; and wrap-up with a few suggested next steps. Please read my Disclaimer by clicking here. No data governance series would be complete without mentioning Data Custodians and Data Stewards.  To round this series off, here's a very brief explanation of these roles, linked back to some of the concepts that have been introduced in previous posts. Data Custodians – looking after the containers of data I tend to think of Data Custodians as anyone who looks after a "container" of data but doesn't touch the data in it themselves (unless specifically instructed as a technical action, rather than as a day-to-day responsibility).  By "container", I mean anything that stores data, such as a system or network folder or filing cabine...

In Part 3 , I introduced the concepts of Process Owners, Data Producers and Data Consumers; and explained how all these roles build on the same basic foundations of data responsibilities.  In part 4, I explain why data ownership is still needed once these other roles are in place and how Data Owners depend on the other roles to be really effective in fulfilling their obligations. Please read my Disclaimer by clicking here. Why do you need data ownership, when you've established all these other responsibilities and things? Whilst everything I've explained in the past 3 posts is useful and important to manage data effectively, in most organisations, especially large ones, the problems encountered with data are not found at an individual system or process level.  Instead, they manifest themselves in inconsistencies across multiple systems; or in the misuse of data in scenarios that the data was not originally captured for.  For example, if the same data in three system...

In Part 2 , I explained how data responsibilities extrapolate up an organisation and then introduced the concept of a Business System Owner and how such a role could be used in a very powerful way.  In part 3, I explain how Process Owners, Data Producers and Data Consumers all work as part of a wider set of data roles and responsibilities; and also explain why formalised “data ownership” may still be needed, after all of these other roles and responsibilities are in place. Please read my Disclaimer by clicking here. Process Owners - for completeness... Given that I've touched on Business System Owners, I thought it was important to address the concept of "process ownership" too, especially for organisations that already have such a role in place.  Moreover, even if you only have the concept of localised process ownership, if you consider that a process has a set of inputs, which will include data inputs; that a process then performs a set of tasks, which almost alwa...

In Part 1 of this series of posts, I introduced the basics about data responsibilities, starting from the very bottom of an organisation.  In summary, I explained that anyone who captures or processes data is responsible for it while it is in their possession.  In this part, I work up the organisational hierarchy and explain how these basic responsibilities naturally extrapolate upwards. Please read my Disclaimer by clicking here. One level up If you run a team, you are responsible for the conduct and performance of the individuals in your team.  This is a universal truth in most organisations following a standard management structure. As such, a team leader is responsible for the data that their team captures and processes.  If the team doesn't capture data they are supposed to, or captures invalid, inaccurate data, or mishandles it resulting in security breaches due to the actions that they have taken, the team leader is responsible, just as the individual...

Whilst I know many people have written articles on the topic of data responsibilities, in this series of posts I will present a slightly different and simpler spin on how responsibilities for data work in most organisations, plus a few pointers for things companies can do to make data management roles even more effective. Please read my Disclaimer by clicking here. The wonderful truth: establishing who is responsible for data is easy! It's really common for organisations to struggle with concepts such as "data ownership", "data stewardship", "data custodianship" and the like.  When these ideas are introduced, they are often met with resistance, especially when they are communicated as something "new" that need to be done in addition to people's "day jobs". The great thing is, working out who is responsible for data is extremely simple and is based on the fundamental way that any organisation works.  "Data ownership...