In previous chapters I have covered the importance of timelines, waymarkers and articulating realistic goals as the critical focal points to have constantly in your mind whilst defining a data strategy. This is not just because these represent good practice in any major undertaking that needs a plan. In my experience, strategies have failed to be adopted or implemented, or have simply stalled, because these aspects were not thought through extensively enough in the preparatory stages and through the defining of the data strategy.

In many cases, those who define the data strategy and those who are tasked with implementing it may be two completely different sets of people. This might seem odd, but it can arise for a number of perfectly rational reasons. The timescale of pulling together a data strategy may be long, it might be driven by someone with a particular skillset or level of knowledge and experience, or it might be seen to be an activity which sits in different parts of an organisation. As a result, whether through individuals moving on, either within the organisation or leaving it altogether, retirement, how roles are tightly defined or the use of consultant or contractor resources to help drive the data strategy definition, the end-to-end process of data strategy definition can pass through many hands before getting to see the light of approval and moving into implementation.

It is worth reflecting on what this means. A data strategy needs to be owned corporately, not individually, to avoid the risk of work becoming lost or misunderstood as it passes through different hands, and so has to have the appropriate rigour in place to mitigate such risks.

Just as importantly, senior stakeholders are likely to change in the time it takes to get the concept of a data strategy agreed and it being ready for approval. This includes the sponsor, who may be the main advocate and why the data strategy is being pursued in the first place, and so the risk of such a change must be factored in to the thinking to minimise the risk of change.

Why do I explain this at a point in the book focused on creating a route map? Simply because your route begins from the very start, the first discussions that take place on why the organisation is interested in having a data strategy and what that means in reality. Documenting the starting point, the assumptions, the key stakeholders, and the time and resources available to deliver the data strategy is one of the most important tasks you undertake to ensure continuity is maintained in the subsequent phases through to implementation.

It is easy to reflect in hindsight what the starting point of the data strategy looked like, but the lens through which you look back is never quite the same as the one which gives greater clarity in real time. The lineage that links the concept of the data strategy through to its implementation will be invaluable to:

• future groups of people who are tasked with coordinating and communicating it through delivery;
• stakeholders to provide a common understanding of intent;
• those tasked with implementing various elements of it to provide what it was seeking to achieve.

Reality might dictate that this too evolves; nothing stays static and so the initial thinking might be at best only partly relevant as time moves on. However, capturing how thinking is evolving, and reflecting on the drivers behind why change has occurred, keeps all parties aligned and focused on what is to be achieved, when and why.

The purpose of this chapter, therefore, is to set out some key steps to be undertaken as you embark on planning the stages of the data strategy. There will be a series of deliverables and an assumption of progress to be made, given the data strategy will be time limited, whether to three, five, ten or any other number of years. The role of the data strategy is to illustrate a likely path to achieving data goals and to ensure there is linkage between it and the corporate strategy in terms of timing.

5.1 VISIONARY MEETS REALISM – HOW TO KEEP IT GROUNDED

I have previously made the point that there are two common failures with data strategies that lead to their becoming either shelfware or forgotten, and that is a lack of realism, or practical application to the current starting point, in terms of what it lays out as the vision to be delivered through the data strategy, and a lack of keeping it simple, or grounded in that reality.

It seems obvious to state that a data strategy must be followed by an implementation plan, which may set out the first year or longer, but if it is in any way unclear as to what is to be achieved, the implementation plan lacks a clear picture of where it needs to head or the pace at which it needs to progress. I have seen two polar opposites in this situation: the data strategy so aloof that it is far from clear as to what is to be achieved, where the organisation is starting from or any concept of steps along a continuum; and the data strategy that is so steeped in the detail, and devoid of the vision to set out the what, why and when over the longer time frame, that is has become an implementation plan and not a strategy at all.

These scenarios may seem avoidable, but it is remarkably common to find efforts to define a data strategy drifting one way or the other and, once on the wrong track, the drift increases and it becomes impossible to correct it. It is often the culture of the organisation too that determines such outcomes. There is a tendency for highly operationally focused organisations to want to get into the detail and fail to see the merits in something as visionary as a strategy. On the other hand, those organisations that are steeped in a culture of strategy and policy are more comfortable exploring the possibilities and therefore likely to be focused on a more theoretical perspective that can sometimes be a little detached from the practicalities of implementation.

These descriptions are extremes, and most organisations will fall somewhere in between on the spectrum, but it is worth considering what sort of organisation you are defining a data strategy within to spot any risks of being steered one way or the other.

If I return to the CLEAR principles outlined in Chapter 2, ‘execution’ is at the centre of the acronym, which is a neat reminder that it is important not to leave consideration of implementation until the end – it is at the heart of being CLEAR. As you develop the data strategy, utilising Agile to develop it iteratively, bear in mind the question ‘How would I approach executing this?’ If the answer is in any way unclear, ambiguous or simply too complex to comprehend, then a further iteration or two is likely required. A data strategy which is unclear as to how it can be executed is of no value whatsoever, and brings the concept into disrepute for the next person who is tasked with reviving the notion of creating a data strategy in that organisation.

So, what would an effective data strategy in terms of realism and being grounded entail? I recommend setting out clearly at the start a summary of what the data strategy is for, how it is to be utilised and how it will be measured (in terms of success). This introduction sets the scene for what follows, and as long as these clear principles are kept in mind when the data strategy is reviewed, then the reader should be on the same wavelength as the author.

The next step is to set out the structure of the data strategy, which is covered in more detail in the next chapter. For the moment, the structure has to aid the reader by having a logical flow to it, one which will translate effectively into a plan, coherent and cohesive in linking the key deliverables in the data strategy in an easy to understand manner that interlinks with all other relevant parts of the strategy. At no time should the reader have to interpret dependencies and associations within the data strategy – it is your job to provide the clarity of a meaningful narrative from start to finish within it.

The data strategy itself has to be clear in terms of content, providing definition if there is any doubt as to the interpretation that the reader may place upon any of it (a key challenge in the iterative shaping of the data strategy is to test out meaning and understanding, to iron out any risk of inconsistencies or lack of understanding in the drafting process). It must provide parameters, guides within which the individual or team responsible for its delivery into an implementation plan can have a consistent understanding of what is to be done, by when, for the bigger objectives along the way – the waymarkers that signal the way to delivering the vision of the data strategy.

If, at the end of drafting the data strategy, it is not clear to someone outside the close-knit group who have worked on defining and drafting it how to turn it into an implementation plan, then the process has failed. No matter how positive the reviews of the data strategy itself, the sense of achievement of having completed it, the praise that has been given following its presentation, an inability to execute the data strategy is failure. There is little to be gained from having a tick in the box only to see the data strategy fail to leave the starting blocks.

Therefore, find someone with deep implementation expertise and co-opt them onto your review group, but use them very sparingly. Bear in mind that you don’t want them to go rogue and become too close to the subject to continue to provide implementation objectivity. Once you have finished final reviews of sections or elements of the data strategy, invite the implementation expert in and let them seek to interpret what is required of them without prompting – the more you influence their thinking, the more it undermines the capability of the data strategy to stand for itself. If they need clarification, guidance or further descriptions, or simply do not understand whole sections of it, take it at face value and work with it. Remember, keeping it simple and comprehensible is a key guide in this process, and your expert’s feedback is invaluable in sharpening up that particular premise.

5.2 WHAT ARE YOUR TIMESCALES?

It continues to amaze me that many strategies – not just data strategies – seem to overlook any concept of timing in terms of the deliverables that are in scope. There may be some broad statement about the timescales being a three-, five- or ten-year strategy, with seldom any variation on these three options. That is not to say that these are wrong, but they are the commonly chosen periods despite the world seemingly changing at an ever faster pace. I am always bemused by a strategy for a decade and question the validity of its assumptions, given that we seem to move into a recession or similar major disruptive event roughly every ten years, and fast-moving technology is one of the biggest disruptors to major organisations operating in traditional sectors. But does a ten-year strategy reflect this fast-moving dynamic effectively? I’d suggest not, but that’s another debate.

There are also far too many instances of organisations that leave devising a strategy to beyond the last minute and then start the period it is intended to cover with a ‘best endeavours’ attitude that morphs into an implementation plan of sorts, with the strategy never quite catching up. Unsurprisingly, this approach is destined to fail, typically quickly, on occasion before the strategy has even been completed. However, it is not uncommon for the lack of a strategy to be determined to be the cause of the problem, rather than the lack of planning. Do not find yourself falling into this trap.

The question remains of how long your data strategy should be, and it is a valid one. If you have a choice, I support keeping it to three years (see below). If you do not, then you have to align with corporate guidance that determines how long strategies should be for, though of course if this is the first time your organisation has had a data strategy you may need to work in line with the strategic cycle in play. In other words, your organisation may choose to work to a five-year planning cycle and have set periods defined for those five years that all strategies align to.

If you are delivering your data strategy in the midst of one of these periods you may need to fall into line: for example a five-year strategy might be 2021–2026, yet you are not going to complete yours till 2022. In such an instance, you might have to cover the period to 2026, thus delivering a data strategy which is for no more than four years in the first instance till you can realign with the usual planning cycle in 2026. In some cases, the standard rule in an organisation may be to have strategies of a fixed period – say five years – but not anchored by a fixed planning cycle.

Whatever the case in your organisation, it is important to know what the situation is before embarking on defining your data strategy. There is little to be gained developing a three-year strategy only to find it had to cover five years when presented.

I am a keen advocate of a principle of rolling strategies, which unfortunately seem to be relatively rare in the arena of planning cycles and fixed periods. I often recommend developing a three-year data strategy which is then a rolling strategy, learning from the experience gained in year one, monitoring its effectiveness against waymarkers within the data strategy and shaping what would have been year four as the ‘new’ year three.

One of the challenges in this approach is the rigour required to assess progress and provide confidence that the remaining two years of data strategy are still as valid before appending a new year three. However, I see this as a useful calibration between the implementation plan – which is usually developed on a yearly cycle – and the data strategy, to test the ambition of the data strategy: was it realistic, did unforeseen obstacles prevent progress, how robust was the thinking on dependencies and the assumptions made at the outset?

By using this iterative approach to continue to run with a three-year rolling data strategy, continuity is maintained, a view can be taken as to whether the data strategy is ambitious enough or overreaching in its goals, and the fourth year is incorporated at a lower risk than starting afresh with a new three-year plan at the end of the current data strategy. It is also less time-consuming to do this, both for the area of the organisation leading on it but also for those who contribute to its compilation in one way or another.

What differentiates it being right to set a course for a longer time frame from instances where a shorter time frame would be more appropriate?

In sectors where there is long-term stability, a need for major investment which takes long planning cycles and less volatility in the market, there is a case to be made to plan over longer-term horizons. This might be the case in major infrastructure environments such as the nuclear, rail or road industries for instance. In these sectors, it is easier to plan due to stability, based on the knowledge that there is an expectation that major change tends to take significant time to achieve. This may be less pertinent to a data strategy but, conversely, if funding is available to make a significant transition (should that be appropriate) it enables a long-term view to be taken on the breadth of what can be achieved.

Shorter timescales are more appropriate for highly volatile sectors, which may be due to the impact of technology, new entrants (many of which may, due to the rapid evolution of technology, trade solely as online businesses in an otherwise bricks and mortar sector), the pace of product evolution and the volatility in the market itself (at a time of recession or other economic upheaval, planning for the long term might seem fanciful if survival in the short term is the priority). Reasoning for shorter timescales could be a combination of all of these factors, of course. However, the pace of change is growing, the role of technology in our businesses is increasing (AI is a significant factor for many organisations at the moment and in the near future), and adjusting to change requires agility and adaptability on a scale not previously seen.

Where your organisation sits on the strategy timescale may even be changing, as there is a recognition that the ‘old’ ways of operating are no longer relevant to a faster-moving world. It could be that the data strategy is a catalyst to bring change to the thinking of your organisation, and I would certainly recommend putting a greater focus into the first three years of your data strategy simply because most strategies will become less relevant as we move beyond that period.

If you can get the first three years close to being reflective of reality, then you are truly a master at defining and delivering a data strategy. Revisiting the strategy for the years beyond the first three is both likely and responsible, as no sensible organisation would sign off on a strategy longer than three years and not conduct some sort of review ahead of year four. Such uncritical faith in the author having correctly predicted the outcomes not only of the organisation’s own performance but also the dynamic of the market would be entirely misplaced.

5.3 WAYMARKERS RATHER THAN MILESTONES

I would hope that you have got the principle that there is a difference between a data strategy and an implementation plan by this stage. You will also have seen that I use the term ‘waymarkers’ rather than ‘milestones’, a term you may have heard more commonly.

If you wonder why I have used waymarkers to refer to points at a future time when you would expect the organisation to have achieved various elements outlined in the data strategy, it is because these are descriptors of what the organisation should look like, from a data perspective, rather than a specific deliverable.

The data strategy is intentionally a guide, a portrayal of what the journey the reader is about to embark on looks like, with some clear pointers and descriptors of things to be achieved along the way. It is a mix of the tangible and intangible, describing clear and measurable things to be achieved during implementation, but also outlining what this means for the culture of the organisation, the nature of changes to be implemented and how this move to a more data-led way of working will operate.

Waymarkers are intended to indicate key moments in time, points at which the organisation will look and/or feel different, and to provide an outline of what has been achieved at that point to recognise the extent of the change achieved. They thus bring together the physical and measurable activities, which in an implementation plan would be recognisable as milestones, and link with the intangible to show how the organisation has evolved to exploit these and other things which have successfully moved the organisation forward in its wider goals.

As I said earlier, the data strategy has to be measurable, and it is via the waymarkers that this is achieved. The waymarkers are an informed crystal ball into the future, outlining to the best knowledge available when the data strategy was defined what the organisation is expected to look like through the lens of the data strategy. Their purpose is to provide clarity of what the combination of tangible and intangible brings, how that morphs into one joined-up view (as reality is a combination of the two) and sets a sense of purpose in defining the implementation plan through a richer picture of what is to be achieved. They set the context, define the pace and broaden the implementation from a purely tangibly driven plan into one which has the wider scope of delivering cultural change and wider organisational impact embedded within it.

Rather like the stars by which a ship might navigate, the waymarkers appear periodically and are used to ensure the course remains consistent with achieving arrival at the intended destination. The navigator does not discount using landmarks along the way to assist where possible, and can correlate between land and stars even if both are not visible at the same time. However, the data strategy acts as the night sky, a reliable indicator for the navigator to use the stars as waymarkers on the journey but still with the ability to adjust and adapt should tides and currents dictate slightly different tactics in navigating to the same end destination.

5.4 PLANNING FOR SUCCESS

It has been stressed throughout the book that the implementation of the data strategy stands apart as a discrete phase of the overall process, yet it is essential that the data strategy is devised and defined with the execution of it in mind. Failure to do so will run the risk of the data strategy failing to be fit for purpose and the effort in defining it having been wasted.

I mentioned earlier in this chapter that I would strongly recommend having someone with a strong implementation background involved as a slightly detached critical friend of the data strategy drafting process. This objectivity is really important to ensure that the transition from data strategy to implementation plan is as simple and coherent as possible, avoiding ambiguity that can lead to divergence and drift from the original intent simply through misunderstanding. In many ways, it is the transition from an approved data strategy into implementation that carries the biggest risk, though for those engaged in the data strategy drafting process there is a tendency to focus on the approval itself as the end goal and the major hurdle.

The first step to aid the planning process is the clarity of the baseline position within the organisation. I have explained the importance of this elsewhere, but to reiterate: if there is a lack of understanding of what the starting point is, then there is almost certainly a risk of assumptions being made which later are found to be incorrect and a flawed understanding of the landscape in which the plan needs to function – this is especially true when it comes to the intangible elements that the plan needs to capture, such as the cultural shift that may form part of the data strategy.

All too often, data strategies focus on the end goal and miss the importance of establishing a common understanding of the baseline. This is essential in order to get agreement across the organisation on the scale of the task to be undertaken and the measures to be put in place.

Once there is a clear understanding of the baseline, and appropriate measurement in place to capture the starting position, it is feasible to begin to define the objectives within the data strategy and set out the waymarkers. In the same manner, taking the baseline and defined measures, the planning team can set out the goals and milestones for the period of the implementation plan, which is likely to be a twelve-month plan with a less detailed view beyond, possibly to reflect the length of period that the data strategy encompasses. These activities are separate, though an effective data strategy definition process takes account of the task of implementing it to make the translation from strategy to execution a relatively easy one.

The data strategy will be a multi-year strategy, as outlined in this chapter. As such, it needs to provide a balanced view of that period, identifying how the layers of activity in the years in question build to deliver a more advanced organisation in terms of data and its exploitation and compliance. It is a common trap to focus heavily on the more immediate period of the strategy, say the first year, and be less detailed on subsequent years. This is a risk simply because those involved with defining the data strategy will almost certainly be more familiar with the shorter-term view and less confident in defining the activities in the years beyond.

The reason I highlight this is that, with a multi-year strategy, there is a need to assure those who are signing off on the data strategy that the vision beyond what would form an immediate delivery plan will support the corporate strategy and deliver longer-term benefits. This is where the data strategy waymarkers demonstrate the outcomes in a descriptive and engaging way to secure the investment needed to underpin the whole implementation programme. If there is an imbalance towards the short term, it suggests that those closest to the data strategy do not have the vision themselves; this would lead to a more short-term view of investing for the year ahead through the usual budget round and planning process rather than committing to a longer-term strategy.

In addition, a lack of detail for subsequent years makes the task of implementation much harder. If the data strategy in year one already resembles an implementation plan, but years two and beyond are so lacking in detail to be vague and uncertain, then the risk is that the implementation plan for those years is either lacking or determines the strategy: in other words, the plan is the strategy due to the absence of detail and meaningful waymarkers.

The longer the period the data strategy covers, the harder it is to determine the emerging landscape due to both external influencers and internal factors. However, the waymarkers simply need to define a picture of the time in question, and the key changes from one period to another, to make it evident as to what has to be achieved – tangible and intangible – from one point in time to the next one. Therefore, be prepared to define the detail in terms of significant outcomes the further out you go, especially beyond three years, but paint the picture with sufficient detail that those who come to implement it can see how it has evolved from the previous waymarker and the contributory elements that have enabled progress to be made. Also, don’t be afraid to make the waymarkers more spaced out as you move through the years – years one and two are likely to be quarterly, year three may be quarterly or half-yearly, and years four and beyond are almost certainly half-yearly moving to annually.

5.5 PRESENTING THE ROUTE MAP

The route map can take a number of forms, from a simple timeline with a series of boxes against the relevant points in time to explain the key outputs expected to have been delivered by that point, through a complex project plan format that displays interconnections between deliverables to show how these come together. No particular format is right or wrong; as with so much in the strategy space, what your organisation is used to and comfortable in relating to is likely to be influential. There is no point in making it too complicated when the essence of the route map is to keep it simple and high level – remember this is the data strategy, not the implementation plan.

The choice of style may also be one of personal preference – what you feel comfortable with, as you are likely to be at the forefront of presenting it to a wide range of stakeholders. There is also the limitation of the tools available, though this is becoming less challenging as tools become much easier to access via cloud-based platforms such as Office 365, Google Workspace and Apple iWork.

Whilst I do not want to limit your enthusiasm, or artistic flair, the most common ways of presenting a route map are as follows.

• Gantt chart – named after Henry Gantt, who designed it in the early years of the last century, this method has become a standard for project schedules and milestone tracking to this day. A standard bar chart, it is easy to create, is readily accessible to most audiences who will also be familiar with this form of presentation and can convey a lot of information relatively easily. Downsides of a Gantt chart include its oversimplification, and it is more challenging for the strategy implementation when complexities in resource management, dependency tracking and the need to operate at sub-task level can make operating via a Gantt chart more of a limitation than a help.
• Flow diagram – often portrayed as a journey map – a visualisation that shows how actions against a timeline lead to outcomes, often with a narrative of what each of those points on the journey look like. It works well visually, as it is in keeping with the concept of a route map, but it can be challenging to see how the strands come together, or to track any dependencies along the way. It can also be seen as prescriptive, presenting one route only and suggesting there is no alternative, when the data strategy route map is intended to be indicative of, rather than constraining, the implementation.
• Radial grid – often referred to as a sun ray diagram – this starts out with a common topic or a vision, which could be the data strategy in this instance, or the end state following the implementation of the data strategy, and then has branches radiating out that contain deliverables over a timeline, showing a level of building on each other. It can be challenging to comprehend the necessity of delivering all of the items in the sun ray versus the impact if there is a delay, as the grid does not illustrate the dependencies between the radials very effectively. However, it is a constructive way to convey a volume of information in a clear and defined approach that is generally easy to follow.
• Projectmap – a recent development which has been devised by an Israeli start-up called Proggio.² This tool is focused on revolutionising the project management space, replacing the need for Gantt charts by presenting a highly visual representation of your project that enables dependencies to be tracked and reporting to be delivered from within the tool. It can also be presented as a Kanban board (a visual depiction of work at all stages of the process using cards to represent tasks and activities) for use in Agile delivery, and it integrates with Jira, for those organisations that use this tool to manage tasks and epics also in Agile delivery.

Remember that the purpose of the route map is twofold: it needs to inform the key stakeholders who need to buy in to the data strategy and have an appreciation for what it is going to deliver, whilst understanding what is required to make this happen; and it must be a guide to the implementation team who have to turn the waymarkers in your data strategy into a plan that can be executed in a way that remains true to the goals, and therefore the value, outlined in the data strategy.

5.6 TEN TO TAKE AWAY

To summarise, key points from this chapter:

1. Design the data strategy with implementation in mind. Think about how you would act if you were to be given the data strategy and asked to implement it – would it be clear in terms of the baseline, direction, outcomes and what success looks like? Use a critical friend to challenge.
2. Test understanding through an independent reviewer to ensure the data strategy is clear and achievable. It is valuable to have an external party to those defining it to provide friendly challenge to the content.
3. A timeline is essential in your data strategy. Without this, the implementation is challenging, as expectations of pace and any perceived flow of activities are unclear.
4. Consider a rolling strategy, enabling the learning from the period covered and the evolving nature of the organisation to be reflected in adding a subsequent year on an annual basis.
5. Set waymarkers rather than milestones. Guide the execution: it is not a straightjacket. The data strategy must avoid becoming an implementation plan.
6. Ensure the data strategy is measurable and that this can be reflected in the implementation plan. The baseline must be clearly articulated, so there is a clear understanding of what has been measured to retain consistency into execution.
7. Waymarkers may be uneven in both their content and frequency in the data strategy. This is inevitable, so do not create them unnecessarily as it is understandable that the clarity of detail is probably greater earlier in the period the data strategy covers and at a higher level the further out it goes.
8. However, balance out the data strategy to avoid it looking like a year one implementation plan with a strategy bolted on for subsequent years. It needs to be consistent in being a strategy.
9. Reflect on how best to provide a route map, utilising approaches which are known to have worked in similar situations. Familiarity removes a potential barrier that something novel might create. The purpose of the route map is to convey visually what the data strategy will provide, so you want it to be easy to reach agreement.
10. The route map must be able to convince key stakeholders that this is what they want and expect to be able to reach agreement. Make it easy for them to comprehend what they will be getting.

1 H.S. Judd, How to Play Golf the Easy Way. New York: Harper & Row, 1980.

2 https://www.proggio.com/.