The Power of Context….

When inside a maze, it is very confusing (and frustrating) to know where you are, where you’ve been and where the heck you are headed… When however you have the option to rise to a level above the maze and get a higher level view…a better perspective, you gain the ability to find solutions to your predicament more easily.

That is the power of perspective, of placing your circumstances in the proper context.

This is also true of business problems. It also applies specifically to documenting or modelling complex business process problems, requirements and solutions.

Let me explain what I mean by this…

Often one sits in a meeting room, surrounded by a variety of stakeholders, engaged on a certain set of business requirements. When these stakeholders are from different areas of a business, they typically have their own agendas and reasons for being in that room at that point in time.

The financial guy is for instance possibly looking at the project from a cost reduction, revenue increase or return on investment perspective. The operational person is looking at possibly automation or improving turn around times. The sales person is looking for features, benefits, bells and whistles which she can impress her clients with.

These individuals are therefore probably listening with a biased ear, listening for the part of the discussion that peaks their own interests and serves their own needs.

When this happens, everyone is not always on the same page and this tends leads to misunderstandings. Dependent on the ability of the facilitator to focus a discussion, this might often lead to people leaving a meeting more confused than before.

I have however on numerous occasions seen that where basic diagrammes or pictures are used to focus the discussion and check understanding, the success rate in terms of understanding issues at hand, is greatly increased.

There is just something about drawing a simple picture, that focuses the mind and clears the clutter away. A picture gives one the ability to ‘zoom in’ on a topic that is up for discussion and removes the rest of the fluffy, distracting, additional details to a large extent.

Business Analysts often use this technique, specifically using context diagrammes.

What is a context diagramme, you may ask? The definition I really like is the following one from the ModernAnalyst.com:

The Context Diagram shows the system under consideration as a single high-level process and then shows the relationship that the system has with other external entities (systems, organizational groups, external data stores, etc.). “

Essentially the context diagramme depicts what the problem or solution is and what the factors or forces are that affect it or is affected by it.

Different modelling languages and notations might have more or less formal ways of depicting their context diagrammes and you might even have an “anything goes” approach to modelling your context diagramme. As long as the audience at hand understand and agree on the requirement or problem that is being documented.

Another huge benefit of drawing a context diagramme, is that it enables the audience to absorb a huge amount of detail or data quickly and easily…sometimes even at a glance.

Here are a few examples of different context diagrammes:

See their great article here

 

 

See their article here

You see….  this does not have to be painful. Who know, it might even become fun!

But be sure to use the concept of context diagrammes to your advantage.

Your context diagramme can include be scribbles, pictures, be hand written, be  messy… anything goes – the aim is to get clarity of understanding as well as participation of the stakeholders. If it means that you need to swop out pens, put people on the spot or draw on your limited artistic talents… so be it..

GET PARTICIPATION – GET TO CLARITY

Remember that clarity creates power!

And now for something really fun ….  start getting creative with your data & how it is presented…

Of course you really need to understand the data before you sell it like this :-)

Leave a comment

Filed under Uncategorized

Clarity creates POWER!

Try finding your way in a blizzard…not an easy feat!

Have you ever noticed how much time is spent talking about how to approach a task, a project or a problem at the clients where you serve or at the companies where you work on? I don’t necessarily mean devising a strategy….I mean the kind of discussion that leads to arguments about what is actually on the table. Where if you speak to 5 people, you get 5 differing ideas on what they believe needs to be achieved or how to achieve it. Where there is just utter confusion around the WHY, WHAT, HOW and WHO…

I’m sure you would have noticed a significant amount of time and money being spent on this? Continue reading

Leave a comment

Filed under Business Analyst

The value of traceability…

Remember the fairy tale of Hansel & Gretel? Hansel had a plan to keep them from getting lost in the woods, by leaving breadcrumbs in order for them to trace their way back later. Unfortunately the breadcrumbs were eaten by the birds and they got horribly lost.

How often I wonder do we get lost during software development projects, because we use a “breadcrumb” approach to keep track of what we are developing and why…

How important is it to keep track of requirements throughout a software development  life cycle? Continue reading

1 Comment

Filed under Business Requirements, Technique

Activity Diagramme Case Study…”How Business Analysis can drive you crazy…”

Hey fellow- Business Analysts….Have you ever felt like this ? [Forgive the semantically incorrect UML :-) ]

Image

Leave a comment

Filed under UML

Agile UML?

Can UML be used for Agile methodologies?

As someone who cut my BA teeth on UML (Unified Modelling Language), I have traditionally been very biased towards using it as a means to document business – and functional requirements. Not that I do not believe that there are not very good alternative documenting methods out there… but simply because I’ve had great results in using it as a comprehensive and standardised method of modelling requirements. Continue reading

Leave a comment

Filed under UML