Skip to main content

Tag: Business Analysis

KISSing Complexity Goodbye

As I was reviewing the presentations from this year’s Building Business Capability conference, I kept running into slides that looked like the graphic below to describe frameworks which model how organizations operate (the details have been left intentionally blank to protect the innocent):

Hailes Nov18
The Everything Framework

In this one example there was no less than 13 different model components and 25 relationships defined!

One of the recurring themes I heard from presenters and attendees alike was the challenge in demonstrating the value of business analysis and related activities to their organization, particularly with business architecture initiatives. I think part of the challenge lies in trying to use big, elaborate frameworks to describe anything and everything within an organization. Sometimes we think we’ve developed the ultimate map of our organizations, but it just serves to confuse our audience when we try and have a conversation with them. It can be hard to explain, much less understand.

Complexity – the conversation killer Watch video here

Instead of trying to have every possible model and view of our organizations, why not focus on using what is effective and relevant for our audience and eliminate the rest. One of the primary purposes of modeling is to facilitate a shared vision of the present and/or the future, which supports informed decision making and improves change outcomes. The more complex we make the model the harder it is for all stakeholders, from executives to front line staff to solution experts, to get on the same page.

Every organization is different, so no one set of models is appropriate for everyone. Here is a sample of the types of models I usually use as a starting point with clients:

  • People: Org charts and stakeholder/actor/persona matrices
  • Capabilities/Processes: (Non-compliant) BPMN diagrams
  • Information: Entity-relationship diagrams, sometimes data flow diagrams, business rules catalogue
  • Technology: Systems catalogue mapped to the information each system manages and the processes it supports
  • Requirements: Text, diagrams, mockups/prototypes

This is the starting point that I use for everything from developing business cases to assessing solution performance. These are by no means the only models that can be used to maintain and communicate this information; it’s all about finding what works best with your stakeholders to achieve that shared vision and reduce the noise in your conversations.

So, what part of your business analysis practice do you consider overly complex? What challenges do you encounter due to the complexity? What can you do to simplify or eliminate items that are not having their desired effect?

Don’t forget to leave your comments below.

The BA Role: Has it really changed in the last 15 years?

As I tweet my latest BA adventures, I ask Siri to find the best restaurants near my hotel, Skype with friends in Mexico, and order my favorite bottles of Napa Valley wine on Amazon, I can’t help but be amazed by how much technology has saturated my life in the last 15 years.

Internet, email, mobile devices, “the cloud” and social media have transformed the personal and professional lives of a huge portion of our world’s population in such a short amount of time.

Visionaries like Bill Gates, Steve Jobs, Jeff Bezos, etc. get most of the media credit for the technology explosion, but instead of focusing on their undoubtedly awesome leadership, I often find myself thinking about project teams. I think about the thousands of programmers, project managers, architects, testers, and of course business analysts—that move the vision to reality.

Given this technology explosion, one would expect that the tools, processes and procedures used to deliver technology have evolved dramatically in the past 15 years as well.

What do you think? Has project life changed in the last 15 years? A lot, a little or not at all? When focusing on the BA role, have the primary functions of the BA evolved? Have BA tools and techniques changed? Have the deliverables changed?

Have the mindset and behaviors changed?

Here are a few thoughts about how project life has changed and how those changes impact the BA role:

Higher Stakes

Whether a project delivers solutions to internal or external customers, the stakes are higher in 2014 than they were in the 1990s. In the past, system and process errors often had manual back-up procedures. The people around then still remembered what the business rules and logic are.

Now, we are so dependent on technology, that, in many cases, business shuts down when the system does not work— orders don’t process, inventory does not move, money doesn’t flow, customers/employees jump ship.

These high stakes impact the BA role in the following ways:

  • Accurate requirements become even more important than in the past as customers and operations are impacted more when requirements are missed.
  • Contingency plans for key functions become critical to protect employee/customer relationships.
  • BAs become risk managers and need to effectively communicate risks, dependencies, and constraints so that projects do not move forward with bugs, gaps or inefficiencies that will compromise the value of the solution being implemented.
  • The partnership between BAs and QA (test teams) needs to be stronger. BAs need to help QA prioritize test cases and provide context and expected results for key test cases.
  • The partnership between PM and BA needs to be stronger than ever, both managing key aspects of value, risk, and complexity impacting how both roles work with stakeholders and manage scope and priorities.
  • A competitive environment in most industries that changes quicker than most project can keep up. This means high stakes if teams cannot flex to the changes, BAs need to be able to adapt and work with changing requirements to ensure the most value is delivered.

Increased Complexity

Fifteen years ago, most BAs were probably working on in-house software/process projects that involved 2-3 systems and a multitude of manual paper procedures, supporting a single business unit or product. The entire project team probably shared space on one floor (or even one large room) and many of the stakeholders were just a few floors away. BAs often grew to understand systems and processes so well, they did not need extensive assistance from subject matter experts.

Business and project complexity grows as companies expand and merge, and it’s happening more often and faster than before. In many cases, dozens of systems interact, integrations and interfaces are critical and complex, users expect more form systems, and BAs gather information from people across the country and even across the globe.

Increased complexity pushes BAs to:

  • Strengthen their elicitation techniques to account for the immense amount of information complexity, and cross-functional connections; amounts no single person can possibly keep up with as their own knowledge base.
  • Transform elicitation skills and techniques to discover requirements that are unknown when the project starts. Helping the team discover requirements they did not know they had, but add immense value to the changing landscape.
  • Strengthen analysis techniques to make the critical connections between functions, processes, rules, data and user experience end to end.
  • Increase the use of collaboration techniques. In the past, solutions may have been more obvious. Now defining solutions for complex systems requires meaningful collaboration from a diverse group of stakeholders who are rarely in the same city.
  • Strengthen their facilitation techniques to help stakeholders focus, prioritize, and discover requirements as we learn together.

More vendor package software

Packaged software purchases from third-party vendors also add complexity to projects. Organizations assume packaged software solutions offer reduced costs and efficient implementation and are surprised when project delivery is not seamless.

As organizations expand their use of packaged software, BAs must:

  • Define vendor roles and responsibilities, especially understanding the role the vendor BA and client BA. The vendor BA’s role is to be a functional expert of the vendor application, functions and options. The client BA needs to be the voice of what the user and process goals and business rules are to meet the solution objectives.
  • Quickly build strong and trusting relationships with vendors, yet keeping vendors accountable for bringing options and alternatives to realize requirements.
  • Understand and evaluate vendor requirements strategies, and options to meet requirements. Escalate any related issues that would impact solution value.
  • Quickly map current systems/processes to packaged software process/functions. Understand and communicate gaps and changes to stakeholders. Prototype, pilot and test quickly to understand requirements and designs fully.
  • Understand when to leverage vendor knowledge and when to leverage business knowledge to ensure value from the package.

Less time to do requirements

Time and cost have always been focus of solution delivery. Organizations apply strong pressure on their project teams to deliver solutions faster. Our stakeholders have less time too, which means we need to alter our practices to work more efficiently.

In recent years, this pressure has resulted in tighter timelines for business analysis and requirements. With increased complexity and shorter timelines in 2014, BAs need to:

  • Reevaluate BA practices and techniques to maximize efficiency.
  • Reevaluate how we use meeting time, collaborate more, and in smaller groups to get work done.
  • Reevaluate how we document requirements; watch our level of detail for each audience; document in pieces and context rather than big requirements documents.
  • More alignment to other projects needed to integrate value across solutions.
  • Understand and communicate solution priorities and risks; base the requirements and testing plans accordingly.
  • Ask for more time if needed with a solid plan in place to provide value to the stakeholders, and identified risks in business terms if time is not allocated.

Agile Approach

In the 1990s, most BAs worked in a traditional waterfall environment where templates were the norm and the software development life cycle was clearly defined with a regimented organization-wide or application release schedule.

Many organizations continue to operate in this fashion, but more organizations are trending to using an Agile or hybrid approach to deliver solutions.

The role of the BA in projects using an Agile or hybrid approach can be a bit ambiguous, but in general this Agile or hybrid approach compliments a movement toward more collaboration and flexibility in solution delivery, and less focus on SDLC process.

BAs working on projects using an Agile or hybrid approach need to:

  • Utilize techniques that inspire collaboration and meaningful dialogue to generate effective and innovative solutions.
  • Understand their role and how it adds value to the solution delivery.
  • Understand timing and deliverables may change, but mindset and what we do as a BA does not.
  • Advocate for the value they add to the project.
  • Let go of role definition based on governance processes and focus on the essence, value, and goal of what you do as a BA.

How has your BA role changed over the years? Are you still generating 100+ page BRDs?

Don’t forget to leave your comments below.

I Am Not David Blaine

“Hello. I am not David Blaine. Nor am I Penn and Teller or Miss Cleo. I am a Business Analyst, and I am here to ask questions and get to better understanding of your business and needs. I am not here to read your minds or predict your requirement changes 72 months from now.”

Do you ever feel the need to start conversations off like this with your business partners? I feel that way all the time. And I certainly do not think I am alone in that feeling.

Like anyone else, business partners tend to be completely caught-up in their own world. They know their business like, well, the back of their hand. Skipping steps, information or needs that should be a factor in future design or program functionality happens and it is not done on purpose by any means. This is just a side effect of knowing an area so well and forgetting that outsiders do not have the same tribal knowledge. Remember, often times, Business Analysts are brought in to work on a singular project and business owners often have multiple projects going on at once. What might be majority of a Business Analyst work may be a tiny part of the business partner’s day. This is true of any industry and any methodology. Being Agile or Waterfall or Kanban is not a free pass on experiencing these pains.

Is there a way to avoid this situation? The short and true answer is NO; requirements will be missed and you will not find out every possible detail of their job that you should probably be aware of. Unless you are in fact a magician with telepathic powers. If that is the case, then please set-up a conference and teach us all your skills! So how can Business Analyst work to combat this inevitable situation? Among the many different tips or tricks, below are the three most common.

Job Shadowing

One way to overcome this is to job shadow your business partners. Not just speaking with the SME (Subject Matter Expert). Sit down with the actual business end user of the software or program. Who uses the application every day? Who would notice a change the most? Sitting down with the SME’s is critical and should never, ever be overlooked. But often times, our conversations tend to stop with the SME’s and leadership. Take a few hours at the beginning of the project and get into the weeds and get the perspective and opinions of the end users. I ask to be trained like a new person joining the team that you want doing the job on their own in the next 48 hours. Ask ‘why’ and ‘how come’ often and keep strategy and future state in-mind. Ask them thought provoking questions that they might not have ever thought about. Go back to them throughout the project and get their opinions. Show them mock-ups and story boards. An awesome side effect of doing this is you can end up with a person or a team that will be more than willing to help QA work later. And – BONUS – you get some nitty-gritty information that SME’s and leadership might have overlooked.

Write it Down

Sometimes, business partners need help remembering what they said was a ‘must have.’ This can be especially true if you use the Waterfall methodology. They may remember a conversation having Outcome A when you remember it having Outcome B. How can this be avoided? Take. Good. Notes. Do not rely solely on your memory or the memory of those around you. Write it all down. Things to consider in your notes:

  • The meeting or discussion date
  • The attendees and contributors
  • The topic at hand
  • Key pieces of information and decisions made
  • Who is following-up on what and when are the follow-up’s due back to the group

This does not mean you have to write down everything that was said. Remember, you need to be listening and participating more than writing. After you have cleaned-up your notes a bit, email them to the group. That way they can help correct any confusion and they have a record of the discussion and decision too. This will be a win in your corner when business changes their mind or contradict themselves down the road when discussing requirements and acceptance criteria. In a way, having all the information written out, shared with the group and saved allows you to be a pseudo Miss Cleo. I mean, you are predicting that they will forget what they said six weeks ago.

Ask..and Ask Again

More often than not, we are put on a project that covers a business area we are not familiar with. This is especially true if you are a consultant going into a new client every six to nine months. The great thing about this model of work is that you learn a lot about many different areas. Your breath of skill gets wider and that can lead to more opportunity for long term growth in your career. At the same time, it can leave you feeling a bit frustrated. It is important to keep in mind that you are learning another group’s work (or multiple groups work) and having to understand a job they have taken years to master. Always ask the questions until you truly understand. Never assume something works one way or is there for a certain reason. Do not be afraid to admit to your business partners ‘I do not understand. Can you please explain it to me again?’ They will be willing and, if they seem irritated, just reassure them that the better you understand this in the beginning, the better their technical solution will be. You cannot write requirements, acceptance criteria, project charters or anything else unless you have a firm understanding of the business and their needs.

You are not a mind reader that can zap information out of your business partner’s head. You can, however, anticipate certain behaviors. You can anticipate business SME’s and leadership having a ton on their plate and juggling multiple projects. You can anticipate they will not think of everything that needs to go into a project’s requirements and that they will change their minds on requirements, especially if the project is over an extended period of time. Last but not least, you can anticipate you not understanding everything in the business. Do not go out and by a crystal ball. Instead, take the time to implement certain behavior in your own routine that will help you and the project. Talk to more than just the SME; get to know the the end users. Get their opinions and input. This will make them feel more connected to the project and what you are changing. It will also help you find out details that leadership might overlook. Write down your discussions and key information. We cannot expect to keep everything in our brains and expect others to remember conversations in the same way. Be sure to send your notes to the group so that they have the same information you have. And never be afraid to ask the questions to your business as often as you need. The end result will be a better project or product because you have more details to work with. No project or product change is flawless; but following these three simple steps and remembering that you are not a mind reader will go a long way.

Don’t forget to leave your comments below.

Requirements Come in Many Forms

ferrer sept23sm“What’s in a name? That which we call a rose 
By any other name would smell as sweet.”
– William Shakespeare, Romeo and Juliet
“You say po-tay-toe, I say po-tah-toe……..You say to-may-toe, I say to-mah-toe…..
let’s call the whole thing off!”
– George and Ira Gershwin, Shall We Dance or Quit This Project?
 
Requirements come in many forms. For concepts slipp’ry ‘twixt our brains
Goals and visions, points of pain. Needs and wants, gaps versus norms
Approaches, scope and upside gains. Costs and plans, assumptions named

A business case, with risks in place. Analysis to gray cells whisked
Away in meetings, don’t explain. Don’t make us think – it’s HARD in rhyme
And only then transitions? — tsk!

Look and feel pushed to design. Test quality at rollout time
And if performance is not so keen? Don’t forget the root cause blame
Change requests, poor user training. So many words, what DO they mean?
– Marcos Ferrer, CBAP

Let’s use the BABOK 2.0 requirements definitions to decide what words mean (yay standards). BABOK recognizes 5 major requirements types:

  • Business Requirements
  • Stakeholder Requirements
  • Solution Requirements Functional
  • Solution Requirements Non-Functional (don’t tempt your users to agree here)

Transition Requirements

We’ll take a simple, yet frustrating example. An executive wants to organize all of the workers tasks around how much time it takes to do the task. The idea is to do more tasks by doing the quick ones first (don’t laugh – if you haven’t run into stuff like this you are a lucky BA, but may lack skill from lack of exposure).

What is wrong with this requirement? If your answer is “nothing”, you don’t have to read the rest. If you aren’t sure, keep reading. If you can articulate exactly what is wrong and why, you should be writing this blog.

Let’s break this requirement out into BABOK categories, across ALL the requirements types and levels.

Step one: What is the executive’s “requirement” in BABOK?

First and foremost, it is a “stakeholder” requirement, and requires some kind of analysis (thought) to make it into a “real” requirement. According to BABOK the “requirement” is “stated” and/or confirmed (“You really said that? – OK, got it”)

Step two: What kind of analysis?

We might consider breaking the statement down into more detail – what are the tasks and how long does each one take. This is the naïve analyst (naïve IT analyst) approach, and will lead to a failed implementation if not stopped immediately.

The business analyst approach is to consider the business requirement that is driving the stakeholder “requirement”. SO, what is the business requirement analysis that might help fix the stakeholder “requirement” (save it or build it – you are running out of time.

Maybe the business requirement is a vision: “Let’s do shortest tasks first so we can get more work done.”

NOPE – that doesn’t help – restating the stakeholder requirement as a vision leaves us where we were, and even BABOK says that “visions” are the least likely “requirements” to be ongoing / valid as stated.

Maybe the business requirement is a business need: “We need to do shortest tasks first in order to get more work done.”

ICK – again, restating the stakeholder requirement as a “business need” didn’t move the ball – we are still stuck with organizing tasks in an “overly simple” (to be kind) way OR getting into a fight with a stakeholder.

Maybe the business requirement is a capability gap: “We can’t get enough work done because we are not able to organize shortest tasks first.”

Phooey – this doesn’t help, because even though it is true (we are not able to figure out which tasks are shortest, and hence can’t do them first) it is not clear that filling this gap will result in a winning system.

Maybe the business requirement is a business solution approach, as in “Let’s get more work done by doing shortest tasks first”.

Hmmm… this might be better, if only because it shows that:

  1. We want to get more work done (or at least the executive does).
  2. We can use the approach of doing shortest tasks first.

NOW we have some analysis – we broke the stakeholder requirement into TWO parts – a business solution approach and another part. The other part – is it also a requirement?

BABOK offers solution scope business requirements, as in “The business solution shall get more work done.”

Nope – I have seen such requirements, and yet calling them “solution scope” is off.

BABOK offers business case requirements, as in “Organizing tasks to do shortest first will accomplish 10% more tasks in the same amount of time.”

This sounds like what the executive is imagining, but notice that the statement above is NOT a business case and hence is not a business case requirement. The statement is a “justification” statement with no evidence or analytical cost vs. benefit computation. It is, as stated, simply another stakeholder “requirement” – a statement of stakeholder thinking minus any serious attempt to prove feasibility or estimate payback.

To make this into a “business case” requirement would suggest making an actual business case, including feasibility (what are the shortest tasks – what happens if we try them first – what are the longest tasks, and their relation to the short ones?). I for one am in favor, and yet I know that if I insist on a business case it sounds like I am questioning the executive’s thinking, who (theoretically) is responsible for due diligence before writing checks for projects.

Again, NO GOOD, unless:

  • We don’t like the executive and want to be mouthy (demand the business case and avoid the executive by getting fired or whatever)
  • We intend to build whatever we think without discussing it and hence risking conflict
  • We intend to build what the executive seems to have asked for (that’s right – when IT builds what you tell them to build it might mean that “you asked for it” and how words don’t mean what they mean, be trilingual! and what’s more that the IT team figures you deserved “it”.
  1. You are an IT genius even though you chose to go into “people work” like management, or sales and got B’s (C’s?) in math.
  2. IT doesn’t like you enough to do what is right even though you won’t listen
  3. IT knows from experience that if you see any deviation from your exact instructions you will pitch a fit, and they gave up trying years ago., and are prepared to

We are out of business requirements, and surely we don’t want “Let’s do shortest tasks first to get more work done” to be a Solution requirement (functional or “quality” non-functional) or a Transition requirement.

What is the answer? How do you present the stakeholder requirement to “Let’s organize the system around “shortest tasks” first in order to get more work done.” In such a way that it opens discussion instead of shutting down communication and trust with the (very excited at the brilliance of her idea) executive?

Answer in the comments below for a chance to write your own blog in this very space (yes, with editorial help) and have fun, fearless BA readers!

Don’t forget to leave your comments below.

How to Ask the Right Questions: Part 2: Know What to Ask

The right question is the one that gets you the right answer.
Therefore you need to know what answer you are after before you start questioning.

The more we know the more clearly we realize what we don’t know.
– Dietrich Dorner

What You Don’t Know Can’t Hurt You

I have heard that particular phrase for nearly all my life. Generally it seemed to be a way of avoiding the acquisition of new information for some reason, or a way of minimizing the impact of failure to obtain the information being sought. One thing I learned about that supposed truism: what you don’t know can hurt you.

Perhaps this lack of knowledge will not hurt you now, but in the end it is what you don’t know now that ends up causing the problems. And thus the Mystique of the Right Question arises: we need that Right Question to identify the information we don’t know before it causes problems.

First, let’s look at the big picture of interrogation. Assuming that the reason for asking questions is to get information, usually information we don’t know, we can start by dividing the universe of information into the information we know and the information that we don’t know. The apparent goal of asking questions then is to increase the amount of information we know. A successful question, the Right Question, is one which moves the information from the realm of what we know we don’t know into the domain of what we do know. This matrix helps illustrate the process.

  Know Don’t Know
Know Facts Questions
Don’t Know Expereince Assumptions

In other words:

What you know you know are the facts: the information you have already received and verified. We don’t generally ask questions about the information we know except to gain confirmation. A confirmation question in general might be considered a Right Question. When information is confirmed, the answer is valuable and when the answer does not confirm what you already know (or think you know) the information is equally as valuable if not more so. (The issue in asking for confirmation is in avoiding the Confirmation Bias. We’ll talk about that in the next segment.)

What you know you don’t know are the questions: questions that will give you the information to turn what you don’t know into what you know. To a degree, any question you ask here that produces an understandable answer can be considered a Right Question.

What you don’t know that you know is experience: the knowledge that you have that is inherent based on what you learned previously and is now embedded in your memory or subconscious. We don’t generally ask questions in this category because we simply are not aware of the questions to ask, and the responders don’t answer the questions with this level of detail because their experience is second nature and automatic. However, some questions you ask result in an answer that triggers your previous experience and that experience will help you evaluate the applicability and veracity of the answer. In this case we might consider such a question as a Right Question.

What you don’t know that you don’t know are assumptions. You might think you know, but the knowledge is not actually based on facts. In some cases you think something is a fact because someone gave you the information, but the information they gave you was based on their assumption and you are not aware of it. Questions are not asked in this situation because we are assuming that the information we don’t know we don’t know is in fact information that we do know and therefore, facts. We believe that we are in the first quadrant, when we are not. Questions that clarify and disabuse us of our erroneous assumptions are definitely Right Questions.

This last category is where many business analysts feel they didn’t ask the right questions because that information which turned out to be wrong or misleading was incorporated into the product and ended up causing problems in the end.

Getting More Information

One of the obstacles to asking the Right Question is a lack of planning. Most business analysts do prepare some form of question to ask the person they are interviewing or to throw on the table during an information gathering session. However, the questions usually are rote, and determined by the responder rather than the business analyst. In other words, we decide WHO we are going to talk to and then decide WHAT we are going to ask them. This is backwards if we are indeed interested in asking the Right Question.

When you focus on getting the right answers rather than trying to figure out what the right question is to ask, the questions occur by themselves, almost magically. But first you have to define what will be the right answers. You may even find that you can get the right answers without even asking a question.

You might throw a wide net and just ask any somewhat relevant question and hope that the answers will steer you in the right direction, or you can determine in advance what information you need to know to solve the problem and ask specific questions designed to get you that information.

The typical approach for the business analyst in the information gathering, or elicitation, phase might be as follows:

You get the assignment to solve a problem. You meet with the problem owner, sponsor, customer or whoever wants the problem solved or is paying for it. That person gives you a briefing about the issues and suggests you talk to several people and directs you to them. You dutifully call and make appointments with the several people, or you have a meeting with them. You may prepare some questions ahead of time, perhaps mentally. You go into the meeting expecting them to tell you all about what they want, what the problems are and what they want you to do about it, so preparing a list of questions seems a waste of time and effort, because after all you were directed to these people because they presumably have the answers.. The right questions in this case might fall into the category of “what do you need?” Or “what do you want?” [1]

If, in fact, this is an appropriate way to identify or solve problems, then there is no concern about asking the “right” question. Any question will do that gets the designated responder to talk. And the business analyst need just record the answers accurately. However, as many of you realize, the person you have been told to talk to may not actually know the situation, much less the answers, probably has not spent any time formally defining the situation or the solution, maybe distracted during the conversation, and at best will give you their one solution. Most importantly, from the business analyst’s perspective, there is no analysis of response if we assume that the responder has all the answers regardless of our questions.

To ask the right questions business analyst has to take control of the entire elicitation or investigation process, and seek the information that the business analyst needs and not settle for the information defined by someone else.

Plan to ask the Right Questions

You can increase the probability that you will ask the right questions (that is, get the right answers) by defining an information gathering plan

Reporters, investigators, journalists, authors of nonfiction books, and even those professional interviewers who bring celebrities to tears with their pointed questions, all start with a plan to gather the information to achieve their respective objectives: a news story, the guilty perpetrator, background for their book, or that specific question or set of questions that will generate a response that will increase ratings.

It makes sense that if you want to be sure to ask the right question to plan to ask the right question.

The information gathering plan, and informal document maintained by the business analyst for the business analyst (or team of business analysts) consists of four parts, which can be created in a matter of minutes at the beginning of elicitation phase. The four parts are

  1. What information do you need to understand the problem or the problem domain?
  2. Where are you going to get that information? Where is it most likely located and/or who might have it?
  3. How are you going to acquire the information, by what means?
  4. In what order are you going to collect the information?

The information gathering plan starts by listing what we need to know to achieve our objective: a list of questions and categories of information that, when taken together, will provide the right answers and pretty much guarantee that you ask the Right Questions.

Note that it is not a matter of defining the specific questions were going to ask, and agonizing over which ones are right. It is more a matter of creating a frame within which you can conduct your elicitation. You want to make it easier to ask the Right Question.

This brings us back to the original premise that it is not question that is “right”, but information produced by the question that is “right”.

Below is an example of part of an information gathering plan for an accounts payable system. Since the project involves streamlining the data flow for Accounts Payable to speed up the overall process, the initial focus is on the data. So the first people we want to speak to are the Accounts Payable manager, and the purchasing manager. We decide to have an interview with at least one of these two stakeholders. This will give us a general overview of the process from a strategic perspective, as well as defining any constraints associated with the data flow. Then we want to get more specific and look at the content of the current tables used by the Accounts Payable system. We can review the data dictionary for the Accounts Payable database and likely talk to the database administrator to clear up any questions we might have. This plan helps us organize our information gathering process and increase the chances that you will ask the right questions. [1]

What Information Source Method Sequence
The layout of the current vendor tables

Data Dictionary

Database Administrator

Read

Interview

2
What does the overall A/P voucher process look like

Accounts Payable Policies and procedures manual

Charley and/or member of voucher entry team

Read

Observation &
Interview or meeting

4
What is the process to do vendor entry Vendor entry clerk Observation & Interview 3
What is the data that goes into computing the payment terms for vendors Accounts Payable manager
Purchasing manager
Interview 1

The Information gathering session

How do you know that your interview or information gathering session was successful?

Do you feel it was successful because there was a lot of interaction? Was it successful because you ended on time? Was it successful because you got answers to all your questions? Is it because you asked the Right Question? How do you gauge success in elicitation?

I submit that the measure of success in any information gathering session is whether you achieved your objective in that session. You have to know what you wish to accomplish in each and every information gathering session. Setting clear objectives for gathering information increases the chances that the session will generate the information you are seeking to define the problem or solution, and to ask better questions.

Identifying the objective for each information gathering session is fairly simple if you have an information gathering plan. The topic or question on the plan is the objective for the individual information gathering session. For example, referring back to the information gathering plan table, we can set as our objective for the first interview. We have with the Accounts Payable manager to determine what data goes into computing payment terms for vendors. We will plan our interview with questions that will generate answers that will achieve our objective. When we walk out of the interview with an understanding of the data necessary to compute vendor payment terms, we can deem our interview a success. And we will know we asked the Right Questions.

There is more to asking the Right Question, though. We can know what we want to ask but then fumble the question during the information gathering session. In many cases the question “How do I ask the Right Question?” is not about choosing the Right Question to ask, but in How to ask it to ensure getting the Right Answer. That is the topic of the next installment.

Don’t forget to leave your comments below.

References
[1] Blais, Business Analysis: Best Practices for Success, John Wiley, 2011