Tag: Business Analysis

Requirements Come in Many Forms

Written by Marcos Ferrer on September 22, 2014. Posted in Articles.

“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:

We want to get more work done (or at least the executive does).
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”.

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.
IT doesn’t like you enough to do what is right even though you won’t listen
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

Written by Steve Blais on September 22, 2014. Posted in Articles. 1 Comment on 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

What information do you need to understand the problem or the problem domain?
Where are you going to get that information? Where is it most likely located and/or who might have it?
How are you going to acquire the information, by what means?
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

Practicing Simplicity in Analysis

Written by Santosh Shaastry on September 8, 2014. Posted in Articles.

Have you ever realized that innovations aim for one or more of these – Faster, Better, Cheaper, Sleeker – all these and more, while trying to keep things SIMPLE.

Only a few years ago, if someone told us that huge market existed for tablets it would have sounded presumptuous if not impractical. Tablets have actually replaced desktops and laptops across the world – from Sales representatives to home makers, the user base for tablets is diverse. This is a phenomenon that is worthy of a research to understand how human beings “adapt” and “absorb” simpler designs all the time! Don’t we always wish everything is simple and easy to do? – paying bills, buying groceries, watching a movie, reaching out to a loved one across the world at the touch of a button etc.

Analysts work with business problems and are expected to SIMPLIFY the problem to define a practical solution! After all, why would business folks need “analysts” if the job defining solution is “that” simple? Being one myself, I began on a quest to understand what ‘Simplicity’ actually means (and feels like) when consciously understood and applied to our day to day work. I did research great deal of books & articles that detail the importance of and offered tips to “keep things simple”. “Laws of Simplicity” (by John Maeda) stood out for two reasons: 1) Categorization of different principles in to 10 laws (embodiment of a law itself!); 2) Clear and practical uses of each of these laws.

Here I present my views of some of these “Simplicity Laws” that I found highly beneficial in the process of “Analysis”. I hope the same is true for you as well!

Reduce

Analyzing a business problem requires a thorough research about existing process & practices, emerging trends, competition and current capabilities. This could well lead us into a minefield of information. If not carefully managed, we would be trapped in this minefield and eventually lose out by delivering incorrect or inefficient solution.

Thoughtful reduction of what I call “3D” would help in differentiating the “noise from the sound” and leave us with clear, relevant information

Data which is irrelevant
Discussions (with stakeholders) that are futile
Documentation of every little fact that comes our way

Organize

As we work to identify different solutions for a business problem, variety of information shall be at our disposal. Applying the first law of “Reduce” in the hope to overcome the problem of “Disconnected Data” may not work most of the time, because it only eliminates what we do not need. This is when we must activate our brains to look for patterns in information and assimilate information. This creates a systematic approach to “clear the clutter” and also help us find information when we need it and as we need it! As the book “The Art of Organizing Anything” (by Rosalie Maggio) captures, it is possible to organize anything. Why not organize what we analyze? And organizing information as soon as we find it definitely helps in the long sprint!

Learn

Have you ever been in a meeting in which you did not get what is discussed? I know exactly how it feels – puzzling. Such puzzling could trigger thoughts that range from irritation, helplessness to fear of the unknown! You probably guessed it – domain knowledge is necessary to be a successful analyst but is not the only one. With the barrage of technological innovations happening around us, which I think is great, we must strive to learn “new stuff” all the time. Competition is the other factor that “forces” us to learn something, but that does not cause as much excitement as our proactive ability!

Trust

Ofcourse! If we cannot rely upon our co-workers, nothing would ever get accomplished at the workplace. So the obvious is beside the point. As analyst, we must identify trust-worthy “source of information”. Don’t we use Google to search for most of the information? Do we trust all the 38,10,00,000 results that Google throws up for the word “analysis”? As we gather information, note down the source of that information. Revisit the source (probably while Organizing) to check the allied information, acceptance and authenticity.

If interested, I welcome you to explore the other laws of simplicity and share your valuable thoughts on how the below laws impact analysis OR even do they?!

Time
Differences
Emotions
Failure
Context
The One – that combines three keys: Away, Open and Power

Don’t forget to leave your comments below.

Question Everything About your Business – 7 candid questions that need to be asked

Written by Richard Lannon on September 8, 2014. Posted in Articles. 1 Comment on Question Everything About your Business – 7 candid questions that need to be asked

Good questions are the key to successful planning and decision making. Throughout the business planning process we must consider strategic questions to help us understand the current situation, focus areas and our vision for the future. Strategic planning is an intensive process and should be a team effort – it should not be done in isolation.

A good place to start in the planning process is to focus on ‘what’ questions. What questions are extremely powerful tools for thinking about your business / personal strategy, goals and objectives. The key is to know which questions to ask and to be willing to take a candid look at your business.

Here are seven candid “what” questions that every business leader should ask:

What are the overall strengths and weaknesses of your business?

Strengths and weaknesses exist in all organizations and should include considerations for people, resources, culture, work processes, tools, supply chain, financial situation, etc. The list goes on and on. The important thing here is to start the process by first looking at your organization and its resources.

What are the overall opportunities and threats to your business?

Focus here on your external world, the things you cannot control but must be aware of. Some items could include a market shift, retirement and succession, competitive movement and changes, the global business climate (local, national or international), obstacles or climate and weather effects. We often miss the opportunity to do environmental scanning. Look outside your office to truly understand the opportunities and threats to your organization.

What political, economic, social and technological conditions impact your business?

What’s happening in your local business scene (economics)? Is there a product or service that people want or need to buy? Is technology impacting your team and their need for training? What important social change will impact the business? Are you developing leaders for tomorrow? Every answer should lead to another question. Dig deep, exhaust yourself and find people to help you through the process.

What do you want to achieve, protect, avoid and eliminate?

This question contains all the elements of risk planning. There are always things we want to achieve, protect, avoid and eliminate on a personal, team or organizational basis. What are they? Identify as many as possible and make a list. Examples vary but could include increased sales, keeping an established portfolio, avoiding trouble or accidents, establishing an employee health program or helping people drop a few pounds. The point here is that whatever is identified must be relevant to your business and its challenges.

What are the key challenges you face today, tomorrow and in the distant future?

We’re in an era where we must be predictive and adaptive business leaders and professionals. Strategic planning is about timeframes with past, present and future considerations. Establish what your work world should look like with timeframes. Planning used to focus on 3 to 5 year cycles. That has changed. Now we must keep our eye on short-term road trips with long term implications.

Where are we and how did we get here?

This question is a pure honesty question. Success and failures in every business should be reviewed periodically. It is used to establish your present situation and to help you accept complete responsibility and accountability for it. No blame-storming allowed. Outside forces might have contributed, but at some point decisions were made to set your direction. As a business leader, you were either active or reactive and there were consequences. Capture it, leverage it and be prepared to let it go.

What key initiatives are going to be placed on the strategic agenda of your business? Why are they important?

At some point you need to focus and make key decisions that will make a difference in your business. Building your strategic agenda is a different type of challenge and may require another approach. This may take ‘why’ questions, questions that focus on benefits and value. Before adding anything to your strategic agenda you must first clearly establish the benefits and values of those items.

Being honest about your business, the organization and its people is a challenge. When strategic planning it’s important to remove yourself from the natural tendency of coming up with solutions. Establishing solutions is the action part of planning. Consider engaging an expert strategic facilitator to help. Remember that you don’t plan to fail, you fail to plan and planning requires asking the right questions.

Don’t forget to leave your commments below.

The Value of Business Analysis: Identifying Business Need

Written by Aaron Whittenberger on August 25, 2014. Posted in Articles.

One of the critical roles of the Business Analyst (BA), or Enterprise Analyst (EA), in the area of Enterprise Analysis is to identify business need. Many business professionals make the mistake of thinking that since it is named Enterprise Analysis, that identifying business need can happen only at the enterprise level. Nothing could be further from the truth; Enterprise Analysis and identifying business need, can happen at the enterprise level, involve multiple lines of business within the organization but not the entire enterprise, and at the business unit level.

There are many factors, or many ways that the business analyst can identify business needs. It can be a result of market research or an identified new opportunity brought about by actions of a vendor or competitor. It could be derived from a strategic goal or initiative of the organization. It could have come from a business user complaint about a current system issue and/or the subsequent Root Cause Analysis. It could also be derived from an Enterprise Analysis activity that the BA performed, such as Capability Gap Analysis, SWOT Analysis or Product Feasibility Analysis.

If this vital role is not performed than the organization would not realize the benefits of identifying some business needs that need to be addressed, possibly gaining greater competitive advantage, possibly achieving strategic goals or taking advantage of an opportunity presented in the market. As you can see this can have a direct effect on the strategic success, and bottom line, of the organization.

Define Business Need

Once identified, the business need should be documented in the Business Case to initiate a project to develop a solution for this business need. This solution may, or may not, involve information technology software development; some solutions are completely a business solution. The business need defines the problem for which the business analyst is attempting to find a solution. The way the business need is defined determines which alternative solutions will be considered, which stakeholders will be consulted and which solution approaches will be evaluated.

Define Problem

Defining business need and defining the problem are two different things. The business need leads to the problem, but both the business need and problem statement needs to be defined and documented. Take for example that you have identified that sales have been decreasing for the past three years. So your business need statement could be “Need increased sales”. What is your problem statement? A root cause analysis uncovered an aging sales force using archaic sales techniques, no new products introduced to the marketplace in three years, competitors introducing products with innovative features, no new marketing campaigns in the last two years, rising costs, and production equipment in need of repair and upgrade.

Leads to the Solution

Now that the true problems have been identified, the enterprise can now initiate separate projects to find solutions for the sales problem, product problem, marketing problem, and production problems; rising costs and production equipment. The team assigned the sales problem can determine if they need to hire younger salespeople, provide sales training on newer techniques, provide better sales support, or implement a new Customer Relationship Management (CRM) system. Likewise, the other project teams will determine proper solutions to their defined problem statement.

One pitfall that many business analysts and project teams fall into is trying to define the business need by the solution. In practice, quite often the business stakeholders define the solution at the start of the project instead of defining the problem statement first. They start with the solution first instead of the problem first. This reduces the solution alternatives that receive consideration and may bring a lesser valuable solution to deployment than what could have been achieved. So starting with the business need, problem statement, and solution scope; then developing alternative solutions will bring the most valuable solution to the organization, and the business analyst’s recommendation, to light.
In our sales problem example above, the organization may have identified slumping sales for three years. Without proper problem statement identification the business team may decide to simply hire more salespeople to increase sales. Without proper root cause analysis, they may hire older salespeople, just like the rest of the sales force they have. None of the true root cause problems get resolved because the team jumped to the solution with identifying the true problems needing addressed.

We all learn from our mistakes, what pitfalls to developing the Business Case have you encountered in your career?

Don’t forget to leave your comments below.