Soliciting requirements from an SME

When soliciting requirements from an SME (Subject Matter Expert), what is the most important information you need to capture? And how do you know that you have captured it? What would your response to this question be?

What is the most important information you need to capture?

Capturing requirements is an art and it plays a key role in the effective and successful delivery of any project.
When I worked with Business Analysts and project teams I found gaps in the requirements gathering approach. I highlighted this with the BA’s and they asked this question:
When soliciting requirements from a subject matter expert or end user, what is the most important information that you need to capture and how do you know that you have captured that information?
My initial response to this question is to say that the BA needs to ensure they ask enough questions in order to fully understand how current business processes work.
So much of what happens in a project is based on a change to the current work process. Therefore without fully understanding what happens currently, you have no idea what you need to document to create the changed view.
Asking the SME how things work and capturing the detail is very important.  If in asking the questions, things don’t make sense, this is a great sign for me that there are pieces of information missing.  You must validate what you are being told. And the way to do this is to ask more questions.

Why it’s important to validate the information

By doing this you are able to see, any areas where there are additional processes impacted, systems that interface, those sorts of things.  If you only take what you’re told on face value, you miss out on a lot and subsequently leave your project open and risky.
Why?  Because anywhere that you, the BA, as the knowledge holder for the project, don’t understand fully what happens or is going to happen leaves an unknown, a gap that can and will create a risk that something may go wrong.
You know that you’ve captured enough information when you have a solid understanding of the way the current processes work. And then what your changing process is going to look like.  Only when you have this information down and detailed can you then start to bring systems into the picture.

Don’t focus on the system, focus on the process

Start with the system and you’re coming at things from the wrong way.
Even when talking about a project that is predominantly about system change, you still need to be asking questions about the process, as this is what drives what happens.
Therefore paint the picture of what the current processes are.  Then paint the picture of what you want any new processes to be.  The gap is what needs to be filled with your project – how to get from AS IS (Current State) to TO BE (Future State).
What I have discussed here is the key role of a BA on a project team.  If they do this well, then they set the project up for success. A good Business Analyst plays a vital role in any project team.
*Photo courtesy of Stuart Miles at