Fomenting Revolution
Last night Emily read the old Aesop’s fable about the tortoise and the hare to her child. The tortoise, weary of the hare’s boasting about how fast he runs, challenges him to a race. The hare – overconfident in his speed – lies down for a nap, and the tortoise wins the race.
Afterwards, Emily wonders whether we really believe the fable’s message. Do we behave like the tortoise, or like the hare? Which is better? We forget the lesson of the fable. In real life, we shift our focus too quickly and put our minds to sleep rather too often. This is true in business projects and large IT investments, as much as in our personal lives.
The tortoise knows what it needs to do and the pattern of work that it needs to employ to reach the finish line. The hare stops for a sleep and jumps around from one thing to another, turning its attention to anything shiny and interesting. It is easily distracted from the journey and the ultimate goal of beating the tortoise.
The hare would love the ‘Agile’ approach that is in favor with many software developers and system designers. The agile hares run fast in ‘sprints’. They race to release a product to users – “Hey look, we have built a terrific new digital service for you!” – but it is only a partial solution, at best. Like an incomplete building, the users are allowed onto the building site too early, when only the foyer is ready for use.
Through such regular builds of software, the agile hare attests that he is making rapid progress. But in a project that is building a serious business system, the race to release the product of a few sprints achieves little except a pat on the back and a nice nap afterwards.
In Agile IT projects, the hares dance around with great energy. The latest thought or challenge easily distracts them, and they lose focus on where they are going. Although well-managed Agile IT projects will begin with an overall design and will ensure that the product of each sprint aligns with the design, we have observed that this rarely happens in practice. The holistic and enduring target design is often sidelined. Yet the hares still expect to deliver a coherent system that properly supports the business processes, while pulling their team in all directions, believing this is what being agile means.
We need a better, more tortoise-like approach. We need a method that delivers coherent, well-structured business processes and systems. This approach would build a holistic solution using proven patterns, with doggedness and persistence. We would keep the end-goal at the front of our minds – like the tortoise. The tortoise’s approach would deliver a joined-up end-to-end service journey, and – more importantly – the efficient and repeatable back-office processes that fulfil the promise to the customer.
The passing fashions of the IT world serve to distract the hare from getting to the finish line: Agile development methods, scenarios, user stories, prototyping, user research, design thinking, service design, user experience design, and so on. The tortoise might use some – or all – of these techniques; there is no denying they can be useful. But he knows that producing a worthwhile business system requires much more than a shiny new tool. It requires persistence, as well as the ability to remember the goal, and make constant progress towards it. Progress is not so much about delivering some, or any, working software, but about designing and assembling all the pieces methodically in alignment with a planned target.
When constructing a building or a bridge, correcting an error in the design or adapting to a change in the client’s brief can be expensive. Beyond a certain point, there is no going back. The hares in the software industry exploit the fact that developing systems is not like constructing a building or a bridge. It is much less costly to fix a mistake in software or to meet an emerging new requirement. Provided, that is, you still have some investment capital left. If the money runs out, the hares may release the product anyway so as not to ‘waste’ the investment.
The tortoises avoid getting into that situation by discovering the client’s objective and requirements quickly. They design a robust target that links people, process, data, and technology in a seamless whole. The tortoises rely on using simple patterns to design and build the target quickly yet robustly. They insert data levers and switches that business folk can adjust down the line, without further IT investment.
Many large IT projects fail to deliver a complete product or meet the strategic objective, leaving disappointed investors and users in their wake. Poorly expressed and undiscovered business requirements are often the root cause of these failures, but only rarely are they exposed as such because people are loath to learn what to do differently next time. The fashionable hare-driven methods will probably not arrest the growth in costs and mounting failures. There is little evidence to date that the Agile methods have greatly improved project outcomes.
We need to stop sprinting and napping like the hare. The tortoise sticks to the long game. He knows where the finish line is, and he knows how to reach it. Let’s behave like the tortoise.
Managing change
Emily is excited. She loves the fresh approaches she has been learning about and enjoys working as the subject matter expert on a system redevelopment project. Basing the business requirements on the Transaction Pattern really helped the team to deliver a business system that supported an improved internal business process. The alignment between the business requirements and the desired service design enabled the development of a much-improved customer experience.
Emily is keen to keep her rebellion alive. She recognizes that persuading others to use the new approaches calls for them to accept changes in the way they do things. She has seen how difficult it can be to bring about change in the processes and the culture of her organization. Emily wonders why change is so hard.
Often, change is difficult because there is too much of it. Emily’s colleagues are weary of the constant change initiatives that management foists upon them, yet that do not seem to achieve much. Managers love to tinker with easy things like the organizational structure, believing that a ‘better’ structure will make the organization work better. Usually though, restructures only change the responsibilities of the senior managers and their reporting lines, with no effect on how well the business works. Other management favorites include outsourcing of certain services, new computers and software, centralizing shared services, measuring staff performance, and reversing previous change initiatives.
Everyone is aware that the pace of change is accelerating. There are many factors that drive this acceleration, not all of them management fashions. A significant driver of change is technology innovation and continuous efforts to maintain competitive advantage and save on costs. But the cumulative effect on staff of change on top of change is often great fatigue and – ironically – less efficiency and fleeting benefits. There is a growing recognition since the 1990s that programs that aim to deliver transformational change fail more often than they succeed.
The problem with change may be even more fundamental and embedded in the way businesses are designed. According to management innovators, Gary Hamel and Michele Zanini:
The reality is that today’s organizations were simply never designed to change proactively and deeply—they were built for discipline and efficiency, enforced through hierarchy and routinization. As a result, there’s a mismatch between the pace of change in the external environment and the fastest possible pace of change at most organizations.23
How can we run change initiatives that really ‘stick’ and make a lasting difference? Part of the answer is that we need to manage the change explicitly. This is encapsulated in a growing specialization known as Organizational Change Management. More than simply helping people to deal with changes or controlling changes to business plans or system projects, Organizational Change Management focuses broadly on what needs to change within the whole organization. It includes many different disciplines – from behavioral science to business solutions and technology.
Organizational Change Management employs a structured approach to implement change successfully with minimal disruption to business operations. The goal is to achieve lasting benefits. While many different models of change have been tried over recent decades, change managers – now a recognized vocation – have settled on a few that have been proven. Comprehensive guides to the methods and competencies required to manage change effectively have been developed. Including a well-trained and competent change manager in a project team is an important step towards making change ‘stick’.24
Managing the change of adopting the Transaction Pattern
While implementing the Transaction Pattern in your organization may not be on the same scale as a large transformational change initiative, some of the practices of modern Organizational Change Management will prove helpful. Implementing the Transaction Pattern might be tackled as an across-the-board change to the methods by which the organization develops systems and improves business processes. This approach would require adoption of the approaches outlined in this book by your colleagues in a wide range of disciplines. It would also require winning the support of a senior executive who would mandate the change and champion it throughout the business.
A more successful approach, however, is to just start small and gradually build a following. Emily decides on this option after using the Transaction Pattern in a small way for a while. Now that she has demonstrated that the techniques work, Emily thinks that other people will want to adopt it too.
In fact, implementing the Transaction Pattern has a low barrier to entry. It involves tweaking or modestly amending processes that you are already likely doing in some form. It requires no additional software tools and it can be begun within a single project.
Despite this low barrier, we have found that changing system design and development methods inevitably gives rise to objections and obstructions. Emily will need to be prepared to manage them. One way to be prepared is to be thoroughly familiar with the organization’s current system development practices. This will be known as the ‘System Development Life Cycle’, the ‘System Development Method’, the ‘Agile Development Method’, or a similar name. Bear in mind that the current practices may not be formally documented; teams just know ‘the way we do things here’. They are the set of practices that your business and IT people actually use in projects.
The standard practices, whatever they are called and whether documented or not, will most likely contain variants for different kinds of projects, such as a system refresh, a new system, process re-engineering, or introduction of a new product or service. There may even be several methods in different parts of the organization, especially in a larger organization. The system development practices will have a flavor of ‘requirements up-front’ (often called ‘Waterfall’) or ‘requirements as-we-go’ (‘Agile’). (We outlined these two fundamental attitudes to system development in Chapter 1.) These two basic approaches have much in common. Successful proponents of both employ many of the same features. If documented, the practices will appear to be sensible and methodical – more tortoise-like than hare-like. In practice, however, sensible, methodical practices are often distorted by the pressures of reality or the whims of the participants in the project.
Slipping the Transaction Pattern techniques in between these existing practices in her current project is a low-risk way for Emily to begin her quiet rebellion and perhaps to find a few other people who want to adopt the practices. In turn, they will influence others. In this way, Emily’s initial tentative actions will grow into a broad network of influencers in her business.
In the rest of this chapter, we summarize each of the techniques discussed in this book, including the business outcomes that will result from using them. We also set out four key steps to take when implementing the Transaction Pattern and its associated techniques.
Transaction Pattern techniques
When Emily began using the techniques we have outlined in this book, she found that she needed a concise summary of each technique. All these techniques support the effective use of the Transaction Pattern in some way. We believe that using all these techniques will benefit any business improvement or system redevelopment project. However, it is not essential that all techniques be implemented at once – a gradual introduction of some techniques may be the most successful approach in a given situation. Be aware that, ultimately, you will call upon all these techniques to get the best out of the Transaction Pattern and to embed the use of the pattern successfully in your organization.
Steps to implementing the Transaction Pattern
In this section, we describe four key steps to take towards implementing the Transaction Pattern and the associated techniques outlined above.
Three key points from this chapter
- Ensuring that a change ‘sticks’ can be difficult; it needs to be managed explicitly.
- Several Transaction Pattern techniques work together and should be implemented in a sequence and pace that suits your organization.
- Four high-level activities or steps are needed to embed the use of the Transaction Pattern and to demonstrate its positive outcomes.
Further reading
ACMP’s Certified Change Management Professional program; The Association of Change Management Professionals; Retrieved from https://bit.ly/2PdtR5Q.
Change Management, Wikipedia, Retrieved from https://bit.ly/2AFiGxs.
Hamel, Gary and Zanini, Michele. (2014) Build a change platform, not a change program; McKinsey; Retrieved from https://mck.co/2xYzz2N.