Use this simple trick to become a better stakeholder interviewer


In order to excel in their role, business analysts need to be clear on the business goals their project is meant to support, and how success is going to be measured. Yet, oftentimes stakeholders get impatient to kick off a project without first clarifying the strategic direction. The typical consequence is poor requirements definition and waste of time and money building the wrong solution.

The ability to ask the right questions to the right people is a critical competency for any business analyst. The right question asked at the right time can help you get to the bottom of why a solution is needed, what benefits it will bring compared to a different approach, and any potential issues that if left unchecked would create a project roadblock.

There is a simple trick that can drastically improve the type of results you get when you’re trying to elicit information from stakeholders for a software project:

Separate what you need to learn from the questions you ask, and try to get your stakeholder into “storytelling” mode to get to the bottom of the business need.

Let’s say you’ve been assigned to a project that has nebulous objectives. Your first reaction might be to ask your stakeholders, “what are the objectives for this project?”, or “what are the desired outcomes?”. But in reality, it’s likely that your busy stakeholders didn’t spend a lot of time trying to articulate in a few sentences what they are trying to achieve. They’ll be inclined to describe the solution (“the objective is to build an executive dashboard that lets executives monitor our KPIs”) rather than present a well-articulated justification for the project that is clearly defined and aligned with overall business goals.

In order to get better answers for your questions, instead of asking directly, “what is the business motivation for this project?” or, “what business problem are we trying to solve?”, focus on getting your stakeholders to tell you their stories. Here are some examples ofquestions you can use to get your stakeholders into “storytelling mode”:

“OK, let’s imagine the future. Let’s assume for a minute that our solution is live, and let’s talk about a day in the life of someone who uses it.  What will they be able to do then that they can’t do now?

What challenges are you facing that made you decide to build this capability?”

“What happens if we don’t build this solution?”

Notice how this type of question helps your audience take a step back from discussing the solution (e.g., “build an executive dashboard”) to focus on the specific people who will use the solution, and what they’re trying to accomplish  (e.g., “quickly identify performance anomalies without having to wade through lengthy reports”).

Here’s another example. Imagine you’re documenting the process for employees of a company to submit requests for IT purchases (printers, laptops, monitors). You’re trying to figure out what needs to happen before an employee is notified that one of their requests has been denied. In books teaching people how to document a business process, you’ll find advice to ask something like, “what should already have been produced before an employee is notified that his request has been denied?”. That’s a perfectly valid way of stating your question for the purpose of understanding what you need to learn. But it’s not the best way to present the question for your stakeholders, who most likely aren’t trained to think in terms of process models that transform inputs into outputs.

You can reword the question into a narrative to stimulate your stakeholders to get into “storytelling mode” and give you the information you need without getting lost in the details of business process modeling:

“We talked about how an employee request for new equipment can be denied for various reasons: the company is changing providers and want employees to only use a different brand, the department the employee belongs to has exhausted their budget for the quarter, etc. Let’s look at a specific scenario. Imagine that Mary from the Marketing Department submitted a request for a new monitor right before the vendor she selected is removed from the approved list. Can you tell me what, exactly, would happen with Mary’s request at this point?”

By avoiding process modeling jargon (“what should already have been produced before this step happens?”) and framing your question using storytelling, you’re making it easier for the stakeholder to connect the dots from what you’re asking to what they know happens in real life. Instead of having to think in generic terms about the process steps that happen prior to the output “employee notification”, he can think in terms of a real situation to explain the process.

The interviewee could answer your question with something like, “Well, Mary would be automatically notified that her request was denied as soon as the vendor is removed from the list. The ‘request denied’ notification would include instructions on how to resubmit the request after choosing a different brand or model of equipment that’s still in the catalog.” You could then continue probing through storytelling until you had all necessary pieces of information to understand the solution requirements.

When you need to ask a question to clarify a business process or system requirement, remember to make things easier for your subject matter expert, not for yourself. That means never asking jargon-laden questions such as, “What are all the steps an item must go through to achieve the outcome of the workflow?”. Take the time to frame your questions in a way that starts a conversation and gets your stakeholders in the mood to tell you their stories about who the solution is for, what they do now, and how things will change for them later. This is guaranteed to get you much closer to finding the answers you need to specify a winning solution.


Interested in learning more? Tested Stakeholder Interviewing Methods offers a straightforward blueprint for you to get to the bottom of the real business need and demonstrate you value as a business analyst with better requirements.

Stop prioritizing features

By Adriana Beal

What do you think of our process to prioritize new features?

Whenever I hear this question, my first thought is that I don’t even need to look at the process to conclude that it is wrong.


Whether you are working on a small custom software application, or a product sold to millions of customers, your primary focus should never be new features, but rather value creation

We all understand where this obsession with feature prioritization comes from. Managers get nervous when product owners are not writing new requirements and developers are not producing more code. There’s always a pressure to “come up with themes for the next release”, “deliver more user stories per sprint”, and so forth.

Sadly, the fixation on productivity and feature throughput is as likely to lead to  “bloatware”, customer aggravation, and quickly losing relevance in the market, as to produce the expected growth.

The way to avoid this trap is to shift the focus away from feature prioritization and toward desired business outcomes.

What are the top business priorities for your company?

As Richard Rumelt writes in Bad Strategy, Good Strategy,

A leader’s most important responsibility is identifying the biggest challenges to forward progress and devising a coherent approach to overcoming them.

In practice, it’s common for leaders to fail to acknowledge the most important challenges facing the business. They ignore the power of choice, trying to accommodate all types of conflicting demands and interests across the organization.

But good product owners and business analysts demand more from those who lead. They’ll insist on gaining a clearer picture of what fundamental problems the company is trying to address, and will not rest until there’s an agreement on a focused and coordinated set of actions to tackle those problems.

How do these business priorities affect the priorities of the product or project you’re currently working on?

Let’s say you are a product manager in charge of the requirements for the next release of a SaaS (software-as-a-service) application that is offered by your company in a subscription model. And the high stakes challenge facing the business is customer churn: the company is being able to attract a large number of customers to try the software every week, but the majority of them cancel the subscription a few days after registration.

Now, instead of immediately starting to brainstorm new features that could be added to encourage customers to stick around after trying the software, you would dedicate time to understanding the root cause of the problem. You might learn from support tickets and feedback from former customers, that the main reason for customer churn is how difficult the product is to learn and how long it takes to set up.

Armed with this information, you’d be able to prioritize things like user interface redesign and improvements to the onboarding process as the most critical actions to support the goal of reducing customer churn.

Or, imagine you’re a business analyst in charge of an internal application that helps the sales team manage the sales pipeline. And the biggest challenge the sales team is facing is time wasted with unqualified leads, which is slowing sales down. Upon investigation, you may identify the scoring method used to predict the lead’s “likelihood to close” as the top obstacle to qualified leads, and prioritize enhancements to the scoring algorithm to support the goal of making the sales organization more efficient.

Note that in both examples, the deliverables that most contribute to the desired outcomes have nothing to do with building new features. In the first scenario, improvements in usability and the onboarding process could be the best alternatives to reduce customer churn. In the second scenario, improving the lead scoring algorithm might provide the highest impact in helping the sales team spend time only on the leads that are the most sales-ready.

These examples highlight the biggest problem with feature prioritization models: they start from the faulty assumption that the solution to business challenges must reside on new features, when the best opportunities for improvement may be found elsewhere. When you start from the question of where the best opportunities lie, new features become one of many alternatives to achieve the business goals. They’ll be rightfully competing with bug fixes, performance enhancements, process improvement activities, user interface redesign, marketing efforts, and many other actions capable of delivering business outcomes.

An effective prioritization process doesn’t revolve around features and release scope. It starts from shedding light into business goals and advance toward a commitment on the outcomes the team plans to support, before arriving on software features it plans to implement.


Thoughts or comments? Share them on LinkedIn

Photo Credit: Kelly McCarthy

Get infrequent updates from us


Should you pursue a certification in business analysis?


Which business analysis certification do you recommend for my circumstances?
What tips to you have for me to successfully complete my application?

These are two common questions I get from readers. I see it as an undesired side effect of having a successful online training program that earns “PDs or CDUs for IIBA® certification or re-certification, or PDUs/Contact Hours for PMI® certification”. Hopefully posting my answer here will help more people find it and allow them to reach their own conclusions without having to contact me for advice.

With a little bit of research, people would quickly realize that for the most part I’m against certification. This diagram summarizes my thinking in this area:


A curious thing I noticed is that even though a big part of business analysis has to do with leveraging data to drive business results, apparently most BAs will gladly throw their analytical skills out the window when deciding to get a certification. The typical interaction I have with the BAs who write me with these questions could become classical case studies for predictable irrationality.

The exchange goes like this:

Letter writer: “Please help me get certified so I can leave this dead-end job!”

Me: “Well, what evidence do you have that a certification will help you achieve your goal? Are employers in your area asking for certification?”

Letter writer: “Hmm… no, in fact I haven’t seen any job post that mentions it.”

Me: “OK. Do you know anyone who was also struggling to find a better job and succeeded after adding a certification to their resume?”

Letter writer: “No, I actually don’t know anyone who has improved their chances because of certification. But can you help me get mine?

The answer is invariably “no”, for the following reasons:

a) I’m not certified, and would rather change profession than go through the process of documenting my work history and memorizing material to pass a multiple choice test knowing very well that I’ll forget 80% of it right after the exam. It goes without saying that I’m not even qualified to help you with this process.

b) I’m a firm believer in aligning our efforts with the actual need, and in framing the problem correctly before jumping into solution mode. Until you’ve made sure that getting certified is the right means to your end, your job is to get specific about what you want to find out, narrowing down the problem you want to solve with clear phrasing of the question to be addressed, the data to be applied to it, and the possible outcomes.

For example, if you are currently employed as a software developer and thinking of moving into a business analysis job so you can focus more on defining the right thing to build as opposed to just building things right, a good way to frame your problem might be “how do I optimize the use of my limited time to maximize my chances of becoming an attractive candidate for BA job openings in my city?”.

With that problem in mind, you can start collecting and analyzing data that may or may not lead to the conclusion that the certification path is the most efficient and effective for you to become an attractive candidate for local BA job openings.

If you can honestly say you’ve gone through this process and confirmed that certification is the best solution for your problem or opportunity, here’s a great place to get started.

A reader asks: how do I map a business process involving multiple departments with non-existent or variable workflows?

by Adriana Beal


Process mapping is a well-known technique for creating a common vision and shared language for understanding and improving business results. It helps business analysts identify capability gaps, optimize solutions, discover new ways to perform tasks that yield better results, and so on.

Often, though, BAs feel lost when trying to map an as-is business process that nobody seems to fully understand. The solution, again, lies in framing your questions strategically.

For example, if you were trying to document the sales process of a business that doesn’t have a mature sales organization, the question “what is your sales process?” could be met with a blank stare. But if you frame your questions well, you’ll find it much easier to start eliciting the information you need:

“Can you tell me what is the first step a salesperson on your team takes to approach a prospect for the first time, at the beginning of the sales cycle?”

If this question still elicits a vague response (“it varies a lot; we may have received a lead from marketing, or being referred to the prospect by an existing client, etc.”), you can try a different approach, starting from the final step and going backwards toward the beginning of the workflow:

“Let’s start from the other end now. Suppose you have just closed a deal, and the customer already signed the contract. What would have happened immediately before that?”

The answer might be something like, “we send out a proposal for the prospect to review”. Then you continue going back step by step, “OK, and right before you sent out the proposal, what did you do?”.

It’s likely that the stakeholder you’re interviewing will forget some steps in the process they’re trying to describe, and at that point when you can add follow-up questions to start filing the gaps. For example, “wait, you’re saying that right before sending the proposal, you schedule a meeting with the prospect to review your understanding of their problem–I’m going to add here that between these two steps, you have the meeting, and then prepare the proposal to send. Are there any other steps I’m missing here?”.

And what if by talking to different stakeholders you get different answers? In our example, speaking to different salespeople might lead to conflicting information (“I only call people after establishing a relationship via email first” vs. “I start my day by cold calling a list of prospects that the marketing team generated for me the previous day”). But that’s OK; most processes benefit from this type of flexibility, and your documentation can just include the variations found in certain steps.

The big takeaway here is to focus on how people are behaving now. Ask questions about the individual tasks the person has to execute to complete their work, rather than asking them to describe their process or the workflow they use. Most people don’t think in terms of a “process” or “workflow”, but they’ll definitely be able to tell you what steps they have to go through in order to do their job.

# # #

Are you interested in getting better at conducting stakeholder interviews and avoiding the horrible experience of discovering at the end of a project that you missed a critical requirement and caused serious delays and cost overruns?

Check out the recently launched ebook Tested Stakeholder Interviewing Methods for Business Analysts.

Increase the success rate of your software projects by changing your reward system

By Adriana Beal – Jan 2015

Imagine pouring money into building a new software feature or buying a new tool, only to see it ignored by the intended audience. A few recent examples I’ve witnessed:

  • A powerful project management tool chosen by executives based on its ability to provide aggregated project data to help manage overall priorities was quickly abandoned when project managers found the application hard to use.
  • A new mobile app designed to solve a real problem failed to attract buyers.
  • Changes in how a software-as-a-service solution behaved and looked, made to improve the user experience, triggered angry reactions from customers who were happy with the status quo and demanded a rollback.

idea-screening Situations like these are more common than organizations like to admit. Even devotees of agile methods often suffer from the problem, patting themselves on the back when a new release is delivered on time, on budget and with the planned quality, only to realize that they’ve committed the biggest waste of all: building software that the intended audience refuse to use.

After spending 15 years as a consultant helping organizations of all sizes build better software, I’ve come to the conclusion that the easiest way to eliminate this problem is to change the reward system.

We all know that human beings adjust behavior based on the metrics they’re held against. If your company only rewards people who come up with new ideas, or ship software on time, can you trust they will do the right thing, and seek disconfirming information before starting a new project?  For a better success rate, it’s crucial to reward also the people willing to do the hard work that doesn’t come with any guarantees, and doesn’t necessarily ship anything, but offer the highest return on investment:

  • identify solutions that are truly appreciated as value by the people who will use them;
  • analyze the merit of proposed ideas, and reject the ones that can’t produce real value;
  • refuse to add new features to a product just because a competitor has them, and work instead on the aspects that can make a product remarkable, even if it means making it easier to use, or its advanced features easier to access, without adding a single feature.

Currently, not enough of the software process is devoted to understanding the customer/user context and the causalities that drive user adoption. What Peter Drucker used to say remains 100% true: it is foolish for a seller to spend money, time, and effort developing quality as he sees it, for the buyer may not see it that way at all.

If more companies start to reward the behavior that leads to saying no to ideas that don’t match the customer’s definition of value, we should finally start seeing more software projects producing the change the business is seeking.

On the Usefulness of Job Titles

By Adriana Beal – Apr 2015

In his recent article called Why are we still talking about PM vs. BA?, Kupe Kupersmith wrote:

Does a CIO or the business leaders you work with care that independently you have a good BAs or good PMs? No way. They want teams to deliver outcomes that help move the business in the direction they want. You need to consider yourself a team member first. This means you will do what is necessary for team success. Second, think about how you can best help the team succeed. What skills do you bring to the table? Don’t think in terms of I am a Business Analyst and I have a job description listing 15 tasks so that’s what I can bring to the team. Work hard and work unselfishly.

To me, this paragraph is conflating two different things that should be treated separately.

Fact #1: Business leaders and CIOs don’t care about how tasks are allocated among team members, as long as projects achieve the desired outcomes.

In that aspect I’m in total agreement with Kupe. As long as the desired results are achieved, no sane manager is going to care about team configuration and distribution of responsibilities. I’ve worked in highly successful projects whose teams had wildly different team configurations, and am in favor of adaptability and doing what works best for each team.

On the other hand, it shouldn’t follow from this fact that people should just gladly accept any assignments that align with their capabilities, regardless of their interests or what they originally signed up for when they took the job.

Fact #2: Just because a person is capable of performing a task, it doesn’t mean it’s a good idea to make him or her responsible for it.

There are two problems with thinking in terms of capabilities rather than roles when deciding who does what in a project:

First, many organizations don’t understand the contributions business analysts are supposed to bring to the table, and thus expect their analysts to be available to perform a variety of technical and non-technical tasks throughout their projects based on their skill set, often in detriment of the quality of their core deliverables. I’ve lost count of how many BAs came to me to ask for advice on how to prevent the project failure they just experienced from happening again. Invariably, when those BAs describe their failed project, it becomes clear that the analyst was being spread too thin, with insufficient time to dedicate to understanding the business need before being asked to “jump into solution mode” and help with all sorts of project tasks, from identifying data sources to coordinating cross-functional metings.

I firmly believe that a clear, BABOK-like job description for the business analyst role helps avoid this type of problem. Now, there’s nothing wrong with expecting people to pitch in as needed. However, in the absence of a well-defined job description, organizations tend to develop unrealistic expectations of how much time will be required for the business analysis activities to be completed, and fail to allocate additional resources to other project tasks, making the assumption that the BA will have plenty of time to take care of those tasks. Inexperienced BAs often find it difficult to express why they need more time to finish the analysis for their project when a manager insists “the requirements have already been provided by the stakeholders, and you should be free now to help with project execution”. Having a solid job description reduces the need for BAs to constantly having to educate business and technical stakeholders regarding their responsibilities, and defend the amount of time required to perform critical tasks such as understanding business problems, scoping the needs of users, identifying dependencies between requirements, and so forth.

Second, besides the need to consider the impact that additional tasks can have in the quality of a BA’s core deliverables, it’s important to check whether the person would be happy tackling the work. The best BAs I know enjoy the activities related to figuring out “the right thing to build” but are not interested in doing project management, data analysis, coding, quality assurance, and so forth — even when they are the most qualified person on the team in those areas. And this is something that smart organizations know about talent retention: there has to be a balance between organizational mission and self-interest.

At the beginning of my career, I worked for a solution provider as a BA consultant. My job was to go to a client organization and perform business analysis for one or more projects, clarifying business goals and project objectives, identifying business stakeholders, modeling business processes, defining and getting sign off for solution requirements. Nobody expected me to be responsible for project management or QA activities, which kept me happy and focused on delivering value on what I did best. Because there was a clear delineation of what my job was and wasn’t, the team was structured in a way that didn’t have to rely on me doing non-BA activities I was qualified for, such as reporting on development progress or performing quality assurance testing.

Granted, it’s much easier to delineate the type of work you’re going to do for your team in a project-based consulting arrangement. But that’s precisely why job titles and descriptions are important to communicate expectations. In the past, when I was applying to a full time BA job, knowing whether QA or project management was part of the role helped me self-select out of a job, saving future headaches for the hiring manager and myself. Based on skill set alone, I’m perfectly capable of being a project manager, or a QA professional. If I weren’t upfront about disliking the types of tasks associated with these roles, I’d have found myself in situations in which the natural arrangement would be for me to take on those kinds of responsibilities as the project evolved, because it would have been easier than recruiting additional team members. Either the team would resent the fact that I refused to take care of these tasks, or I’d resent accepting it, and would start looking for a transition out. By clarifying role expectations early on, and being honest about the type of contribution I’m capable of and willing to provide for my teams, I’ve helped managers understand resource availability and create structures and accountability systems that allowed me to remain 100% busy with value-adding activities without being required to perform tasks that didn’t align with my career goals.

I disagree with the statement “to assume someone with a title of Project Manager does certain tasks and a person with the Business Analyst title does other tasks is just crazy”. Clearly, I’m not saying employers should treat employees as “rats in a box”, or employees should refuse to help out because a task is not in their job description. But in my experience, self-organization works best when you respect the boundaries of what people are signing up to do for their employer. Otherwise, a talented BA who also is good at data modeling could get “stuck” with doing data mapping work she’s not happy with just because it’s the easiest way for the team to fill the capability gap.

I’m all for going the extra mile for the good of the team, department, or company. But star BAs have enough career capital to be able to successfully control their careers. It’s one thing to expect them to take initiative and move out of their protective job descriptions to cover “white spaces” and reach goals that benefits everyone. It’s another thing to expect them to overcommit, or “work hard and unselfishly” on something they dislike doing just because it’s more convenient for the organization than to find and assign the appropriate team members.

Choosing jobs with descriptions that didn’t include activities I dislike doing on a regular basis didn’t mean I wouldn’t volunteer to do some of these tasks when the situation required. It meant, though, that my employer and I had similar expectations about what type of contribution I was signing up for, and that nobody would be disappointed if I didn’t volunteer to help with testing or progress tracking when I was busy designing business models or managing system requirements for my projects.

What about you? Do you agree with the importance of job descriptions, or are in the camp of ignoring job titles to focus on the skills each team member brings to the table?