The incompletable jigsaw: part three

While there’s no hard and fast formula for developing a strategic initiative as important as a digital strategy, here’s how the journey developed at RoS.

  • Embrace the concept, understand the conceptThe executive management team recognised the importance of digital transformation and what it could give; the board was similarly engaged and supportive. Both of these governance groups were fully behind it but, more importantly, they understood it. This was more significant than blindly following the ‘digital first’ principle.
  • Appoint the right peopleTrying to undertake digital transformation without experienced heads leading the way is a dangerous path to follow. RoS appointed Tom Meade – who had an impressive track record in digital transformation – as digital director, and he’s been able to bring his considerable experience, insight and energy to RoS.
  • Create the core programme teamOutsourcing digital transformation completely is not a sound approach for creating a sustainable, supportable programme that will deliver continued value. Tom built an experienced core team consisting of enterprise architects, business analysts, agile professionals, developers and testers to supplement the existing developers, PMO, product owners, UX and UI teams in RoS. To create the capacity, larger strands of the transformation was outsourced to specialist systems integrators for areas like case management and GIS (spatial mapping). The systems integrators are working on site at RoS’ offices alongside the existing teams. This gives continuity and a cohesive approach.
  • Let the enterprise architects and business analysts do their thingThe essence of a digital strategy is knowing what to change. This is where good business analysts and enterprise architects will study the business and figure out what can be achieved. How to change it is arguably less important, as that’s more a mechanical function of problem solving steps. The business analysis process is something like the diagram below:

    Diagram of business analysis process

  • Cost itWhile not being bound by cost as part of the ‘iron triangle’ of project management, there still needs to be a ball park for how much capital finance such an undertaking will need, and when that capital is likely to be needed for cash flow forecasting (the business case and the value derived can be worked on separately).

    This led to two separate, full-day workshops for 14 people estimating everything from people, contractors and equipment, to software, SI, desk space, accommodation, and other overheads. This was apportioned over an estimated ‘sliding’ timeline of when strands of digital transformation were predicted to start, and hence a total budget and cash flow was determined. This has since changed a number of times as you’d expect with a large programme.

  • Vision to realityThe result of all the analysis and costing is, of course, a strategy document and presentation which was made to the executive management team and board. In true agile fashion, iteration one (or maybe the way in which it was revealed) perhaps did not have quite the impact expected. The feedback received was used to fuel iteration two, which was universally well received and supported, and resulted in the initiation of the digital transformation programme.
  • Adopt agileSoftware development in RoS had habitually been by a ‘waterfall’ approach, while the support of the entire ICT infrastructure by the IT services department had been loosely set up on ITIL principles. A huge shift in ethos was needed to be able to deliver (and, in the long term, support) a digital transformation programme.

    The solution was to engage an agile coaching and mentoring company to work with teams in the ICT department over many months to lead and foster the adoption of agile techniques. In its most rudimentary form, agile is realised by scrum in the development teams, and by kanban in the service and support teams. Retrospectives, daily stand-ups, show and tells, feedback, CFD, value, flow, and quality are all terms are techniques now in regular use.

  • Build capabilityThe move to digital is more than ‘just’ developing some software. Any change requires more resource to give headroom to implement successfully, but there is a much wider spectrum of areas that will need addressing:
Skills New technology will mean new skills. Do your people have them? RoS created a skills matrix and developed a far-reaching training plan to last two years.
Supportability You need to be able to support what you build at all levels. Bridging the gap between third parties, service desk, and development teams allowed us push towards a DevOps environment, ensuring whoever codes something also supports it.
Automation To maintain velocity and ensure the DevOps teams would be as efficient as possible, automation in provisioning new environments and testing, as well as self-service, are still being developed and refined, dramatically reducing deployment time.
Cloud strategy Digital products rely on cloud as a platform in the main. Are you on public cloud? Do you have a private cloud? And if not, how will you get there? Devising our cloud strategy was one of the most challenging aspects of our digital strategy.
Blend of full time staff vs contactor vs systems integrator Due to the sheer size and scale of the digital transformation project, coupled with the length of time it was going to take to upskill internal staff, a hybrid approach to resourcing the programme was the correct decision. Contractors give us ready-made experience and technical skill, as well as temporary capacity. A systems integrator gives us specialist skills and additional ‘on tap’ capacity. Full time staff give us stability and their involvement ensures that there will be ongoing skills for supportability and future product refinement once minimum viable product is achieved.
Technical direction The legacy hardware and software estate in RoS was fairly daunting in that it sprawled across many vendors; a classic case of many architects with no overlap and so no real joined up approach. A technical design authority was commissioned to bring control and direction to future technology choices.

A technology register was created to define what technologies were strategic, which were tactical, which were contained, and what could be retired.

Rationalisation and consolidation of technology Once the cloud strategy and technology register were agreed, the culling of existing hardware and software was undertaken to prepare the estate properly for the technological change that was starting to be realised. This included retiring older hardware and software, re-platforming onto preferred (mostly open source) operating systems and middleware, and performing product upgrades where necessary.
  • PrioritisationIn any programme of change, there will be a number of concurrent strands with their own DevOps teams delivering. But which work takes priority? Work streams have unique values to the business; some are overlapping and some are dependent on others. Determining the cost of delay and then prioritising to ensure maximum business value is returned is quite involved.

    A dedicated prioritisation forum was set up to handle this, ensuring that the programme delivered change in the best way, using various metrics and the six prisms of value, risk, stakeholder, urgency, geography and necessity as pointers in decision making.

  • Accept that the digital strategy will changeIt has been called out a number of times in this blog series that change to the programme is inevitable, and so the programme needs to be flexible enough to change. Already, external factors have influenced RoS’ programme, which started with six separate work streams and now has seven.

    You need to be able to refine/redefine the strategy at suitable points. Be flexible with the feedback cycle to trigger iterations of the strategy. Any change will, of course, have a knock-on effect to prioritisation, and so the prioritisation forum has to be similarly flexible to assess the ongoing business priorities and re-align effort to deliver best business benefit.

Validation and governance

It goes without saying that a successful Digital Strategy will get and enjoy support from all levels. That support is easier to obtain and retain if it can be demonstrated that the strategy:

  • has been validated by other sources, either entirely on in part (e.g. Gartner)
  • was consultative in its creation
  • was benchmarked against, or is not dissimilar to, other similar agencies or organisation
  • used feedback to iterate and hence make it as robust as possible

The incomplete jigsaw

RoS’ digital strategy can be illustrated as in incomplete jigsaw that may never be quite complete due to constantly changing parameters and discovery of new issues and opportunities. But if you have the right people involved and strong leadership at the top of the organisation, it will result in tremendous value being unlocked, driving transformational change.

Cloud workspace elements

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.