Agile Enterprise Part 3 - Experiences Enabled by Platforms
Earlier in this series on the Agile Enterprise I talked about two of the operating model changes needed to foster agility. Part 1 covered whether or not organisation structure change is needed for technology and change teams, and Part 2 talked about moving away from project-based funding and towards an envelope funding model. In this article I’ll explore how to group change into long-running, cross-functional agile delivery teams. Delivery teams built around Experiences and Platforms as the enduring foundations for an agile delivery model.
Structuring large portfolios of change has never been easy.
If you’ve been involved in delivering large scale change using a traditional project and program model, then you’ll no doubt have experienced one or more of the following challenges that tend to arise:
- Under-estimated or under-scoped projects running over budget or over schedule
- Under-delivery of benefits or very slow take-up delaying benefits
- Cross-project interdependencies creating unplanned scope or schedule change
- Quality issues with delivered solutions causing cost and performance issues for impacted business teams
- Contention for business and technology change windows forcing unplanned delays
- Challenges finding and retaining the right people with the right skills to deliver
- Benefits overlap and tracking issues with multiple initiatives changing the same process or function, and
- I could go on for a couple of pages with this list!
Organising large volumes of change into logical programs and projects of work, then wrapping all these projects with the appropriate governance needed to control all the issues and risks listed above, has always been a challenge. Many executives fear large change programs for a good reason. They are hard.
The key question is, yes change is inherently difficult, but is there something about the way we’ve been executing change that makes it harder than it needs to be?
Experiences and Platforms are enduring foundations for change.
I make no claim that by simply reorganising your change portfolio into Experience and Platform groups, all the issues and challenges listed above will magically disappear. Rather I’m suggesting that when we create long-running, cross-functional change teams, as opposed to transient project teams, we are creating a fit-for-purpose delivery model that will be far more effective at handling all the issues and risks listed above.
I am currently seeing long running, cross-functional, agile delivery teams outperform transient project teams for a variety of reasons including:
- Long-running teams can learn and continuously improve whereas transient teams disband after delivery making it hard to capture and implement learnings,
- Long running teams can be better measured over time
- Long running teams can be held accountable much more easily than temporary project teams, but probably most importantly…
- Governance can be built into long running teams as opposed to being wrapped around projects.
Now if you’re going to go to all the trouble to establish these teams, build in governance mechanisms, create new measurement systems, etc, it makes sense to create the most enduring groupings possible. This is where the Experiences and Platforms come in and let’s start with the most important experience, the Customer Experience.
When we group change around the customer experiences that matter for our organisation we create a delivery structure which, almost by definition, is enduring.
A slight aside here: the concept of a “customer” in this context can be substituted with a “citizen” for Government organisations, a “donor” or “beneficiary” for Not-for-Profits, a “student” and/or “parent” in the Education sector, a “patient” in Health Care, etc. The important thing is to identify the people who matter when it comes to the experience they have dealing with your organisation and which you plan to change.
Take a bank for example. A decade ago one of the most important customer experiences in banking was buying and moving into a home. Today it’s still one of the most critical customer experiences. A decade into the future it will likely remain a critical customer experience, irrespective of how many structural changes have been made inside the bank, or how many product features, pricing changes or new offers have been launched to market over that time. Therefore buying and moving into a home would be a good candidate customer experience for a bank to consider when selecting its experience groupings.
What are the right customer experiences for your organisation? Unfortunately there are no “cookie cutter” models I’ve yet found for identifying the right experiences for each organisation, which is where help from those who’ve done it before can be useful. The key principle is to select experiences that help your organisation focus on the right customers, and on what matters to those customers.
Now to Platforms. Once established, I’ve found the customer experience teams to be good at prioritising and then delivering the direct benefit driving features. However, prioritising and delivering non-functional platform activities like upgrades, cyber security improvements, resilience improvements, etc can still be hard, especially for platforms that are shared across many customer experiences. It is therefore necessary to complement the hard benefit driving experience teams with funding envelopes, and usually also teams, for each of the Enabling Platforms so that those platforms can sustainably do what they need to do.
To optimise the performance of long running, cross functional, agile change teams, the change work needs to be broken down into enduring groups. The customer experiences that matter and the platforms that enable those experiences are the way I recommend approaching it so as to sustainably focus on the people that matter the most to your organisation. There isn’t a “cookie cutter” model or spreadsheet that will pop out the customer experiences and platforms groupings that are right for your organisation, so be prepared to put in a little time and effort figuring it out and don’t be alarmed if after 6 or 12 months it needs a bit of fine tuning.
If you need help with your operating model for agile change feel free to reach out to me on firstname.lastname@example.org.
About the author: David Boyle’s IT career over 30 years spans both the buy side and sell side of technology services. He’s worked with Accenture, EY, Commonwealth Bank of Australia and until recently was the Group CIO at NAB. David is now the Managing Director of CAP2ITS, a technology advisory firm focusing on technology strategy, performance and risk.