Business Analyst Community & Resources | Modern Analyst

The Community Blog for Business Analysts

Mike Cunningham

Asking the Right questions-Process Discovery

If you are an internal Business Analyst or consultant asking the right questions in a Discovery project is a critical skill. While it seems that a 10 or 20 year veteran seemingly gets those answers by some magical power, it’s really not that complicated. The experienced Business Analyst or Project Manager has been there many times before and knows how to build an good set of probing questions that will bring out the details.

For process discovery, you may already be a subject matter expert on the project, but often that’s not the case. In these situations creating a shopping list of items that will guide you to ask the right questions is very important. This list includes:

Identification of roles of those involved
Responsibilities for actions/tasks and decisions in the process
Outcomes and results from the processes in hand
Known problems with existing processes
Goals from management required from the Discovery project
The expertise level of the intended audience
Access to quality standards for the existing process
Clear separation of “current state” from “future state” questions
Identification of resources, guidelines and instruction locations and usage

This list can go on, but you get the idea. Unless you identify, who, what, how and when before you start the interview or information gathering process, you many need to re-interview staff because of your unpreparedness. Not a good idea. Plan your questions carefully, particularly when it comes to the interview stage of your Process Discovery project.

Original posted at Michael Cunningham's BPM Blog

This entry was published on Jan 21, 2011 / Mike Cunningham. Posted in Business Process Management (BPM) . Bookmark the Permalink or E-mail it to a friend.

4 members liked this article

COMMENTS

Wilco Charité posted on Monday, March 14, 2011 3:54 PM

Identifying who, what, how and when seems not enough to me. That counts also for the list of questions listed here.

Of course, you need to know as much as possible of the subject before interviewing anyone. Desktop research and of course, all things mentioned in the article. But, to really get to know what's happening, you need to talk to the stakeholders, however mucht you know (or not) in this recovery-proces. A problem could occur very difficult, solutions should be as simple as possible (Einstein).

When i put my first steps in ICT, i believe i was 22 then and started as a programmer, we learned about a very simple means to get to know what we want. First let your stakeholder tell about the context wherein the project runs . Maybe a second stakeholder, let him tell his story about his department and the situation he is facing. Forget about discovery in those first talks. Make it (almost) a nice chat. Don't ask questions about the future, just about the current situation, "tell it like it is" (that's a song).Simply let him talk and listen! And listen! You might already undertand the problem then. Evaluate the stories as spoken and write down what the stakeholders told you.

Is it that difficult then to mark the verbs in color number 1 and the nouns in color number 2? When you are a good writer, the stories tell you what happens (verb) with what subject (noun). Nice start for discovery? This should at least reduce the "re-interviewing" on the same subjects and asking questions twiice. Or, as Stephen Covey once said: "First understand, then be understood".

Kind regards,

Wilco Charité
Independent Business Analyst and Requirements Engineer

Only registered users may post comments.

Modern Analyst Blog Latests

Jarett Hailes

Three Audacious Goals for Business Analysts in 2013

As we start a new year many of us will take the time to reflect on our accomplishments from 2012 and plan our goals for 2013. We can set small or large goals. goals that will be accomplished quickly or could take several years. For 2013, I think Business Analysts should look to go beyond our traditional boundaries and set audacious goals. Merriam-...

Howard Podeswa

Hey IIBA, What’s Up With That?

Recently, I was asked by the IIBA to present a talk at one of their chapter meetings. I am reprinting here my response to that invitation in the hope that it will begin a conversation with fellow EEPs and BAs about an area of great concern to the profession. Hi xx …. Regarding the IIBA talk, there is another issue that I am considering. It's p...

Adrian M.

BA ABCs: “C” is for Class Diagram

Continuing the ABC series for Business Analysts, Howard Podeswa created the next installment titled "BA ABCs: “C” is for Class Diagram" as an article rather than a blog post. You can find the article here: BA ABCs: “C” is for Class Diagram Here are the previous two posts: BA ABCs: “A” is for Activity Diagram BA ABCs: “B” is for BPMN