The difference between an average and a high-performing business analyst

When asked to describe their role, many business analysts working on customer-facing software products or internal information systems use terms like “liaison”, “bridge”, “communication line”, and “translator”, typically referring to work they do to make sure “what the business has in mind for a computerized system is accurately understood by the technical team”.

This interpretation of the BA job is very limiting. It comes with an implied assumption that someone on the business side has done the proper analysis of the business problem, and the job of the BA is limited to finding a common language and ensuring the objectives between the two groups are aligned so that the need communicated by the business can be fulfilled by the IT or software engineering team.

Every time I started a position involving business analysis, I took a different approach, making my #1 job not develop requirements that translated the business and user needs into a technical solution, but to make sure all software solutions I worked on had a clear business motivation in sync with the business strategy.

This shift in perspective can quickly take you from a reactive to a more proactive position in your organization. Here’s an example to illustrate the difference:

Jim, the average BA

Tom, the business stakeholder: “Hi, Jim! We just received a report from the customer success team showing that we have a large number of customers complaning about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jim, the average BA: “Sure, Tom! Let me get right to work.”

Jim goes talk to the development team, discovers that the Orders Placed page takes between 8 and 12 seconds to download, and that with some significant work, can have its latency reduced to 4-6 second. He then writes the requirement:

“The Orders page shall download completely within 6 seconds over a 20 Mbps or faster Internet connection.”

Tom signs off on the requirement, and the work is handed to the development and testing teams. Two months later, the change goes live, but with little impact to the business in terms of customer satisfaction or retention. What went wrong?

Jane, the high-performng BA

Tom, the business stakeholder: “Hi, Jane! We just received a report from the customer success team showing that we have a large number of customers complaining about the latency of the Orders Placed page. It’s imperative that we fix this issue so we can increase customer satisfaction. Can you make sure the IT team makes the Orders Placed page run faster?”

Jane, the high-performing BA: “Sure, Tom! Can I look for a 15-min slot on your calendar for us to go over your findings and make sure I have all the information I need to proceed?”

Tom, the business stakeholder: “That works, thanks!”.

Jane talks to Tom to gather more information. She also schedules some time with the head of the customer success team and the system’s tech lead to better understand the context of the complaints received, and learns the following:

  • Only customers using the old version of the application are complaining that the Orders Placed page is too slow.
  • The latency of the Orders Placed page has not changed between the old and the new version. What changed was simply that the new version uses incremental rendering to start displaying content as it becomes available, rather than waiting to display the complete page only after it’s fully downloaded. Even though in the new version the customer still has to wait until the page is entirely downloaded in order to interact with it and get the information they need, the perception of slowness is no longer there.
  • The customers in the old version are legacy customers who aren’t considered “ideal customers” for the business. Their lack of commitment to upgrade to the new version is just one more sign they’re not extracting enough value from the relationship to remain customers in the long run.
  • The current focus of the business is to increase satisfaction and retention rates among its  group of “ideal customers”, who are already in the new version and happy with the performance of the Orders Placed page.
  • The chief complaint within the “ideal customers” group is not that the Orders Placed is too slow, but rather that the information offered about the estimated delivery time is often wrong.

Armed with all this information, Jane can go back to Tom with a better diagnosis of the problem.

Jane, the high-performing BA: “Tom. looks like making the Orders Placed page run faster is not going to help you achieve your business objectives. Here’s what I learned [ summarizes the key points from her investigation ], and here’s how I recommend we proceed…”.

Jane can now work with Tom on a plan to increase the accuracy of the estimated delivery time. Any changes that are required in the system to achieve this objective (e.g., querying the shipping carriers more often, refreshing the EDT more often) can be tackled by the developers who would otherwise be busy making the page load faster with little to no impact to the desired business outcomes.

# # #

When a BA is doing only reactive work, he or she is more likely to have people questioning the need for the role. After all, why can’t Tom the business stakeholder go directly talk to Jeff the developer about “making the Orders Placed page faster”?

The more proactive your work becomes, the less risk you face of your job being considered superfluous. A business analyst can deliver incredible value to an organization by going beyond understanding and translating the wants and desires of the business stakeholders to technical stakeholders. High-performing BAs also avoid the risk unnecessary scope creep that reactive BAs constantly face. You’ll know you’ve become a high-performing BA when you’re helping the business answer two fundamental questions before getting into “solution mode”:

  • What is the real problem to be solved here?
  • Is this problem even worth solving?

 

# # #

Interested in getting better at problem definition?

Register to our free email course “Understanding the problem: A key step to being a successful problem-solver” using this form.

It’s time for business analysts to add machine learning to their “bag of tricks”

                                                                                               

Are you tired of hearing about machine learning and “the artificial intelligence revolution”? Or perhaps just dismissive of the topic, thinking it’s not relevant outside of the realm of Amazon and Google or a team of data scientists working for a Fortune 500 company? Well, it’s time to change your mindset and recognize that machine learning is another powerful tool that business analysts can add to their “bag of tricks” as they look for new ways to deliver value to their organization.

With the proliferation of open source tools, as well commercially available applications that hide most of the complexity of building a prediction model, it’s getting easier and easier to use machine learning to help solve all sorts of business problems. The applications are endless. To preserve the confidentiality of proprietary information, I can’t use any real-life example from my consulting practice. Instead, I’ll illustrate the possibilities using a simulated project based on a real dataset released as a companion for the paper Explaining the Product Range Effect in Purchase Data by Pennacchioli, D., Coscia, M., Rinzivillo, S., Pedreschi, D. and Giannotti, F., . In BigData, 2013. (If you’d like to play with the same data, you can find it here.)

The dataset contains purchase data aggregated by customer from January 2007 to December 2011 for five supermarkets owned by Coop, one of the largest Italian retail distribution company. It includes variables such as the distance between the customer’s house and the closest and farthest store locations (which may carry different items), the average unit prices of the products purchased by the customer, the total amount of items purchased, and the price paid for each purchase during the time span covered.

Simulated Case Study

A multi-unit enterprise is interested in expanding its line of products to attract more “high value customers” in a specific geographic area where there it has five stores. The company uses a loyalty card to track the patterns of consumption of each registered customer and classify as “high value” the ones who spend $5,000 or more per year across the five stores, assigning them a “VIP” status.

A business analyst on the IT team is assigned to write the requirements for a solution that will allow the company to create and execute a survey to collect the preferences from the “VIP” customers of the five stores. These preferences will inform the decision of which new items to carry in the stores to increase customer loyalty and share of wallet among those top customers. As the BA gathers information from the stakeholders and internal databases to inform the requirements for the project, she learns that the company has 60,365 registered customers with a label of “VIP” or “Regular” assigned to them. Out of these 60,365 labeled customers, 18,278 have “VIP” status. An additional set of 8,103 customers are still unlabeled, as their use of the loyalty card is more recent. This set includes both brand new customers and existing customers convinced by a recent marketing campaign to register to the loyalty program for which the company doesn’t have yet enough purchase history collected for label assignment based on the existing rule.

The BA decides to see if it’s possible to find any reliable patterns to identify “VIPs” among these 8,103 customers with a shorter purchase history in order to expand the number of people invited to take the customer survey, so more data is available to generate insights and the preferences of top customers just adhering to the loyalty program can be taken into account. After extracting the records of the 60,365 labeled customers from the loyalty system, she uses R Studio (an open source tool that makes it easier to use the open source statistical language R) to make sense of the data.

She does some variable selection and transformation, and splits the resulting dataset into two sets, one for “training” the model (42,255 records, 70% of the available data), and another for testing the model accuracy with “unseen data”(18,109 records). She then uses a supervised learning algorithm to analyze the training data and produce an inferred function that can be used for mapping new examples of “VIP” customers.

To find out if she trained a good model, the BA looks at statistics provided by R including Accuracy (90%) and Kappa (77%), and checks the model against the training and test datasets. The following table shows how well the model performed with new observations (the test set with labeled customers not used to train the model). The correct predictions are the ones in the diagonal line from top-left to bottom-right. Our test set has 12,619 “Regular” customers, with 11,729 (92%) being correctly labeled by the model. The test set also has 5,490 “VIP” customers, with 4,624 (84%) classified as such. The error (misclassification rate) is 9.7%, consistent with the performance achieved by the model with the training data.

Additional steps could have been taken to improve the model: test a different algorithm (extremely easy to do using the R package caret), find a better combination of predictors to feed into the model, and so forth. But since the business is not dealing with a problem in which false positives or false negatives would cause any harm, the BA decides that the model is good enough for the intended purpose. She can now apply the model to predict the status of customers in the unlabeled set using predictors like average purchase cost, and flag the ones assigned the “VIP” class to participate on the survey.

The figure below shows a partial depiction of the resulting decision tree used to classify customers as “Regular” or “VIP”. The number within parentheses in the end nodes represent # of observations / # of observations in the wrong class in the training set of 42,255 observations. For example, the end node with a red border at the center of the diagram has 7,590 customers assigned to the class “VIP”,  with 546 of those incorrectly assigned to that class.

Note how not all predictors of “VIP” (high spending) status are obvious. Even though we’d expect customers with a lower average purchase (less than $7.91, top left node of the tree)  to be “Regular” (lower spending), some of the behavior of “Regular” customers is far from intuitive. For example, one might expect that customers with an average purchase greater than $7.91 and average product price above $ 7.13 would be higher spenders (“VIP” class), but in the training set, 1,204 of those are “Regular” customers, and only 33 are “VIP” (see far left end node with red border). In the full dataset of labeled customers, 89% of customers with this profile are “Regular” (i.e., spend less than $5,000 in the stores per year).

It’s also interesting to see that “maximum distance to a store” is a more important predictor than “minimum distance to a store” (metrics provided by R show that on a scale of zero to 100, “maximum distance of a mile or less” has importance 98.11, and “minimum distance of a mile or less” has 84.15). Discoveries like this would be hard to identify without the help of machine learning, and can raise issues more important than the business originally meant to address.

As a result of this quick exercise, based on the attributes that the model found to have the strongest predictive power (average purchase amount, average product price, and maximum distance from the customer’s home to one of the five stores), the company is now capable of flagging more potentially “high-value” customers to invite to respond the survey.

Instead of merely writing the requirements for a solution that would enable the company to survey customers already flagged as “VIP”, the BA contributed with additional value to the project by allowing the survey to be extended to more customers who, based on the identified predictors, are likely to be in the same “high value” category as the “VIP” customers that the company wants to hear from. The survey results from the two groups of customers (“true VIPs”, and “predicted VIPs”) could be kept separate and compared to check if they seem consistent before being consolidated to inform the company’s decision-making process.

If the model helps the business achieve its objectives,  it can continue to “learn” as more customer data becomes available, with benefits in terms of accuracy and identification of new customer behavior that may start to develop over time.

# # #

As seen in the case study above, machine learning can exploit fundamental correlations between a variable of interest at a certain future time and other correlated metrics at a current or historical time, and predict the future state of the variable with some accuracy. There are myriad situations when predictive analytics can help business analysts solve business problems or improve the quality of their solution. From analyzing data from a CRM system to understand the drivers of customer churn to using web crawling data to predict which mobile device doctors would feel more comfortable using before making a large purchase decision, the applications are endless. And with the proliferation of free learning resources and open source applications, there is no excuse for ignoring these powerful tools and techniques that can dramatically improve the impact of business analysis in your organization.

 # # #

Ready to jump into the predictive analytics bandwagon?

Here are some good resources to help you get started:

How to Run Your First Classifier in Weka

Practical Data Science with R

Need help getting your team ready to use predictive analytics methods that are appropriate to your issues without feeling intimidated or producing misleading insights that don’t add value?

Get in touch and we’ll be happy to help you accelerate your journey to becoming a data-driven or data-inspired organization.

* * *

 Photo credit: O’Reilly Conferences (Creative Commons)

A BA asks: when replacing a system, how much do you need to care about the as-is state?

A BA asks:

During IT project implementations, how easy is it to determine the level of the (AS-IS ) detail required? Do you prefer the solution (TO-BE ) be informed by the AS-IS or rather should it be independent of the current set up? As IT professional do you think we dwell too much on the past and fail to solve the issue or we fix our own problems leaving the real pains (challenges) experienced by business?

There are two aspects of developing a superior solution that need to be taken into account here:

  1. The need to investigate the real problem to be solved, rather than focusing on the solution that exists today and reproducing it in the new set up at the risk of replicating inefficiencies from the past.
  2. The need to understand what exists today and why it was built in a certain way so that you don’t end up removing from the new solution critical pieces that turn out to be required to fully solve the business problem.

Imagine that you’re working on the requirements to replace a system used for routing support requests to the appropriate support staff members. In the legacy application, you have a screen where a manager looks at the list of new tickets and decide who to assign the work to based on the level of complexity and other attributes.

In the new system, the assignment of tickets may very well be automatized using business rules or even machine learning. In that case, the as-is process of displaying a list of tickets pending assignment would be replaced by an automated process. Still, it’s important to interview the managers making the manual assignment about their as-is process (e.g., to understand the considerations they make to select the right support person to work on a ticket so that this knowledge can be used to specify the optimal automated solution in the new system). Likewise, the managers should be interviewed about the to-be process (e.g., to understand the concerns they may have with the automatic assignment and elicit information that may lead to new requirements such as the need to allow a manager to override the system assignment based on human judgment or knowledge the system doesn’t have, like when an employee calls to say he’s taking a sick day and his tickets need to be reassigned).

So the answer to this question is, when replacing a legacy system, you should make sure you understand 1) how things work today; 2) why they work a certain way (which could be “no good reason, we’ve always done things like way” or “there is this very important reason why we use a three-digit code to identify the urgency of a ticket even though two digits would suffice). This is how you equip yourself with the knowledge to determine which portions of the as-is process can be eliminated or improved, and which ones needs to stay to ensure the business needs are properly met.

Sure, there are things in the as-is process that you may not need to investigate too deeply (for example, the exact screen of the system used to input each type of information). But anything related to the steps involved in the process, how often certain functions of the system are used, the alternative paths used in the process, need to be understood in a decent level of detail in order to mitigate the risk of missing critical requirements that if ignored would cause the to-be system to fail to meet the business needs.

Photo credit: JoniVan Bogaert

How do you know when a feature customers are asking for is worth building?

One thing I like about digital products is that this kind of product is never finished. Not only they can continue to change over time, change is often critical to keep the product relevant in the market as technology and expectations evolve. For example, a web-based ride sharing application requiring people to plan their ride one day in advance could be extremely popular before the arrival of smartphones, and quickly become irrelevant once it’s possible to open a mobile app and send a request for a ride that a driver nearby can instantly accept.

Yet, something I hear often from startup founders in the digital product space is how uncertain and “gut feeling based” their process to decide what to build next is. And even founders of highly successful startups who are still in charge of product decisions, when interviewed by podcasters interested in learning their secrets to growth, typically describe their decision-making process as something imprecise and opinion-based rather than systematic and evidence-based.

The problem here is that, when you don’t have a solid framework to answer the question, What is the next most important thing to spend engineering time on?, sooner or later you’ll end up falling into one of these traps:

  • Ignoring customer input and building an idea the CEO fell in love with that turns out nobody is interested in using or paying for.
  • Meeting customer requests to the letter and ending up with a “me-too” product, or a bloated product that frustrates users, or a new feature that customers said they would love but now renders their well-established workflows useless.
  • Listening to recommendations of “power users” or “early adopters” and creating a product of limited appeal to your larger audience.

In a recent article for LinkedIn, I gave an example of a time when I almost fell into the trap of listening too closely to customer input (being saved by Eric Sylvia, a colleague from the customer success team who knew better than accepting at face value the feedback received from multiple customers):

I was working as a product manager for a software product that was receiving a significant amount of complaints about response time. Users would often write to customer support to express their dissatisfaction with the time that a page took to finish loading the first time after they opened the application. Some users would also point out that one of our main competitors (which offered the same capability in a free version of their product, making it relatively easy for them to compare) had a much faster load time.

As a product manager with a technical background, my first reaction was to go talk to the engineers to better understand the constraints to make the page load faster. Not Eric! Despite also having a technical background, he didn’t take anything for granted. Eric went through the trouble of setting up the exact same scenario in both our product and the free version of the competitor’s, and timed how long it took for each page to load.

Turns out that our product loaded faster. Upon further investigation, it became clear that our software created the perception of being slower to load because of an animated loading icon that was kept in display while the system retrieved the content. The competitor’s product simply showed the static elements of the page, with a blank space where the content was being loaded. This is a fantastic example of sweating the right small stuff. Before jumping to the idea of making the page faster, this colleague decided to check whether we had identified the right problem to solve–which in fact we hadn’t. In reality, instead of requiring a high-cost, high-effort solution to try and reduce latency on a page that had already been optimized for performance, the solution was trivial: just remove the loading icon to eliminate the perception of slowness.

Anthony Ulwick, in his article for HBR called Turn Customer Input into Innovation, offers another illustrative example of the threats facing companies who don’t know how to interpret customer feedback. His example is of a physical product, but the consequences are equally seen in digital products:

There are several concrete dangers of listening to customers too closely. One of these is the tendency to make incremental, rather than bold, improvements that leave the field open for competitors. Kawasaki learned this lesson when it introduced its Jet Ski. At the time, the company dominated the market for recreational watercraft. When it asked users what could be done to improve the Jet Ski’s ride, customers requested extra padding on the vehicle’s sides to make the standing position more comfortable. It never occurred to them to request a seated watercraft. The company focused on giving customers what they asked for, while other manufacturers began to develop seated models that since have bumped Kawasaki—famed for its motorcycles, which are never ridden standing—from its leading market position.

This type of disappointment can be easily avoided if you use an approach like the one I described in this other article: When customers ask for a feature or product enhancements, instead of taking their requests at face value, ask them to explain the context in which they realized they needed the feature, and what is is that they will be able to do when they get their request that they can’t do now.

I don’t know what answers Kawasaki would have gotten from asking these questions to customers asking for extra padding on the sides, but from their initial request I can imagine that the “job” customers were hiring the jetski to perform wasn’t a challenging and rewarding workout (which would be well-served by a standing watercraft), but probably something like touring and taking people for a ride. After understanding the problem space (“I want a more comfortable ride”) it would be easier to form a robust problem-space definition and then evaluate the candidate solutions (extra padding, seated model, etc.) based on their feasibility, cost, and ability to deliver value.

There are different frameworks that you can use to avoid wasting time, money and limited resources on product ideas that turn out not to be valued by customers. The ones that I’ve seen work best focus on getting answers for the following questions:

  • Who am I trying to serve?
  • What set of underserved needs from my target customers do I aspire to meet with my product?
  • What criteria do my target customers use to judge how well their needs and expectations are being met?
  • What potential solutions–obvious and non-obvious(*)–exist to meet my customer needs and preferences?
  • How will my product be better than the others in the market? What unique value will it deliver?

(*) Non-obvious solutions like “removing the loading icon” that a customer would be unlikely to come up with on their own but you can invent after asking customers probing questions to illuminate the problem space.

When your product prioritization process is based on these kinds of questions, it’s much easier to avoid the common traps listed at the top. Instead of talking about features, you’ll be articulating customer needs and desired outcomes. Instead of wondering if a product idea will “fly”, you’ll be describing the value to be delivered to the customer, and objectively measuring the candidate solutions against the benefits they are capable of providing.

It also helps to reframe the question from What should we build next? to What is the next most important thing to spend engineering time on? Sometimes the best opportunity lies not on building a shiny new feature, but on improving response time, or removing unnecessary features that are cluttering the user experience, or redesigning a user flow to make tasks easier to complete. It bears repeating what I wrote in the article Stop Prioritizing Features:

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.

 

Photo credit: Vimal Kumar (Creative Commons)

Get infrequent updates from us






 

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.