How to make sure you’re dealing with the real problem and not just a problem manifestation

In his article Outside-In User Story Example, my favorite product management expert, Scott Sehlhorst, describes how users “almost always fixate on problem manifestations, versus underlying problems”:

 

Problem manifestation Problem
My contact list is missing this person I need to know the identity of this person
My phone does not ring loudly enough I am not noticing incoming phone calls
I need a faster horse I need to get to my destination faster

To explain what it means to switch a product team’s role from “do these things” to “solve these problems”, Scott uses a personal experience of being a part of a messaging conversation on his phone with three other people (a group MMS) and seeing two names and one phone number because one of the participants was not on his Contact List.

A reader asked in the comment section:

Do you have any personal criteria that help you determine whether you are working with a design or intent? The example of “faster horse” vs “get somewhere faster” is good but I am not sure the difference is always going to be that visible. Do you have any personal recommendations on how to determine whether you are dealing with a design?

I’m sure Scott and other successful innovators have powerful approaches to deal with this issue. Here I’m going to share mine.

The secret to going from a “problem manifestation” to the real problem to be solved is to have a process that supports these key principles (the actual steps may vary from company to company, product to product, and team to team):

  • All product and feature ideas are based on customer insights, and address an important need they have.
  • Customer insights are gained not only from interviewing customers, but also observing end-users in action. (If you just listen to what people tell you, you’ll miss important insights.)
  • Feedback from customers is sought all along the way: when you have the idea, a concept, a low-fidelity wireframe, the high-fidelity wireframe, after launch.

To give an example of how this works in practice, I’ll reuse Scott’s example of group text messaging.

Imagine that the experience Scott describes happened to a customer of your messaging app, and this person submitted a request for an enhancement to be able to add people in a group conversation to their contact list. How do you know they’re focusing on a problem manifestation and not the real problem?

1) Have “problem interviews” with your customers

Instead of taking the request at face value, first you’d ask the user to explain the context in which they realized they needed this feature. They may say something like, “well, from time to time I find myself in a text conversation with a group of people, and instead of seeing all their names, some people are displayed as phone numbers, which makes it difficult to know who is participating on the exchange. That’s why I wish I could add these people to my Contact List and start seeing their names instead of numbers.”

You could then reply, “Oh, I see. It looks like your end goal is to have the names of all participants of an group conversation listed on the screen as the exchange happens, so you know who is participating on it–is that right?”

(Customer) “Yes, that’s it!”

(You) “OK. Let’s say the app automatically identified the person for you, and displayed their name instead of their phone number, even if they aren’t on your contact list. Would that solve your problem?”

(Customer) “Yes, as a matter of fact, it would.”

(You) “Got it. And let’s say this person’s name was displayed every time they are part of a group conversation with you, despite the fact they’re not on your Contact List. Would you still want them added there?”

(Customer) “Well, not automatically. If I have the intention of contacting the person directly in the future, then yes. But it’s possible that the person is someone I don’t have a relationship with, and adding them to my Contact List would just clutter it.”

(You) “I see… It sounds like it would be useful for you to, besides seeing the name of everybody who is in the group conversation, know when someone in that conversation is not on your Contact List, and then decide whether to add the person to the list or not. Is that true?”.

(Customer) “Yes! Once the conversation is over, the app could ask me whether I want to add the person to my Contact List, and only do so if I confirm I want it done.”

Note how at the end of this conversation the user is back to thinking in terms of a solution (“the app can ask me if I want to add the person to my Contact List”). Accept the reality that it’s human nature to focus on problem manifestations and candidate solutions, and that it’s your job to redirect the conversation back to the underlying intent.

Even if the customer suggestion ended up being ideal, they’re not going to be thinking of all details, so we’re not trying to design the final solution at this point. It’s quite possible that the same customer who suggested the solution above would become annoyed if the app started asking each time they were on a group conversation with the same person, “Roy Miller is not on your Contact List. Would you Like him to be Added?” without an option to say “No (and don’t ask me again)”.

Every time the customer attempts to describe a solution (“I want to add people from a group conversation to my Contact List”, or “I want to be asked at the end of an group conversation whether I want to add to my Contact List the participants who aren’t there yet”),  you can steer them back to a conversation about their desired outcomes (e.g., know who is in a group conversation, selectively add people on a group conversation to my Contact List when I want to be able to reach out to them), as opposed to how (and when) these outcomes would be achieved.

2) Observe end-users in action

Talking to customers is not enough. It’s also critical to observe the end-user doing the tasks that your product is going to support. If you just listen to what the people tell you, you’ll miss important insights.

In our example, you could observe someone having an group conversation that includes people that aren’t in their Contact List and therefore have their number displayed instead of a name, to see how the interaction happens.

3) Check-in with customer in all stages from problem definition to solution implementation

Drawing a parallel with past real-life projects, first I’d have checked back to customer to see if they agree that these are the two problems they are trying to solve:

  • Know the identity of the people in my group conversation. As a participant in a group conversation, I want to see the names of all identifiable people who are part of the conversation, even when they’re not part of my Contact List.
  • Selectively add people from the conversation to my Contact List. As a participant in a group conversation with people who are not in my Contact List, I want to be given the option to selectively add them to my contact list.

After validating that I had identified the correct problems to solve, and determined that these problems represent high-value market opportunities to pursue, I would develop a concept for how to solve these problems, and check back with the customer to validate that concept. Then I’d check in again when there was a low-fidelity wireframe to show, a high-fidelity wireframe, and after launch.

Throughout the process, we’d be looking at candidate solutions. For the second user story, is it better to update the Contact List and later ask the customer if he wants to keep or discard the new contact? Highlight the names at the end of the conversation and ask whether to add them as a contact? Create a workflow where the users can press names to add them to the Contact List during the conversation? These decisions should be made ahead of implementation as part of the user experience design, taking into account usability, value, feasibility, and costs.

Do you have a different approach to go from “problem manifestation” to “problem” before working on a solution?

If so, share your thoughts (or link to a blog post that fits this topic) in the comments section, so more people can learn from your successes.

 

Photo credit: Chris Devers (Creative Commons)

A reader asks: “how do I motivate myself when my employer treats me as a document writer and not a real BA?”

Even though many BAs continue to be frustrated by a limiting role, the answer hasn’t changed from the time I wrote this article for Modern Analyst with 4 actions that can help you elevate your role:

1. Make sure you understand the type of contribution your role is supposed to provide

2. Don’t wait for permission to start making higher contributions to your projects

3. Balance the time you spend in doing analysis, creating models, and writing documents with effort to demonstrate the “WIIFY” for your stakeholders

4. Advertise your value in subtle ways

Read the full article: Don’t Wait for the Perfect Conditions to Become a Star BA

How to develop confidence in your abilities while still learning a new business domain

Many business analysts fail to achieve top performance while starting to work on a new domain simply because of their fear of making mistakes. I’ve heard analysts freely admit that looking less than competent is what they fear most. “I don’t know what I don’t know” they will tell me, “and in particular in a domain I’m not very familiar with, I’m always afraid I will miss an assumption or an avenue I must address.”

In part 2 of the series being published by Modern Analyst, Adriana Beal shares some tips on

How to develop confidence in your abilities and establish yourself as a valuable team member while still learning a new business domain

(To make sure you get informed when the third article in the series is published, subscribe to our infrequent newsletter.)

 

Developing your BA “superpowers”

 

Few things can help us find work that’s interesting and rewarding than getting really good at a rare and valuable skills that are relevant to the work we do (also known as “superpowers”). For that reason, BealProjects.com recommends a 3-step approach to help you become a “super hero” who thrives as a knowledge worker:

Step 1: Pick one (not two or three) new skill you think would really help you create more value in your organization. 

Step 2: Do some research to find out one effective resource that can help you learn and practice this new skill (links below to some recommended areas of improvement for business analysts).

Step 3:  Eliminate distractions and focus on working your way up the ladder in the skill you selected.

Ready to go? Below are three proven frameworks and a coaching program to help you develop four superpowers that lay the foundation for you to consistently make your work more valuable as a business analyst. Pick one subject, and carefully start to block time for some in-depth work developing the skill:

Superpower #1: Uncover the Real and Underlying Problem or Opportunity That Your Project is Meant to Address (Even When Stakeholders Are Unable to Articulate it for You)

Superpower #2: Consistently Get Stakeholders Engaged in Requirements Discovery (Even When They Say They Are Too Busy and You Should Already Have All You Need)

Superpower #3: Make your Ideas Heard (Even When You’re an Introvert in a World Dominated by Loud Voices)

Superpower #4: Deliver Flawless Software Requirements that Wow Business and Technical Stakeholders

. . .

Consider sharing the link to this page with friends or colleagues who may benefit from this exercise: (bealprojects.com/products/superpower).

. . .

Photo Credit: Eric 

How to stop non-BAs from taking over the requirements work?

question

Photo Credit: Marcello Maria Perongini

A reader asks:

In my organization, it’s common for a business or technical person to take over the requirements documentation task for an internal system without involving one of the business analysts. This is clearly causing quality issues with the final solution, employees frustrated with systems that don’t let them to their work efficiently, etc. I’ve tried talking to my boss about it, but even though he seems to agree with my position, the issue has not been addressed yet. What else can I do to get people to see the importance of having a trained business analysts assigned to each of our software projects?

Some professions, like visual design and business analysis, are plagued by untrained people thinking “What’s the big deal — I could do that myself!”. And the negative consequences are not always apparent to everyone, like underperformance costs, internal systems that are too painful to use, and so forth. But there are definitely things you can do to try to improve the situation.

Here are a few suggestions:

1. Prepare your case. Figure out how to articulate, in layman’s terms, exactly what the problem is when business or technical stakeholders create and document the requirements themselves without the involvement of a trained business analyst capable of going through a more structured requirements discovery process. It may be completely obvious to you why that’s bad, but it’s clearly not obvious to your stakeholders. Find ways to explains the problem in terms people will understand.

2. Identify allies. Once you have an ironclad case as to the importance of BA involvement in software requirements definition, start looking around for colleagues and business leaders who could become supporters. You’re more likely to succeed if you can make it look like the change has been their brilliant idea from the get go. Let them take the spotlight and “sell” the suggestion to the rest of the organization.

3. Find the middle groundRecognize that sometimes it’s legitimate for someone from the business or technical team to write requirements for a minor project. If the BA team is small, unable to get to a simple, lower-priority enhancement project until next month when the business unit needs it sooner, it’s not always bad to have someone who is not a trained business analyst take care of the requirements.

4. When the situation is unavoidable, mitigate its impact. When it’s not possible to prevent non-BAs to do the requirements work, you might be able to mitigate some of the negative impact by providing templates, examples of what good requirements look like, and DOs and DON’Ts (e.g., instructions on how to group user stories or requirements around higher level problems or goals that logically fit together, write requirements in an acceptable way rather than using technical descriptions of how to deliver or build, etc.).  That’s not perfect, but at least if the teams are working from your instructions, their requirements documents are likely to be better than if they start from scratch. You can also enlist the development team to help disseminate best practices and reach out to the BA team for help when they realize they don’t have high-quality requirements to work from.

5. Speak up when you see the issue happening. When you discover a bad rogue requirements document, bring it to your manager’s attention. Let’s say you realize that the requirements written by a financial analyst are in bad shape. Go to your manager and say, “I’ve noticed that the requirements the financial department has written for enhancing their reporting tool are likely to create issues because they didn’t address some important non-functional requirements needed to keep the solution’s response time at acceptable levels. I wonder if there’s a way to ensure one of the business analysts on our team is always involved in this type of initiative that goes beyond minor improvements, to make sure no important requirement is missing for the development work to begin.”

# # #

The one thing that you can do today

As with any organizational change initiative, in order to things done the most important thing is finding allies for your cause (#2). Make an effort at finding, developing and nurturing allies across the organization–and not just people in positions of power.  Develop relationships with these supporters, and remember: allies need to be constantly reminded of how critical their support is. Nurturing your base of allies will dramatically increase your odds of success.

Read also: Follow-up based on readers’ questions and comments 

Acknowledgement: Tom Peters is to be credited for the idea of finding and nurturing allies as one of the most powerful means to create organizational change.
 * * * * *

More from BealProjects.com

Working for or building a startup?

3 big mistakes startup founders make

Interested in becoming the person that your organization wants in a bigger role?

If you have a few years of experience as a BA and are thinking of moving into a lead BA or BA manager position, you can accelerate that process with deliberate learning and practice from the Business Analysis Leadership group.

Smart companies will pay for it if you ask. After all, it’s a high-return investment in the very people who do the work. Not-so-smart companies need to pay attention to Adriana’s advice in this article: CIO: When was the last time you recognized and rewarded your best leaders?

What can managers and BAs do to prove the value of business analysis?

valueExecutives that have first-hand experience with high-quality business analysis don’t need convincing: they are aware of the key role a dedicated business analyst can play in software projects, from separating user “wants” from the underlying true needs to identifying unobvious dependencies before they create issues.

But not all executives have had the experience. And when all business analysts that senior management knows are former users or developers with little experience and no training in business analysis, it can be hard for project leads and program managers to get buy-in for having skilled, dedicated business analysts in their software projects.

But this is a solvable problem. The following steps can help you build the case for adding skilled business analyst to project teams:

Step 1: Collect performance data related to the requirements work

Example of measurements that can be easy to collect and should be capable of painting a clear picture of the value delivered by BAs in software projects:

  • Number of change requests submitted during the development phase and after launch.
  • Quality problems with the solution attributable to poorly understood requirements.
  • Time lost due to the development team being unable to proceed until nebulous or conflicting requirements are clarified (particularly useful when using an offshore development team, as in this case the delays can pile up quickly).
  • Discrepancy between actual delivery date versus requested and promised date.
  • Complaints and compliments received during UAT and post-release.

Measuring these dimensions of performance in different projects may be simpler than you think. For instance, if your company uses a tool like JIRA to capture defects and change requests, labels and filters can be used to quickly extract, for each project, the number of change requests and defects submitted before and after launch that can be attributed to incomplete or incorrect requirements.

Step 2: Segment performance data to compare results

Once you have collected data for multiple projects, organize the results by relevant dimensions, which may include:

  • Project complexity;
  • BA expertise level and involvement level throughout the project;
  • Projects that followed and didn’t follow the proper requirements change management process after the requirements were baselined.

Your measurement should be able to produce crisp findings to convince the business of the positive ROI of following better practices and keeping trained BAs involved throughout each software project. The more complex the project, the easier should be to show the relationship between availability of BA talent and project success.

Even if you don’t have skilled BAs available in the organization to make an internal comparison, it’s useful to start capturing performance data. Through your network you may be able to find an organization with a stronger BA practice willing to share their data, or look for reports from consulting firms to use as a benchmark (at minimum, you should be able to find data around average project length, project rework, and more).

Step 3: Present your findings to the decision-makers in business terms to provide instant justification for training and/or hiring and retaining skilled BA practitioners

Put together a report that focuses on what this all means for internal and external customers and financial outcomes. Do end users complain that the applications they need to use to perform their tasks makes their job harder than it needed be? Are projects being canceled after time and money was wasted building the wrong solution that didn’t address the real business need? Are there bright spots — projects that go unusually well and produce superior business results that can be traced back to the work of a skilled BA? Your analysis of the performance data will go a long way toward convincing executives of the importance of the business analyst role and the ROI of investing in attracting, developing, and retaining BA talent.


Are you a manager of business analysts or a lead BA? Check out our new Business Analysis Leadership group.

Use this simple trick to become a better stakeholder interviewer

chatting

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.

sticky

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:

CBAP

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

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.