Business Analysis using "Method H"
by Neville Turbit
Many Business Analysts start a conversation with users by asking what they do. The conversation tends to drift in no particular direction until a thread is sighted, then the BA follows that thread to the end. The next thread is fleshed out and a similar process followed. Hopefully, by taking enough random walks around the person’s job, sufficient information will be collected to come up with a requirement.
In this article Neville Turbit describes a more methodical approach to eliciting requirements called "Method H".
| Attachment | Size |
|---|---|
| Method_h.pdf | 113.74 KB |
Efectiveness
A big part of Business Analysis is translation. Taking what a user says and turning it into IT speak. Method H seems to bridge the gap. It elicits information in a way that business people think, and it fits IT requirements.
Since we developed the technique it has been used around the world and we have never had negative feedback. If fact one guy rang me from the UK to see if we would confirm he had been using the technique for years with a client. He was actually using it for the first time, but found it so easy he has been back to us a number of times with rave reviews.
Would I use it everywhere? Definitely not. Some processes are so complex, you need to do some serious BPM. Method H is better for smaller developments. Incidentally anyone doing serious BPM who does not use Holocentric Modeller needs their head examined!
Someone mentioned that Method H does not look at the 'why'. Correct. If you need to reengineer processes, use a modelling tool. If you are specifying a fairly stable process, use Method H. It is all about horses for courses.
Neville Turbit
www.projectperfect.com.au