Building the digital backbone for transformation

by Ray Cooke on 29/07/2016 10:00

Building-Digital-Backbone-Transformation.jpg

Your organisation may be looking to go through digital transformation. And by digital transformation I’m not talking about a routine project to automate a current manual process, but fundamental change to the way you deliver value to your customers or community through disruptive technologies such as social, mobile, analytics, cloud and internet of things (SMACIT).

It may be that these technologies provide an opportunity to deliver a better customer experience, adopt a more competitive business model and/or disrupt your market. Or it may be that you must transform or be rendered irrelevant by new market participants who better meet customer expectations through convenient digitally enabled business models.

Digital transformation may be strategically important, but your organisation must also be able to deliver this change or the strategy is simply academic. Building that capability, the digital backbone, for transformation is the focus of this blog post.

MIT Center for Information Systems Research (CISR) findings show that creating a powerful digital services backbone to facilitate rapid innovation and responsiveness is key to successfully executing on a digital strategy.

Is your organisation ready to deliver digital transformation?

The way that you have delivered change in your organisation in the past may not be suitable for delivering digital transformation today.

Planned change is not responsive enough for transformation

While many organisations are adopting modern Agile and Scrum approaches, our experience is that these approaches are often nested in organisational structures that focus on planned and waterfall style change.

Do any of the following examples apply in your organisation?

  • Structured and dated plans of milestones and deliverables still exist
  • Requirements documents are written and signed off before change begins
  • Teams are organised by function (e.g. PMs, BAs, architects, developers, testers)
  • PMs manage adherence to plans
  • Vendors are pinned to delivery of agreed functional milestones for fixed payments
  • A formal change request process is in place and change is agreed somewhat infrequently by a steering committee
  • Testing happens at the end
  • Software and other changes are released every 3 months or even less frequently.

I’m not saying that these approaches are wrong. If you need to roll out Office 365 and this requirement is unlikely to change then these types of approaches may be very suitable.

Digital transformation however is a different beast. Do you know today exactly what your customers will expect or your market will demand in 6, 12, 18, or 24 months?

If you plan in detail your digital transformation today, based on what you expect your customers and market will want, and then deliver it through a rigid, unchanging waterfall approach, it will be irrelevant when you deliver in 2-years’ time.

You need change that is highly responsive

If you look at the Cynefin Framework we would describe the types of change, that a digital transformation would enable an organisation to respond to, as complex. That is, the effects of the change cannot be predicted; they can only tied to cause in retrospect.

Complex change requires more of an experimental mind-set rather than a planned mind-set. It requires frequent cycles of delivery, monitoring results, accommodating changing needs, and responding. It needs to be highly responsive.

I would expect organisations that can respond to complex change to have these types of artefacts and behaviours:

  • A backlog of high-level requirements that are regularly being re-prioritised
  • Teams that are cross-functional and team members who are multi-disciplinary, preferably co-located together
  • Transparent and visual mechanisms to see the flow of work through the team
  • Business representatives (e.g. Product Owners) within delivery teams with the mandate to make immediate functionality and priority decisions on behalf of the organisation
  • Team members responsible for adherence to approach rather than adherence to a plan (e.g. Scrum Masters)
  • Short delivery cycles, sprints or iterations (1-4 weeks) or continuous
  • Software and other changes delivered frequently, in some cases perhaps many times per day.

The methodologies and practices that work in this way include Agile, Scrum, Kanban, DevOps, Continuous Delivery and others. Note though, that it is not enough to have project teams delivering using these approaches, the organisational structure must also change so that these teams are not forced back into waterfall delivery due to external obligations to deliver plans, requirements, change requests etc.

Building the capability to transform

Some organisations are already delivering projects using responsive approaches, and these organisations are in much better shape to deliver on digital transformation initiatives.

Organisations who do not have truly responsive approaches to change, including organisations who describe their projects as Agile but wrap them in onerous structured obligations, will first need to build their change capability as part of their digital backbone before undertaking digital transformation. This is essential, but won’t be easy.

At a high level, this is what I would do to build this capability:

  • Work with a coach who has been part of successful Agile delivery teams (note, I would avoid coaches who have read the book and advised but never delivered within an Agile team as the real value of a coach comes from their experience).
  • Introduce the Agile mind-set and practices into a one or two projects, learn the lessons, monitor, do more of what works and less of what doesn’t and continuously improve.
  • Restructure your IT and delivery functions to support and enable your delivery teams to work unconstrained in Agile and responsive ways. You will want to think about how to avoid functional silos, what role your PMO now needs to play, removing project steering groups, allocating empowered business representation to delivery teams and so forth.
  • Roll out your proven Agile approach, that has been continuously improved, to all of your projects that deal with unpredictable change.
  • Prove this new structure and approach works on standard business change projects and then begin working on your digital transformation projects.

Obviously each one of the above bullets is a significant amount of work on its own and there are many details to consider for each, which I don’t have scope to cover in this post.

Start building your digital backbone for transformation today

You may already be looking at digital transformation, and if not then it may just be a matter of time before you have to.

Your previous delivery approaches may not be suited to digital transformation and your organisational structures may restrict you from being sufficiently responsive to the changing needs of today’s world.

Start building your digital backbone for transformation today, so that you have the required muscle to change and be responsive to the expectations and needs of a rapidly changing digital world.

If you don’t start today it may be too late when you really need it.

You may also wish to read this article The role of IT in the digital transformation of New Zealand organisations.

Ray Cooke is a Lean and Agile business transformation coach, based in Equinox IT’s Wellington, New Zealand office.

Recorded webinar: The 'edges' of Scrum - Addressing project management concerns on Agile projects, view the free webinar now.

0 Comments

Get blog posts by email