Managing, Maintaining and Developing Change
Getting from A to B is no simple thing, when it means altering what you do and how you do it. But it can be done, and done well.
Organisational change is always, by its nature, a challenging thing. You’re changing how work is done, but by dint of that, you’re also going to change the company’s culture. Changing what you do, how you do it, why you do it, and who does it, means you’re impacting pretty much everything. Even when each individual change is subtle.
This begs the question though, that if we’re optimising how our business runs, with regards to its usage of digital technologies and infrastructure, to better serve our customers, who’s going to manage that project and make sure it’s delivered effectively? At the minute, digital transformation tends to be farmed out to consultancies, who have responsibility for driving change. However, we often find that the timelines for this change are infeasibly short, and organisations view the end result as their being “fixed”, and over time, old habits start to creep back in.
There therefore needs to be an internal driver of continued, constant improvement and development. It’s this person and department’s Job to ensure that change is, whilst it’s being done, managed and developed effectively, and then maintained and continually developed into the future.
The challenge faced though, is that around half of all organisations say they don’t have the digitally capable talent they need to succeed in the future, and that this lack of capacity is hindering their attempts at transformation. Clearly then, if we think back to our hierarchy of an organisation, the functions and processes are going to stay fixed either in part or entirely, until an organisation either attracts talent capable of delivering in new ways, or upskills its people.
Both of these are unattractive options - bringing in new people will invariably lead to job losses as existing staff become replaced and fail to keep up, and upskilling requires staff to be willing to engage with new ways of working and learning how to use new technologies, and that’s always going to be subject to the willingness to change on behalf of the individuals concerned.
This gets even more concerning, when we consider that according to the Institute for the Future and Dell Technologies, 85% of the jobs available in 2030 don’t exist today. We’d question this number, but it’s certainly undeniable that the pace of change organisations experience is only going to accelerate, and become more disruptive.
So how do we go about tackling this?
Transformation & Project Management
Traditionally, the role of transforming an organisation has been given to the project management office (PMO). However, digital transformation necessarily means that more and more of an organisation’s employees become knowledge workers in some way, shape or form, and so the job of work has become decentralised.
The advantage of that is obvious - the work to change what and how work is done can be done in parallel across the organisation, rather than having to be done in one stream, which has obvious efficiency benefits. The challenge is managing what’s going on, making sure the change required is happening, and at the right pace, that no-one is getting left behind in the process, and that there’s visibility into what’s happening, so its results can be evaluated. However, it means that the PMO is becoming more about enablement than execution.
Thus much like UI optimisation, this means we need to start with a process for running transformation projects. Ours is similar to the process for UI optimisation - in this case it’s function and process analysis, challenge definition, initiative identification, measurement plan creation, and debriefing and communication.
Function and Process Analysis
The starting point is with the functions and processes of the business unit. What does it do, how does it do those things, and how does it combine those functions to develop outcomes?
Once this foundation is understood, we can go about looking for inefficiencies in these functions. At this point, we’re not looking at how we’re going to address them, but just noting where they are. What tends to bog down work? What consumes disproportionate numbers of people or time in its delivery? These are the things you want to find.
Challenge Definition
In our experience, the challenges found from the above, tend to boil down to one of four areas, in roughly this order of frequency:
- Lack of strategy, leadership, governance and buy-in
- Bottlenecks in technical implementation, due to complexity, legacy and/or IT capacity
- Cultural resistance, siloed organisational structures and skills deficit
- Limited understanding of the digital customer journey and touchpoint experiences
For the last, I hope we’ve done enough earlier in this document to give you an understanding of how to go about tackling touchpoint user interfaces. And we’ve covered a little on the first and second in our previous chapter. But let’s take a second to dig into the first three properly.
Strategy, Leadership, Governance and Buy-in
There’s a wonderful line from Battlestar Galactica:
not
I think there’s something analogous to what I see in the clients we work with. The soul and spirit of an organisation tends to reflect that of its leadership. In other words, what the people who run something believe and how they act, informs how the rest of the organisation will behave.
This means when it comes to digital leadership, there needs to be someone, and ideally the whole C-suite, bought in to the concept of digital enablement, and driving that change. That starts with a vision of what the organisation will look like in the future, and then orchestration of the organisation in order to deliver against that.
This is where the role of the CEO and/or CDO comes in. These people cannot deliver a transformed organisation through brute force, nor can they do it alone. Instead, they’re a conductor, delivering the vision and managing the implementation of it across the departmental heads. Digital programs inevitably (and this is a positive) bleed into every area of an organisation. Thus that process needs to be managed with that mind. In addition, the leaders chosen to help lead and govern this change need to have a digital mindset, with a facility for risk taking, a collaborative approach to work, and a relentless focus on the end users of an organisation’s products and services.
Technical Implementation Challenges
As we’ve said, DCXD challenges tend to fall into one of four categories - technical, UIs & their UX, and organisational. Of those, the second is easiest to change, the third is manageable, but hard, but the first? That’s where the work of fixing things tends to bog down the most.
The reasons for this are threefold:
- Organisations tend to run without large reserves of spare technical capacity. Technical hires are expensive, and so having the bandwidth for the team to be able to take on new projects alongside existing workload is rare.
- Teams tend to be skilled in specific technologies and processes, and the process of testing or implementing new features and processes can prove challenging, depending on what the existing technical base is.
- Often organisations are tied into their existing technological solutions, if only by the inertia created by the scale of challenge posed by platform migrations, to say nothing of contractual issues.
This creates a serious resistance to change, which is not unwarranted. It’s also why we tend to see the solutions to it being created by organisations going outside of themselves for help. Agencies can provide the bandwidth required, as well as open up avenues to different technologies which the organisation itself may not have experience in. However, the last issue, platform inertia, still remains.
No matter how you cut it, it’s never going to be an easy thing to move an organisation from one platform to another, partly due to the challenges involved in migrating data and UI design, and partly due to having to up-skill internally to support the new systems.
The best solution in the majority of cases is to migrate using internal resources where possible, and external where required, and then up-skill slowly. By using a framing and scoping exercise at the outset to define exactly what the new platform must do, and at the same time identifying key issues with the current solution, staff can be engaged with the process and excitement built around it. After all, any new platform should be introduced to tackle existing issues and provide a better experience for both employees and customers; that brighter future should be used as a carrot to entice employees to engage with the process and the eventual new platform.
Cultural Resistance and Siloed Thinking
This is perhaps the thorniest issue of the three. After all, one does not simply walk into Mordor, or change company culture. The challenges it poses are two-fold:
- Leadership tends not to think holistically in terms of digital enablement opportunities
- People tend to resist digitally focused initiatives as they are viewed as posing existential threat
In the case of the former, when we look at the initiatives organisations are undertaking, they tend to be highly focused on consumer-facing results, looking at product/service improvements, and marketing and distribution opportunities. However, they tend to exclude process and function opportunities, or supply chain improvement.
Whilst this is not to say that one can’t see strong results from focusing efforts at the consumer-facing end of an organisation, not looking at how the entire organisation can benefit from digital technologies and services is a huge missed opportunity. This is re-enforced by that the people in charge of these more back-end parts of an organisation tend to be the least interesting. For example, looking at ways of improving project management and integrating data systems can deliver strong benefits, but the ROI is harder to prove than CRO on a website, and the results will take far longer and lag other elements. That doesn’t mean it shouldn’t be done though - simply that it’s more challenging.
However, the outcome will always be seen in improved customer experience. If your organisation is better able to manage data, its day-to-day operations, or its supply chain and inventory, that’s always going to deliver improvements which a customer will be grateful for. Consider the case of Schuh which we mentioned back in the customer journey optimisation chapter for just one example.
Initiative Identification
In much the same way as with UI optimisation we form hypotheses and test them, one must identify paths forward based on the challenges faced at an organisation level, and test those solutions.
Far too often organisations identify a way to address a challenge, roll it out to everyone, and then find out whether or not it was successful. As far as possible, organisational changes should be tested with the simplest, smallest possible test first.
There’s a wonderful story from Google which inspired something called Project Oxygen, now known as re:Work. Believing that managers were essentially useless, Google decided to drop them all and see what happened. Somewhat predictably, everything went wrong pretty fast, so they reversed the decision and instead went on a now 11 year journey to try and find out what makes for productive teams and effective management.
A better way of doing that would have been to isolate one small group and remove their management. However, at least they had the sense to reverse the change. Too often, organisations roll out a change, and then plough on with it whether or not it was effective at meeting the challenge, or even deleterious to the organisation itself.
The second key to making sure the proposed initiatives can be successful is to ensure that the organisation is flexible, and operates as a collective of teams. In much the same way that good software is a series of discrete components which interact fluently with each other, allowing each to be optimised in isolation, the same should be true of an organisation. In both the technical architecture and governance, an organisation should be like a set of connecting, meshing cogs, not isolated silos, or intermingled webs. Teams should be small and as self-managing as possible. Equally, technologies must be capable of integration with each other, but given as small a scope as possible, to meet the needs of the specific group using it.
Of course, simply getting to this is often a project in and of itself, but even in a transition from an inefficient to an optimised structure can be done piece by piece, unpicking, re-platforming and refining each part as you progress.
Measurement Plan Creation
So you’ve taken a good hard look at your organisation and found some places you think could use some work. Now you’ve just got to find a way to measure what you’re doing.
It’s nice in the world of digital UI optimisation, where you can put up an A/B test, throw some traffic at it, and find out if it works rapidly. But in the world of organisational change, you can’t optimise something so easily. So how do we measure and track change, and then know whether something has worked or not?
Any program of change has to start by defining metrics and planning for measurement, which means:
- Understanding what success looks like, and
- Watching what people do
Too often we see changes being made without knowledge of the former, or observation of the latter. If you’ll permit a segue, there’s an old programming joke which illustrates the point nicely...
A quality assurance engineer walks into a bar. Orders a beer. Orders 0 beers. Orders 999999999 beers. Orders a lizard. Orders -1 beers. Orders sfdeljknesv. A customer walks in and asks for the bathroom. The bar bursts into flames.
When we’re planning our changes, we’re guessing what people will do based on our initial research. However, whilst those guesses are based on evidence, one must always be prepared for the possibility that the proposed solution, no matter how well reasoned and elegant, can be wrong.
So how do we measure and observe organisational changes? There’s various schools of thought on this, but we believe the most valuable is the one used by Amazon - long term adoption and simplicity. It’s easy to get a department to use a new platform which solves identified issues in the short term. However, do they still use it in three months? Has their time to complete tasks which took a long time actually shortened? Is the data they’re generating accessible by other elements in the organisation? Is leadership still pushing for adoption and usage? What’s the sentiment around the change made in the rest of the organisation?
It’s hard for us to tell you what you should be measuring, as it depends on what’s being changed. However, there’s almost always a set of simple, specific measurements which can be made and repeated over time, to ensure that the changes made have an impact, and to quantify whether that impact is positive or not.
And always remember, if you can’t measure something, you should be cautious when changing it. After all, if you can’t quantify whether the difference made by the change is good or bad, then you shouldn’t fiddle. A change which creates no measurable impact, isn’t a change.
Debriefing and Communication
In our final part of our organisation optimisation process, we must communicate results, both to the leaders of an organisation, and to the organisation at large. This serves two important functions:
- It lets leadership guide and course-correct effectively
- It shows the organisation progress being made, and ensures findings from missteps are passed on
There’s nothing wrong with tests which fail. It’s a fact of life; any time you start testing and optimising any system, you’re going to make changes which either do nothing, or impact negatively. But as long as you can measure and revert change rapidly, and your tests are isolated rather than affecting an entire organisation in one go, your failures won’t be expensive. On the flip side, your successes then have a template for rolling out to other areas, and you can move faster than the competition.
This is why communication is so important. Best practice should be shared internally, data should be made as available as possible, and leaders should be as informed as possible, to empower them to make the best decisions they can.