Our thoughts on business transformation and change management

The following is an amalgamation of conversations I have been having recently, explaining the world of agile to a team of project managers. Some have worked out well like this, some have not...

Project Manager: "Acme are unhappy again - this is the third project that's overrun but they just cannot see that hold-ups their end are causing the problems. We must have lost six or eight weeks waiting for changes - we've finally completed UAT and gone live but the website missed the start of their peak sales season. They've given us one last chance with the next project or they are going to leave us."

Scrum Master: "So, have you thought any more about the agile approach I told you about?"

PM: "Yes, a little, but I still don't understand why you don't want a requirements document. Tell me again about user stories and epics..."

SM: "OK, a user story is a simple description of what the user is trying to achieve. The product owner works directly with the customer stakeholders to see what the real business need is and write the stories. Epics are bigger bits of functionality that need breaking down into stories in future."

PM: "OK, I get that but where are the full requirements written? Where does the client tell you what to build?"

SM: "First off, the client never tells us what to build - the client tells us what their needs are. We add value by using our own expertise to design a solution. We know that neither the client nor us fully understand the details at this stage so we build small iterations and learn from them, adapting the design as we go".

PM: "Doesn't that result in lots of re-work? Surely a detailed requirement doc would prevent that?"

SM: "There is a little re-work but, as I said, the client doesn't fully understand the details either so chances are a lengthy document frequently would just be describing the wrong thing. If we built from that, we would put a lot of effort into building something that doesn't meet the client's real needs and have far bigger changes to deal with.

"By trying things in small steps we can get customer feedback very quickly so none of the changes ever cost much. In fact, we often find they highlight areas the customer hadn't thought about and help focus on where the real business value lies."

PM: "But a requirements document forces the client to think things through up front, doesn't it?"

SM: "It does, but we know this isn't effective. Take a simple web application: even this is going to have reasonably complex interactions - input validation is a prime example. Without seeing the system working, it is practically impossible to map out all the permutations. In fact, trying to document them up front can make things a lot worse - if the document doesn't match reality, the developers end up making all sorts of compromises to make it fit. You saw that on the last project where we had to roll back that chunk of work because of a bad assumption."

PM: "But that's why we have change control - we should have raised that as an exception before the developers build it so the customer can revise the spec."

SM: "We'd already been through the exception process with the previous issue - you said it yourself: that one must have lost us as much time as rolling back the other thing!"

PM: "Well, if the customer got the spec wrong, that's fine - we have an agreed exception process and if they caused the delay, they have to accept it."

SM: "But Acme are already complaining that we deliver late and are difficult to work with... Just because the client has signed a delay off doesn't mean it isn't late! This is the fundamental problem with detailed up-front specs - there is no room for change and we end up competing to blame any issues on each other. Don't you see that hiding behind a requirements document and contractual terms doesn't benefit anybody?"

PM: (sighs) "Agreed. So, how will using user stories help?"

SM: "User stories allow a collaborative approach where we work in partnership with the customer to solve their needs. We would ideally start off with a workshop with their stakeholders to map out the key user journeys at high level, identify any design constraints and so on. More detail gets added in, but only as it becomes needed.

"Most change requests we get come from the customer seeing how the system works and changing their mind. If the customer can keep the decision open until we are ready to build that bit, we never get far fewer changes. We also get far fewer UAT defects because the customer has seen it early on - ideally, we can avoid UAT completely."

PM: "So, by limiting the detail up front, we get to set the detail as it is needed so we only build what the customer wants?"

SM: "Exactly!"

PM: "And with the next project, could we also start early by work-shopping the initial user stories and epics with them rather than waiting for them to write the requirements doc?"

SM: "Yep. Now all I need is your support to win the customer round - demonstrating agility is by far the best way to convince people so can you get the initial workshop set up ASAP?"

PM: "Will do."


Does this reflect your experiences? How have you helped traditional software houses struggling to meet customer demands? Any thoughts welcome!

How Does Change Happen?

There are two main ways that transformation happens: as a major change programme with a set end goal and as an ongoing series of "continuous improvement" changes that each alter a small aspect of the organisation.

Transformation Programme

A transformaton programme happens when a significant change is needed that cannot happen without impacting a large proportion of the business. This might include implementing a new CRM or ERP system (impacts on sales, manufacturing, suppliers, legal, finance) or adapting to a new regulatory environment such as the current data privacy move from DPA to GDPR (affects every aspect of the business where personal information is held and has potentially massive legal ramifications).

Transformation Programmes can be disruptive, may span years and need to be constantly assessed for relevance. However, they represent the simplest approach to delivering a major change that needs to bring lots of different departments together.

Continuous Improvement

Continuous improvement happens when an organisation is constantly re-evaluating itself and adapting to changing conditions. This is a very agile approach that allows businesses to respond very quickly to shifts in the market, new competition and so on. It also works well for smaller regulatory changes and for implementing incremental savings.

A high profile example of continuous improvement is the British Cycling team - in 2010 the team was in the doldrums, performing OK but never excelling. Dave Brailsford took over the team in 2010 and, two years later, Team GB took 70% of the cycling gold medals at the London Olympics. Brailsford did not achieve this by implementing one major change - he looked at each and every aspect from rider nutrition to exercise regimes to the design of the bike right through to the type of pillow that gave the best sleep: each of his changes may only have achieved a small performance increase but one percent here and two percent there rapidly added up to race-winning advantages.

The same effect applies in business - consitently achieving one percent improvements won't make a huge difference at first but the cumulative impact can be massive.

Which One Is Right For Me?

There is no one right answer to this as it depends on your particular circumstances. If your organisation needs to make a major change to face a brand new challenge, or if it has stagnated for a while and it will take too long to catch up with incremental change, a transformation programme is probably required. However, if the overall business environment has not changed significantly and the way you do things is not fundamentally wrong, an incremental approach may be best. 

However you choose to deal with your current challenge, we recommend that you also implement a long-term continuous improvement programme. This will help you maximise your performance over time, learn to enbrace change rather than fear it and build in agility to deal with future challenges.

The world is changing fast than it ever has before, and where there is change, there is both risk and opportunity. Canny business leaders are accepting business transformation as a way to stay ahead of the market and succeed where others are failing.

At The Peak Consultancy, one of the challenges we regularly face is helping clients improve productivity. We have seen all manner of attempts to get people to work harder and have identified three factors that absolutely must be right before anything else will work. If any one of these is wrong, any efforts elsewhere will be wasted.

Whatever hurdles get thrown at your business, agility is key to dealing with them effectively - this applies across all industries from manufacturing to IT to local councils and across all business types from small non-profits to large multi-nationals.

This article takes you through four essential steps to achieving business agility...

Page 1 of 3