The Fourth Industrial Revolution favours organisations that are able to completely transform from within, so many companies find themselves at a crossroads – looking one way at their desire to transform, and the other at an inability to execute on that bold vision.

Many of our customers understand the digital transformation imperative; it is necessary to fundamentally transform your organisation while delivering change incrementally. At the same time, these customers often tell us that their organisations are hampered by governance and financial accounting practices that actively hinder transformation efforts.

Historically, legacy technology transformation was delivered through ‘big bang’ projects and programs. Their supporting infrastructure – overly prescriptive business cases, multi-page gantt charts and onerous compliance reporting – lack the agility necessary to support the generational shift to products and services.

Let’s look at common execution roadblocks for agile product or services delivery and how they can be overcome:
 

A rigid business case prevents agility

Digital transformation will often require a business case of some description to secure capital funding, and overly prescriptive business cases that define the what and how of delivery are still common within many organisations we talk to. Agile delivery, focusing as it does on principles such as incremental, iterative delivery, is a less risky path than the milestone-based estimation model found in traditional business cases.
 

“Benefits cannot be comprehensively stated on creation of the business case. These are iterated along with the delivery.”

The key is to persuade executives within your organisation that the uncertainty around complete capital expenditure at the start of your journey is worth it, when considered in the benefits context of an agile business case.

An agile business case will:

• Be frequently updated through the delivery lifecycle as design assumptions are tested, discarded and tested again.

• Uncover which products or services need to be stopped or rethought as the iterative design process and grooming of the backlog unfolds.

• Loop user feedback into the business case on an ongoing basis – sprint playbacks by the delivery team are based on actual deployed software not a prototype, meaning there is an immediacy and increased value in that user feedback loop.

For the reasons listed above, benefits cannot be comprehensively stated on creation of the business case. These are iterated along with the delivery. However the big picture benefits vision should be laid out in the first iteration of this document. Agile delivery allows market hypotheses to be tested, refined and relaunched by an organisation, leading to improved benefits realisation.

Yes, business cases are often about predicting, as accurately as possible, future return on investment. A mindset shift though, from only considering an initial big decision to one of multiple decision points over a period of time, is helpful when supporting digital transformation initiatives and accurately quantifying your return on investment.
 

Strict hierarchical management structures block agility

Legacy transformation initiatives are historically governed under a strictly hierarchical model. Typically the immediate responsibility for delivery would sit with a Program Director, reporting to a Steering Committee which in turn carries the delegated authority of an Executive Sponsor, who holds the ultimate accountability for the program. Sounds convoluted and slow? That’s because it is.
 

“When an agile, multidisciplinary team hits its straps, it is important that the runway is cleared to the business as usual ICT teams.”

Agile delivery of products and/or services relies upon the delivery teams (or squads), who are empowered to make the decisions regarding delivery priority and cadence. These teams cross multiple business units and may not map to your organisational structure.

Some considerations when rolling out this structure into an organisations for the first time are:

• Keeping reporting methods and pathways brief: use playbacks as a way of keeping the senior leadership teams and other stakeholders across progress. Written status reports remain important for budget, and for risk and issue tracking, but the overall progress against plan is best measured through seeing frequent releases of functionality working as envisioned.

• The real strengths of the Steering Committee: their most valuable role is to concentrate on the business and benefits case iteration described above.

• The agility of the rest of the organisation should shape expectations: when an agile, multidisciplinary team hits its straps in terms of frequent, production-ready releases, it is important that the runway is cleared to the organisation's business as usual ICT teams. Difficulties will arise, for example, if an initiative relies on integration to legacy data sources that operate on a strict quarterly-release management calendar. In that scenario, if that schedule cannot be changed it is important to manage executive expectations of delivery schedules.

• Some hierarchy may still be necessary: because the teams are multidisciplinary, ensure there is an organisational mechanism for breaking deadlock should there be disagreement on prioritisation or backlog.

There’s no one way for every organisation to tackle digital transformation end to end, but the right atmosphere for transformational initiatives to flourish is strictly necessary – these changes to your organisation’s ways of working will pay dividends in the long term.

For more advice on executing a digital transformation in your business, download the Advisory Services e-book: Transforming business through strategic technical guidance today.