Select Page

two-singers

Be glad you’re not the pianist accompanying this duet. Photo: twitter.com/Patrick_J_Egan

Our daily news is filled with people screaming at each other. Sometimes this is because their values differ fundamentally, but more often one person said something carelessly, the other misinterpreted, and away we go.

Sound like any place you know?

Not all conflict is bad

Even if actual screaming matches are rare in your organisation, conflict is ever-present. Some of it is generally unhelpful, like egos battling over who can say more words per meeting. Yet much of the conflict in organisations is crucial to their health. People responsible for different business objectives are supposed to disagree! A successful organisation simply channels that conflict into the production of new value for its stakeholders.

Unfortunately, most organisations treat all conflict like the screaming match: unpleasant displays that must be minimised to keep everyone comfortable. This blanket approach is unproductive and strikes me as profoundly dishonest. Most conflict represents actual differences that must be resolved or accommodated, so pretending they don’t exist worsens the problem.

Disagreement over data requirements is good conflict

We’ve written often on this blog about our journey to better data requirements. It started with a problem we faced all too often: how do you know what the customer actually needs from business intelligence? The answer is not, as Geoff pointed out recently, a wad of existing reports, only some of which are still relevant.

Another common, bad answer is ‘whatever we wrote in those hundreds of pages of specifications last year’. These are out of date the moment they exist, and their ridiculous length is often the result of avoiding productive conflict: let everybody write down a wish list and nobody is required to disagree.

Avoiding productive conflict makes delivery impossible because it encourages duplication and its even worse cousin, almost-duplication. If parts of the organisation define ‘customer’ differently, they necessarily build conflicting pictures of performance. While a single definition of every business concept may not be possible (and may not be wise in all cases), it is always better to know that earlier! Perhaps some of the differences can be reconciled, and if not, care can be taken to make the different meanings clear.

At its core, most conflict over data requirements is not trivial, it represents disagreement over how the business actually works. If the goal of business intelligence is to help organisations understand themselves through measurement, we must surface this good conflict, not bury it.

How to surface conflict productively: BEAM✲ it

Before you go around ‘throwing grenades’ to bring all this conflict into the open, you need a method for channelling it to a productive outcome. Once you get different parts of an organisation to agree they disagree, the next step is to discover the root cause. This directs discussion toward the reasons for difference and whether (and how) these can be resolved. Often a huge apparent conflict is only the result of two names for one thing!

We use BEAM✲, a methodology developed by Lawrence Corr, to surface conflict over data requirements productively. I’ve written a blow-by-blow account and well over one hundred students have already taken our one-day course An Optimal introduction to Defining Data Requirements. Lawrence visits us regularly to deliver his three-day masterclass (check the next date here).

In both versions of the course you learn the following lessons that help surface the right conflict:

  • Avoid ‘data-speak’ and instead use the language of the business to describe the events that happen inside it
  • Apply one methodology to uncover, describe, and document each business event
  • Allow for a wide-ranging discussion of different interpretations, within a framework that makes the next action (delivering useful data!) easy for the people responsible that task

In two years teaching our BEAM✲ course I’ve enjoyed seeing the penny drop in our participants eyes, when they realise how simple it is to understand what data requirements will be useful for their customers. And at OptimalBI we’ve applied these lessons to improve our ability the data that will get the job done for our clients.

It all starts with an honest conversation and a desire to use conflict constructively.

Until next time, keep asking better questions
Shaun – @shaunmcgirr

Shaun blogs about analytics, machine learning and how data solves problems in the real world. 

Want to read more? Try Lawrence Corr: Three things to be a great AgileBI teacher or more from Shaun

Visit our Introduction to Defining Data Requirements course page and find out how you get the best requirements for your data.

%d bloggers like this: