Keeping it simple
“The language of truth is unadorned and always simple.”
“The language of truth is unadorned and always simple.”
The primary job of the business analyst is to facilitate communication: Usually between people who share a common natural language, but still find it difficult to achieve a common understanding.
Often this is simply because natural language has a tendency to be ambiguous - with common words having multiple meanings - and this lack of precision leads to differences of interpretation, especially after some time has passed.
For the most part projects also require communication between people who inhabit different worlds (such as business and technical) which have specialised vocabularies, idioms and jargon. To effectively communicate between them requires an understanding of both worlds - to accurately interpret and translate what is being said - and a common language in which to document it.
"You should say what you mean," the March Hare told Alice. "I do," Alice replied, "at least I mean what I say - that's the same thing, you know." "Not the same thing a bit!" said the Hatter, "You might as well say that ‘I see what I eat’ is the same thing as ‘I eat what I see.’”
-- Lewis Carroll
Unfortunately, there is often a tendency to try to solve a complex problem by choosing a tool that has the (unintended) consequence of hindering communication rather than improving it. In business analysis this can be the result of selecting inappropriate languages for documentation.
Over-complicated document templates and impressive sounding, but ultimately meaningless language, are common faults. Complicated[1] modelling methodologies such as Unified Modelling Language (UML) and Business Process Model and Notation (BPMN) are not effective communication tools for a general audience when used in an unrestricted fashion.
“Everything must be made as simple as possible, but no simpler.”
-- Albert Einstein (attributed)
On the contrary, by continuously seeking to remove ambiguity, jargon and buzzwords from the language used (and clearly defining any required domain-specific terms), an experienced BA aims to document using plain English[2] and simple diagrams. Standard modelling languages are used but with a carefully restricted subset of symbols which are all clearly explained[3].
Complicated document templates filled with boilerplate are avoided.
Every sentence or diagram whose meaning is unclear is a potential cost to the project. They can’t all be eliminated, but by keeping things simple there will be more time to tackle the intrinsic complexity of the business problem and less time wasted on misunderstanding and rework.
“Numquam ponenda est pluralitas sine necessitate.”
[“Plurality must never be posited without necessity.”]
[1] The BPMN v2 specification is 508 pages. The UML 2.4.1 specification is 218 pages (infrastructure) and 732 pages(superstructure). That’s complex.
[2] Or other natural language
[3] I try to limit diagrams for no-experts to 4 different boxes joined by two types of arrows