Skip to main content

Tag: Business Analysis

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



What does the overall A/P voucher process look like

Accounts Payable Policies and procedures manual

Charley and/or member of voucher entry team


Observation &
Interview or meeting

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.

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

Practicing Simplicity in Analysis

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!


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

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


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!


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!


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

lannon sept8Good 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.