I came across a LinkedIn discussion recently where a group of business analysts were discussing a common gripe: business people who are not smart enough to understand analysts’ outputs. They can’t follow correct methodology or notation, even when international standards have been applied. These standards have been developed for use by analysts and technical teams because they are supposed to be easy for business teams to understand!
Speak the right language
In short, it’s not them, it’s you. You’re using the wrong language.
Navigating an organisation through change can be scary. It takes a team effort, and depends on trust and clear communication, both ways. As change practitioners we need to build an understanding of business needs and confirm that understanding with clear, easily comprehensible communication to build the trust required to take the leap into the unknown.
What about the GLOBAL notation standards?
The idea of a standard language to drive change and to communicate amongst all stakeholders is of course fundamentally valid.
But for one point…
‘Business users’ are the key audience in the change conversation. They drive the requirements for change, they know the business, they know the customer. They’re where innovation springs forth, given the right conditions. And unfortunately, they’re all different. The idea that we try to teach them this new notation, this communication standard just as they’re about to embark on a major change is just… confusing. And risky, because not all of them will get it. They’ve got enough to deal with driving the change.
What we’re really trying to do with technical standards and notations is impose a style that works for us (the technical analysts, and change specialists) on ‘them’. The advantages for us are huge.
The way we communicate process and change to business teams should:
- First and foremost, unequivocally meet their communication needs - business teams find the information easy to understand
- If at all possible, be in a format they already use and prefer to communicate process internally (varies by team)
- Form the platform for process change management and ownership… again, this means it should be in the format they already use and prefer to communicate process internally
- Be used as the basis for change and technology assumptions by technical teams. If more information or detail is needed - capture it in a way that doesn’t obscure the underlying process and needs of business teams.
Keep it simple, stupid
I’ve got a recurring theme in my blogs: process improvement isn’t rocket science and simplicity is often the cornerstone of innovation and successful change.
Effective communication by definition means that your intended audience (in our case business teams) find your message easy to understand. They can see what they need to do simply, clearly and in a way they immediately ‘get’, and therefore feel that they can truly join the change conversation. It also means they can share what they’re doing with technical teams and other stakeholders, to work together through the change.
That’s what change and collaboration is all about – it’s a very human experience, and it’s something that some business analysts, due to their technical strengths, struggle to recognise.