Elicitation can be a tricky activity. Often when needing to understand the requirements for a particular project, the temptation is to jump straight into facilitating a requirements workshop or holding stakeholder interviews. The challenge, of course, is getting enough stakeholder time, and knowing which questions to ask with the limited time available. Understandably, business stakeholders are often too busy running the business to attend meetings, workshops or interviews.
It’s important to come prepared with as much information as possible, and the technique of document analysis can be extremely useful. It’s possible to use document analysis to gather information about the business domain and/or the problem being solved without taking up too much stakeholder time.
So what does document analysis mean? Well, in essence, it just means “finding out what relevant documentation the enterprise has, and reading/referring to it”. This is something that you almost certainly do intuitively, but by consciously planning it you can expand the scope of documents you consider. Here are some document types to look out for:
Forms: If you are examining a process that involves paper forms, ask to see a copy of the form. This will tell you a lot about the process! It will help you to understand the data that’s collected, and it might even hint at the business rules that apply (e.g. you might find that the form states, “All applications over $3,000 must use a form XYZ2”. You’d then know that something different happens in these circumstances).
Business Architecture diagrams: These will often show who does what, where and which business services are in-source/out-sourced etc. They can give you a macro-level view of your domain.
Process or procedure diagrams: Often operational areas keep documented copies of their processes. But beware: They might not be up-to-date, and people on the ground may well be doing something subtly different (so it’s always worth following up with interviews/observation).
User guides/help screens: If you’re working with an existing system, user guides and help screens can help you to understand the “as is” screen-flows. They might even hint at underlying process logic and business rules.
Previous requirements documents: Sometimes, you might strike gold and find that a previous BA has produced a full set of requirements for the system or process that you’re aiming to change. If so, this will be an excellent reference point, but remember that not all requirements get implemented, so it’s worth checking whether anything was de-scoped.
Customer complaints: Sounds strange doesn’t it? But customer complaints can often give you great insight into where processes have broken down. If you’re working to fix or improve a process or system, it’s well worth finding out whether there are any related customer complaints.
Defect logs: Sometimes, business users will keep logs of “pain points” and perceived defects on systems that they work on. Sometimes these will be on a central defect management system, but sometimes they’ll be kept informally on Excel logs or in paper files. Ask for a copy. It’s very useful to understand which parts of the process or system are causing pain.
Product/service promotional material: Often the marketing material for a product or service will give you an insight into how it works. For example, if you are working on a project that involves making change to an Investment product, then the existing prospectus/brochure provide a whole range of useful information about the “as is” product.
Document analysis is a great way to quickly gain enough information to ensure you’re asking the right questions. It can help you quickly get up to speed, and ensures that you’re using stakeholders’ time effectively. A quick initial 5 minute phone call to ask, “Do you have any of these documents, and if so could you send them to me?” can really pay dividends.
Great article Adrian. I like the mention of reviewing customer complaint information. In the past I have reviewed customer feedback surveys as a way of understanding what aspects of a process need improvement.
Thanks Seetha,
I’m glad you enjoyed the article, and I’m glad that you find pragnalysis.com useful also.
Kind regards, Adrian.
I usually follow the above technique when doing some upgrades. This article is very good and informative. I love the Prognalysis website too. thank you for the tips and looking for more examples
Great insight……sometimes I also wonder if the challenge is also in knowing what are the right documents to employ at the right time to elicit most effectively?! Nevertheless, a little bit more effort might not go waste as long as there is no repetitive information maintained I guess.
It’d sure be nice to have a few samples if possible. Thanks.
Hi Srila,
Yes — as you quite rightly identify, the challenge is knowing which documents to rely on at which points in the analysis. This is part of the art and science of being a BA — it will of course be different for different projects, and as individual practitioners we need to make that decision on each of our projects.
Glad you enjoyed the article, and thanks again for the comment.
Adrian.
Wonderful article. If I had a dime every time a BA told me “but there is no existing documentation…” More than that, http://www.pragnalysis.com is a great website. Thanks!
Hi Francois,
Yes, that’s a great point! Often when people say “there’s no documentation” what they mean is “there’s no existing *BA* artifacts”… but there might be a whole treasure-chest of business documents available.
I’m also glad you find Pragnalysis useful — I really like community resources like that, as I think that as a community we can all learn and grow!
Thanks again for your comment. Adrian.
Hi Adrian,
absolutely agree with you – document analysis is a very helpful technique. It helps me get the context and process specifics. It’s also about ‘doing your homework’ before starting the interviews with SMEs. I found it much easier to speak common language with them after digging into available document resources.
Hi Stasy,
Thanks so much for the comment. I really like your example of “doing your homework” — that is such a great way of looking at it, and completely true. As you say, document analysis is a great way to get up to speed and learn the “lingo” of the stakeholders!
Thanks again for your comment, I’m glad you enjoyed the article.
Adrian
Hi Laura,
As you said I contacted back the HR, It was successful. I got job.
Thanks once again.
Bye