A few weekends ago, I caught up with some old friends at a local restaurant. When the waiter came over, one of our party wasn’t quite ready to order – so I ended up making awkward ‘small-talk’ to fill the conversational void. As anyone who has ever visited the UK will know, we are often seen as being obsessed by the weather – as that’s what we tend to talk about in situations like this. So, in full compliance with that cultural stereotype, I went into ‘weather mode’ and commented on how good the weather had been over the past few weeks. In fact, we’d had a lot of bright sunshine – and I commented on how I hoped that this is a sign of a good summer to come. The waiter agreed, but added:
“Yes, let’s hope for a good summer! Although while we’re holding out for good weather and sun… the farming community will be hoping for rain… I guess only one side will get its wish!”
On the face of it, this is a pretty obvious statement, isn’t it? However, extend this thinking further might lead us to conclude that there are all sorts of viewpoints and communities vying for slightly different things when it comes to weather. If you own a reservoir, you want enough rain to keep the reservoir topped up. If you run an outdoor amusement park, you’ll want sun to attract visitors. If you run a shipping company, you’ll probably be fine with any weather as long as it’s not too windy or too extreme. Actually all of these things are interlinked (not enough rain in the reservoir is a problem for everyone, and if the ships can’t arrive then we won’t have enough supplies). There are so many different viewpoints with different perspectives, needs and wants – some of them implicit, some of them explicitly stated. It’s a complex situation!
And this isn’t unique to weather… I bet you see it in your organisation too…
What this means for business and business analysis
Organisations spend a huge amount of time measuring things, changing things and trying to improve things. Before progressing organisational change, the question has to be asked are we all actually aiming for the same outcome? Are we actually aiming for the same thing here? If we’re not sure of this, then there’s a danger that several people in the same organisation can examine the same data and draw quite different conclusions. They can progress change projects and agree on the surface over the aims and scope, but hidden conflict bubbles away beneath the surface and sucks the life out of change initiatives.
Having open discussions about what “good” looks like and where the organisation/function/project is heading is absolutely essential. Imagine if a project was progressed where different stakeholders had subtly different expectations:
- Operations director: “This project is about creating operational efficiencies and reducing cost, primarily through automation”
- Marketing director: “This project is about understanding our customer to improve service, and it’s likely that we’ll create efficiencies along the way”
- HR Director: “This project is about empowering our workforce and creating a better place to work by improving the service we give to the client (leading to happier staff) – reducing cost of recruitment and staff churn.
In reality, it might be even worse than this. In an extreme case, our stakeholders might have different worldviews over what the entire business system is for which will fundamentally affect how they think the organisation needs to change.
Sometimes people with different perspectives appear to be agreeing on the surface. After all, each of the hypothetical perspectives above are aiming for lower cost, and it’s likely that their needs will be intertwined to a certain extent (there will be areas of agreement). Yet the methods and the motives expressed above are quite different. Plus, a number of these perspectives imply early solutionisation (check out my previous article and webinar recording on this subject) which in itself is a dangerous sign. It’s likely in these circumstances the project will run into serious difficulty, will run over-budget, as the scope creeps to try to incorporate all sorts of conflicting perspectives that might never be fully reconciled. In the worst case scenario, the project might eventually explode like an internal political landmine, spewing shards of blame across the organisation. This isn’t a pattern that’s unique to large organisations either – it happens in midsize and small companies too.
The antidote to this pattern is to openly discuss the required business outcomes before a project commences. Ironically, this is often seen as “time consuming”; there is an inherent desire to “just get going.” This is particularly true in projects that involve IT – where there is a race to start writing code – yet until these initial conversations have been agreed it’s very difficult to know what code should be written.
By discussing and defining the desired business outcome, I don’t mean that it’s necessary to define the detailed solution up front. There will be certain outcomes the business is aiming for – be it a reduction in cost, improved service, or whatever. Knowing what these are up-front and ensuring everyone is on the same page is essential. Ensuring that the organisation actually has the capability to measure these metrics and is regularly collecting actionable data to support this is also critical – otherwise there will be no way of knowing whether the target has been met.
In summary: Define the required business outcome well and how that business outcome can be measured first. If you do this, change projects and initiatives will be far less painful. Before you have decided on the destination, it’s difficult to know which map to pick up. Good luck!
Further reading: If you have found this article interesting, you might want to read some of the many articles and books on soft systems thinking, notably Checkland.
This post was written as part of the IBM for Midsize Business program, which provides midsize businesses with the tools, expertise and solutions they need to become engines of a smarter planet. I’ve been compensated to contribute to this program, but the opinions expressed in this post are my own and don’t necessarily represent IBM’s positions, strategies or opinions
