When you try your best but you don’t succeed; it’s strategy that you want but not what you need…
We thought we’d switch to a bit of Indie-Brit-Pop plagiarism for this blog, considering it relates to fixing things. In our previous blog, we covered the first two pain points experienced by businesses implementing their strategy for data. (In our opinion, anyway!) Today, we’ll finish the set… (more opinioning…)
The story so far. Businesses struggle to deliver on data strategy because they fail to provide a compelling, detail-based narrative. They also don’t explain the resulting value. This translates to stakeholders not understanding the imperative for change. Which in turn leads to a lack of collaboration and co-ordination.
TOM helps to resolve these issues by providing the detail and an achievable plan of action—the TOM package capability changes along with the arguments needed to convince and align stakeholders.
Now, to continue the story. What are those pesky behaviours lurking that may undermine the success of your strategy?
We promise we will learn from our mistakes… not…
Ever worked on projects where you ask: “Can you show me how it currently works and what the issues are?” To hit a wall of blank looks and tumbleweed? In our experience, this happens more often than not.
As the world moved to Agile, it also seems to have moved to being low documentation. Agile practitioners seem more fixated on delivering solutions than understanding existing problems. Whilst we are all for the speed and flexibility of agile delivery, the adoption of agile results in projects failing to audit the current data operating model and don’t pinpoint existing pain points that cause problems today. And it’s not that Agile can’t accommodate this activity. For some reason, it’s increasingly seen as not valuable time and effort.
Even if you could design a ‘new’ TOM in this way, how do you show a roadmap getting you from today’s world to the future utopia?
“Not a problem, we’ll circle back on it when we need to!” we hear this all too often. The problem is, you needed to know this before you started work on the solution. Key stakeholders need a credible design based on reality… not a punt on a wing and a prayer. Understanding “the current” is not a waste of time and effort.
In reality, there should always be a working view of the Operating Model. Codified and accessible as a reference resource, modified and corrected as change delivers within the organisation. If not, development of a new TOM is the perfect time to get it in place and the disciplines around maintaining it. It’ll save you a lot of time, overall.
And the final issue?
Well, data develops as a new data operating model silo within the business. This is where all inward-looking strategies end up in terms of their implementation. The specialist silo perpetuates regardless of best intentions on data literacy and better embedded data. And being siloed, ever growing volumes of newly keen data users are driven towards “front door” entry points, with data having to deal with ever building queues as users attempt to gain access to their vital data assets. Backlogs and workload prioritisation abound.
Specialist data analytics remains divorced from the business. The business continues to suffer due to opaque engagement, prioritisation, miscommunication, and misinterpretation. Data becomes a fortress besieged with risk-based governance to protect everyone and everything. None of these are good outcomes.
Target Operating Model will guide you home…
TOM helps in both areas. Because TOM isn’t a one-dimensional document. It’s not a one-trick-pony that exclusively talks about the future. It goes into the detail of activity value chains that deliver outcomes. It talks about the capabilities and organisational components needed to underpin success. It also sets out the context of those changes in what happens today.
To do TOM properly, your starting point should be the Current Operating Model. You gain insight on existing structures and the strengths and weaknesses of the business, its value delivery mechanisms, and resourcing model. Knowledge is power, always. And it’s enormously powerful to be able brief a stakeholder with pin-point specificity on the pain they experience. “It’s analysed. We can fix you! We know the steps, costs, and risks.” TOM provides both the blueprint and the roadmap. It shows the destination contextualised in the current. It grounds everyone in the same reality.
Data is not just for the data geeks, everyone needs to be literate, everyone needs to take ownership of it. There’s a standardised way to define data. Data is a common feature in all areas of any business. TOM isn’t just capability, it’s culture.
TOM helps to lay down that common approach to the management of data across the business. It should be a single approach to governance. There’s a single data classification approach. There’s a common data model everyone in the business uses. There should be an alignment to common standards. It should be the prescriptive detail that sits behind the more abstract business strategy for data.
Data is not a silo…. It’s the circulatory system of the business. It’s the system through which critical information is communicated. It’s what provides the insight to make eyes-wide-open decisions. It provides the content to help defend the business against commercial and regulatory threats. Data needs to be connected into the organisation. Not its own organisation within the business.
Focusing time and effort on development of a Target Operating Model that builds out the operational reality of your strategy is the way to fix you.
Alex Guy is a Senior Data Architect at Oakland
