Boxes and lines

 A few years ago, I joined an organisation to head up their business analysis function, and whilst making my introductions to the BA function’s key stakeholders in the first couple of weeks, one of them said this:

 “I spend half a day in a workshop with one of your BAs and they come back six weeks later with a process map, so I don’t really see the value of it”.

It’s a quote that’s always stuck in my mind.

OK, so the stakeholder in question (I subsequently discovered) had a bit of a reputation. I think the politest way to put it is that he was someone unencumbered with the ability to let thoughts go unsaid (although he’s now a CIO, so it’s obviously stood him in good stead). But it resonated with an insecurity: namely, that BAs will always struggle to articulate their value while this perception prevails, and it’s something BA functions need to be cognisant of.

It was certainly something I felt I needed to dig into, and actually, it’s what gave rise to my characterisation of ‘Type A’ and ‘Type B’ BAs: Type A being someone who’s technique-driven, viewing the necessary interactions with stakeholders as an interruption to their real job of applying a BA tool; Type B being people-driven, who would be able to do the role effectively even if they knew no specific BA tools because they’d invent their own. (There’s an article about this here).

There were three key issues encased in what he said:

• For starters, it was difficult to argue that a period of six weeks between eliciting the information and presenting it back was reasonable. Granted, there were mitigating circumstances such as difficulty getting time with the other stakeholders that needed to be consulted, plus a heavy workload that had expanded to fill the available space for the BA in question, but none of that resonates with a stakeholder who’s made a significant investment of time in the activity.
• It turns out that the output was sent out for stakeholder review by email with no ‘wrapper’ to set its purpose and outcome in context. BPMN2 is a fantastic method for articulating how work flows through an organisation, but it’s not meant to be consumed unsupervised. To a stakeholder, it just looks like words in boxes connected by lines (which is what you tend to get when the business try to map a process themselves).
• There was also no obvious desired outcome from sending it out, beyond validating that it was accurate. (Even that is difficult to establish over email because it’s rare that an organisation has levels of process compliance that make an process diagram true in all cases).

 These three issues give rise to three fairly simple rules:

• If a stakeholder has invested time in your workshop, you need to ensure the output is sent out as quickly as possible. Sometimes you do need to validate that what you’ve captured is correct, but if that is the case it needs to be as instant as possible, ideally within a day or two of the workshop itself.
• Always walk through a process map. If, for practical reasons, you can’t be there in person to do with, provide a narrative flow to accompany the process.
• Always articulate why you’ve mapped a process – to drive out the requirements for the solution? If so what are they (even at a high level). In an of itself, a process diagram isn’t much use.

The fact is, all business change is about improving organisational performance. And since everything an organisation does is either a business process or part of a business process, if you want to effect organisational improvement, it’s in the business processes that you’ll do it. IT solutions exist to enable an improvement in business processes. And requirements – whether expressed as ‘big hairy audacious goals’, stakeholder requirements, user requirements, functional/non-functional requirements or transition requirements are all requirements of the business process.

Mapping business processes is therefore the spine of organisational change – at any level of detail. The requirements hang from the process, the org design hangs from the process, the data and information flows that an IT system will underpin hang from the process.

A good BA, therefore, needs a strong elevator pitch for process mapping in their toolkit.