This 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
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.
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.