Why model?

Why should Business Analysts use models to document requirements?

What’s wrong with using widely-used Business Requirement Specification templates, documenting lists of requirements in spreadsheets, or just using sticky notes or Kanban-boards to document requirements?

These might be valid questions. It has always (or often) been done this way, hey?

But ask yourself this:

- How often, especially in corporate environments, has the final, signed-off version of a specification document gone missing?

- How often can no-one find that specific BRS, in the numerous mailboxes or hundreds of document repository folders?

- How often does no-one know whether a document contains the latest requirements, who approved these and whether they are still up-to-date?

- How often have you seen duplicate projects being kicked-off because people are not aware of similar efforts?

- How difficult is it to ascertain how one change in one process, system, or dataset impacts the rest of the organisation?

- How often have you seen changes or projects being implemented, where it had unintended consequences because there was no proper understanding of the interdependencies on the current landscape?

I contend that there is a better way…

Making use of models!

What is a Model?

The BABOK® Guide to the Business Analysis Body of Knowledge® (V3) says that a model is:

“A representation and simplification of reality developed to convey information to a specific audience to support analysis, communication, and understanding.”

The main reason why I love using models

for business analysis, is because they

reduce cognitive load.

According to Miller’s Law, the average person can only keep 7 (plus or minus 2) items in their working memory.

Cognitive load is a term used in psychology to refer to the used amount of working memory resources in the brain. More commonly the term is used when people want to highlight when people cannot successfully deal with the amount of strain being placed on their cognition (their brains) during a complicated (brainy) effort. We see this often in the workplace, don’t we?

Some say that the causes of cognitive load are related to three main factors:

1. Too many choices
2. Too much thought required
3. Lack of clarity

Each of these factors take up mental resources that don’t help people understand the subject that they are busy thinking about.

Think about trying to read (with understanding) that academic, text-only based university style textbook of hundreds of pages and the amount of strain (cognitive load) it puts on your brain. Now compare that to seeing a mind-map summary or a video of the same concepts in the book. The cognitive load would be dramatically reduced and in many instances the understanding and retention might even be vastly improved.

Similarly, this is where Business Analysts sometimes miss a trick. By churning out hundreds of text-based or list-based requirement/process/solution documents, we are ‘overloading’ the cognitive abilities of the readers and in a sense we lose them, their attention or, worst-of-all, their interest.

Instead of this, using models provides a much better approach with higher understanding, simpler presentability and typically more buy-in.

Some other benefits of modelling include:

• It could provide an accurate, but simpler representation of reality (if modelled correctly, of course). Reality is often very complex and difficult to get your head around.
• It can reduce complexity — it’s much easier for people to understand multidimensional aspects of any given business, compared to mere text-based descriptions.
• It gives us structure for context to explain any given landscape. Such a structure helps us document all the typical elicitation questions (Who, what, why, where, how?).
• It explains interactions between process (i.e. the how), data (i.e. the what), actors (i.e. the who), locations (i.e. the where), the rules, controls, constraints (i.e. the why). In short, it provides end-to-end traceability.
• It highlights and visually demonstrates dependencies between different elements of your enterprise. This is critical for impact assessment.[1]
• It focusses discussions. Models are especially powerful to facilitate a focused discussion and limit it to a specific topic.
• It allows you to go deep OR wide. Sometimes it is necessary to discuss the big picture, but other times it is required to zoom in on a particular element/process and go deep into the detail.

Some considerations though — your models need to comply to some basic principles:

- Models should be simple to understand and not be overly complex. Rather, use levels of abstraction and break-up complicated process models into separate diagrams, as opposed to trying to cram everything into a single diagram. This does NOT mean they should be simplistic. Don’t ‘dumb-it-down’ to the extent that complexity is misrepresented, and important detail is lost. It needs to be a balance between not complicating your model and not oversimplifying it. You might not always get this right the first time around, which is why various iteration cycles are often required (and encouraged)

- Models must be correct and coherent. If consistency and accuracy are not part of the models, trust will be lost and then interest in referring to them would be lost.

- Eliminate unnecessary steps or tasks. This is a common practice in LEAN design [2] and also applies to modelling.

- Use patterns or modelling languages that ensure consistency. No consumer of your model wants to constantly first figure out how to read your diagrams. Once they’ve first understood how you model things, there’s an implicit expectation that you’ll keep on doing it the same way and not keep on changing your way of working. This is especially relevant and true in environments where multiple Business Analysts work together in the same modelling repository or on the same project. If each person models in their own way, this is a sure recipe for disaster and non-acceptance on the part of the consumers of those models.

I have personally found modelling to be an invaluable tool in my personal Business Analysis toolkit and it is my belief that no BA should go without it.

References:

1. https://www.digiterragroup.com/wp-content/uploads/2016/08/Digiterra_Understanding-the-UnIntended-consequences-of-changing-businesses_Danie-Vandenberg_20160815.pdf
2. https://www.lean.org/whatslean/
3. https://www.batimes.com/articles/model-driven-analysis-a-way-to-work-smarter.html
4. https://www.batimes.com/articles/picture-it-get-to-mutual-understanding-and-agreement-faster.html
5. https://www.iiba.org/professional-development/knowledge-centre/articles/why-model-business-processes/
6. Image used in this article: Photo by Andrea Piacquadio from Pexels