Rules of thumb for business analysis

thumbThis article is intended to be the starting point for a discussion on rules of thumb (or heuristics) for business analysis activities. It describes some principles I think are important to practice in all situations which have served me well.

In wikipedia, the definition of a rule of thumb is:

a principle with broad application that is not intended to be strictly accurate or reliable for every situation. It is an easily learned and easily applied procedure for approximately calculating or recalling some value, or for making some determination

Every analyst will have developed their own rules of thumb over time. If you ask them to list them they will probably struggle because they tend to be instinctive and require some reflection and thought.

I have spent some time thinking about my rules of thumb and hope you find these useful. This is probably incomplete and when others list their rules, in some cases, I will say

Of course! I do that too

Or, more worryingly:

Of course, now that you mention it, I used to do that but, for some reason, I’ve forgotten about it. I’m going to start doing it again because it’s a great practice

Anywhere, here are my rules of thumb to start the discussion:

Learn the language

It is your responsibility to understand the business domain.

It is not unreasonable that you don’t understand the domain but it needs to be recognised and planned for at the outset of the project, potentially with the assistance of the subject matter experts.

You need to ensure you get up to speed as quickly as possible and using the minimum of stakeholders’ time

Active listening

Listen to the client and replay what you have heard, constantly.
Repeat it in different ways to the client and other stakeholders.
Ask questions around the subject to ensure you understand all the variations and the nuances.

‘Reframing’ is an effective technique to confirm understanding and drive out detail, issues, assumptions and increase understanding.

Challenge all assumptions

Be determined and risk being unpopular (in the short term) for the project good.

If you don’t understand why an assumption has been made or why it is justified, challenge it!

If you don’t understand it, there is a good chance someone else doesn’t either.

Understand everything

Ensure you understand everything. If you don’t understand it then there is a risk it is wrong or unnecessary, all of which will contribute to problems or further cost later in the project.

You don’t need to understand the technical solution but you do need to understand all the requirements and be clear on their rationale and the benefit they provide.
If you can’t say this with all honesty, you need to be asking questions.

Be a guardian

You need to protect all of the following:

  • Objectives, requirements and sponsor’s budget
  • All stakeholders’ interests
  • Other people’s time

You must ensure the objectives are documented, agreed and understood and requirements contribute to those objectives. This ties in with protecting the sponsor’s budget to ensure project time is invested in what has been agreed and is not hijacked by local stakeholder interests.

However, you do need to ensure stakeholders are heard and their interests are protected.

You also need to ensure that when you take up stakeholders’ valuable time, there is a good reason for it. For example, it will move the project forward faster (i.e. when bringing stakeholders together in a workshop) or a subject matter expert needs to be consulted and there is no other source of advice available (i.e. reading existing project or industry documentation).

I hope you have found this useful. If you have any rules of thumb, please post a comment for the benefit of other blog readers.

About Alex Papworth

2 Responses to “Rules of thumb for business analysis”

Read below or add a comment...

  1. alexpapworth says:

    Thanks Hansa

    This is a good point although I'd just caveat that you should make sure there is value in producing the particular documentation.
    But, as you say, many of these things are not documented. If you don't keep an accurate audit trail, you can revisit the same point several times. It can also resolve disputes further on down the line

  2. Hansa Magar says:

    I agree with all of the above points.
    Another rule of the thumb is 'Document, Document and Document some more'
    As a good Business Analyst it falls upon us to ensure that Meeting Minutes, Decisions made, Emails flown around, relevant phone conversations are all captured somewhere and stored in a central repository which will be accessible to the rest in the project team. The documentation will also serve as a valuable resource for future project maintenance, metadata purposes etc…

Leave A Comment...