Business analyst, these are the reasons your project will succeed

By Adriana Beal

Let’s face it, lots of software projects continue to fail every year, even after so many advancements in the theory and practice of software development and business analysis. As a coach and mentor of business analysts, I’m often presented with many horror stories, such as:

Image credit: Duncan Allen

Image credit: Duncan Allen

  • A internal software project that seemed to be going well until the day the BA offered a demo of the solution to the project stakeholders only to hear that a big miss would prevent the solution from going live until an expensive architectural change was implemented.
  • A customer-facing application that passed UAT but got hundreds of support tickets submitted on the first week because an enhancement caused a common task performed by users to go from requiring one click to multiple steps to complete.
  • More than 50% of the functionality included in a release remained unused, while change requests continued to be submitted, indicating that the team heavily over invested in new features when they could be optimizing existing workflows.

Why is failure so common? What can be done about it?

After working on countless complex software projects that delivered great business value, here’s what I learned about the reasons for a project to succeed:

Reason #1: You do your homework

As the person responsible for the solution requirements, you need to develop a deep knowledge of the business needs your solution is supposed to address. A workshop with stakeholders where you put up sticky notes on walls won’t cut it. A series of interviews in which you ask a series of yes-or-no questions, or the interviewer evades your probing questions and say, “here’s what I want” won’t cut it. Focusing your attention on individual features as opposed to how your solution will fit into the day-to-day activities of your end users won’t cut it.

Specifying a winning solution requires investing sufficient time to analyze the problem and the constraints around it, and to understand quality as the customer sees it. While a mediocre BA may spend lots of time defining requirements for a solution full of bells and whistles based on how he or she defines quality, a successful BAs dedicates time to investigating what capability are truly valued by customers–which may be entirely different from what they *say* they want, as illustrated in this diagram by David J Bland:

productdeathcycle.

It all starts with asking the right questions to the right people. Successful BAs do their homework to truly understand who their key stakeholders are (from the people writing the check to the ones who will have to use the application to perform their job), and learn in detail what job the software is being hired to do for these audiences. They also put significant effort into determining what initial hypotheses they need to validate during the analysis phase in order to avoid negative surprises when the solution is finally deployed.

Reason #2: You see the value of storytelling

Successful BAs see the power of storytelling. They’ll spend hours looking for a shorthand story that will make their ideas memorable, because they understand that using stories to communicate ideas helps their audience retain and commit to the message they want to deliver.

Let’s say a stakeholder is insisting that you add a calendar feature to the capabilities of a content management system you’re specifying. You’ve done your homework, and speaking to various user groups determined that, without integration with Outlook (the email application the company uses), no one will want to use the calendar, because it would be a pain to manage two separate calendars. After concluding that Outlook integration is out of question due to time and budget constraints, you have the difficult task of convincing the stakeholder that his “pet feature” is not going to produce any value and therefore should be left out of scope. Instead of just giving the requester the facts you’ve compiled, you’d know to start the conversation describing how Sally from Marketing would get frustrated and abandon the calendar once she realized she was having to input each of her planned Facebook campaigns twice. Why is this important? Because we’re human beings, and that means we are influenced by far more than hard data. Storytelling helps us appeal to the emotional mind that needs to be convinced along with people’s rational mind.

Reason #3: You understand the importance of building relationships and becoming a good influencer

In order to succeed as a change agent, a business analyst often needs to rely on the power of influence to gain access to the right stakeholders, postpone a deadline when more time is required to fully understand the problem or solution space, or get an opportunity to present her recommendations to the real decision-makers.

Successful BAs never try to “sell” their ideas “up the chain” until they have paved the road forward by developing relationships, allies, and supporters for their proposals at the lower levels of the organization. They know how to sell their ideas in private, welcoming input and advice from various sources in order to get them to develop a sense of co-ownership. They make people care by appealing to the things that matter to them, transforming their stakeholders into charged up supporters that help move their agenda forward.

# # #

BAs who consistently deliver successful projects aren’t just lucky. Because they did their homework, they have an ironclad case for their specifications. Because they spent time developing a story to go with their recommendations, they have a much easier time getting their ideas heard. And because they they’ve found and nurtured allies in different parts of the organization, they’ve turned colleagues into allies invested in moving their agenda forward.

About the Author

Adriana Beal has developed a successful career in business analysis and product management, having lead the investigation of business problems, defined winning solutions, and written requirements documents for a large number complex software projects. She is also the coach of Crafting Better Requirements, a program that has helped hundreds of business analysts improve their requirements documentation and communication skills, and the author of the ebook Measuring the Performance of Business Analysts,, which has been adopted by dozens of BA managers interested in improving the performance measurement systems in their organizations. Her next ebook, designed to help BAs struggling with getting the right information to analyze and use to specify their solutions, will be called Tested Stakeholder Interviewing Methods for Business Analysts

Author Archive Page

2 Comments

  1. Very well explained!
    I see exactly like you described, it requires a lot of soft skills, and a lot of time invested in 1 on 1 sessions to get buy-in. And of course the open ear to collect inputs all the time plus the filter to include only what brings value, all of these are so critical! And yet they can only be learned through experience.

    1. Hi, Ferran,

      Thanks for taking the time to comment! Indeed, only with deliberate practice a business analyst can become really good at extracting insights from stakeholders, distilling them into the right set of requirements, and proactively steering their projects in the right direction. It requires a lot of dedication and persistence, but also leads to more interesting and challenging projects an the admiration of managers, colleagues and recruiters, so it’s definitely worth the time investment :-).

Post a Comment

Your email address will not be published. Required fields are marked *