“My job today as a BA is kind of nebulous – for example, we have these requirements signed off but then the developers don’t have the technical information they need, such as which data source to use for a data element the solution will have to import, and they expect the BA to come up with the answer.”
“We are always having to help people understand what a BA does.”
“We recently started iterative development, as our project was way too large and our stakeholders were losing faith as we deployed nothing after 6 years. The project was being driven by our IT organization and not our business. This only changed once I joined the ranks and suggested we start collecting business requirements.”
One would think that these statements come from the last century, but these, and many more I could quote, are from emails I received in 2014 and 2015 from participants of my online course Crafting Better Requirements. It’s hard to believe that in this day and age there’s still so little clarity around the role of a business analyst in IT projects, and so many business analysts still being hired to become a non-programming technical resource, in charge of things like :
- getting technical answers for the delivery team (“the customer type column you need can be extracted from Salesforce”, or “this field used to be called RVU_code in the legacy system”);
- writing “requirements documents” focused on what the development team is going to built (“bulk e-mail tool shall receive messages from the new monitoring application instead of the legacy one”, “the system will ensure that the web content publishing end date is equal to or less than the product limited period end date”) without any opportunity to investigate the underlying business need or organizational processes to be supported, or define the success criteria for the project as a whole.
No wonder so many BAs complain that their role is underappreciated, and that their voices are not heard when they have a recommendation for the business stakeholders or the delivery team. In these types of organizations, explaining the true BA role can be an uphill battle. And even if you’re successful once, things can easily go back to square one once leadership management is replaced, causing the knowledge of the importance of good business analysis to be wiped out, as described in this article I wrote about “IT forgetfulness”.
Fortunately, there are strategies you can use to change the situation. If you find yourself in the position of having to defend your contributions, the need for more time or access to the right stakeholders to do your job well, or the impact of your work for the overall results of your team, here’s what you can do to change the situation:
1. Make sure you understand the type of contribution your role is supposed to provide
As Laura Brandenburg points out in the book Professional Development for Business Analysts, not everyone with the title “business analyst” understands the real job of a BA:
“Many people who consider themselves part of our profession are more focused on documents, activities, and sign-offs, than clarity and alignment. They are more focused on filling a specific set of responsibilities than defining a role that helps drive change in their organization. Some are even more focused on getting by day-to-day than on continuous improvement of their abilities.”
If you want business analysis to be perceived as valuable in your organization, the first step is to understand how it contributes to the overall results. Are you choosing the right initiatives to focus on? If most of your effort goes into creating requirements documents with hundreds of pages, rather than doing the work to understand the business need, the project sponsor’s goals, and the users’ context, you’re missing important perspectives, and most likely failing to add value to the organization’s critical path. Ensure you’re seeing your projects through the eyes of your primary stakeholders, and working across organizational boundaries to build bridges so that all the resources are being applied to solving the right problems. This will guarantee you’re making the types of contributions that generate true value to the organization, and help you develop the credibility and reputation of a person the team can count on for tasks and projects beyond basic BA work.
2. Don’t wait for permission to start making higher contributions to your projects
Many BAs seem to think that they need permission from their superiors to start doing the type of analysis that can truly add value to their organizations. For example, imagine you’ve been tasked with writing the requirements for enhancements for a time tracking system. You don’t need your manager’s formal permission to reach out to the consultants who use the system to track their own time, the managers who use aggregate data from the system to make decisions about resource allocation, and the people responsible for payroll who use the system’s information to calculate wages, to get their input about what needs to be built.
Even if you’re told your job is to simply create a requirements document for the developers based on the change requests already submitted by a project sponsor, nothing prevents you from taking the initiative to talk to the various project stakeholders in order to validate that what’s being asked will truly solve the problem in the best possible way. If you don’t feel you have enough time for a more thorough investigation, arm yourself with good evidence that an extra week will drastically mitigate the risks by allowing you to complete the requirements discovery process in a more effective way.
Find a collective goal you can appeal to, and show your boss and colleagues the problems with not changing (like spending more time later fixing deficiencies in the solution if they don’t give you enough time to explore the problem in depth before completing your requirements). Storytelling can be a powerful way of influencing people; spend time building a case for what you want to change knowing you’ll have more success by telling a story rather than firing off a lecture.
3. Balance the time you spend in doing analysis, creating models, and writing documents with effort to demonstrate the “WIIFY” for your stakeholders
Many BAs complain that they can’t get subject matter experts (SMEs) to care enough about the problem they are trying to solve--they find it hard to keep the SMEs engaged during the requirements discovery process. Typically this means that top management is not doing a good job communicating the importance of the project down the hierarchy, and how it relates to the organizational goals. Not seeing it as a priority, mid-level SMEs won’t feel compelled to participate as much as you would hope for.
What has worked throughout my career is to find a way to convey to those SMEs the “WIIFY” (what’s in it for you). Will the project make their lives easier somehow? Generate any palpable gain for them specifically, as opposed to just to the overall business?
Engaging presentations are powerful tools to “make stakeholders care”. In The Upside of Irrationality”, Chapter 9 -- “On Empathy and Emotion: Why We Respond to One Person Who Needs Help but Not to Many” --, Dan Ariely explains how much easier it is for humans to relate when you are talking about a specific situation (in the case of charity, one suffering person, instead of the number of victims of a huge earthquake). Similar to the empathy for one person in need vs. a large number of victims of a disaster, people find it much easier to relate to something for which they can see palpable impact, rather than just theoretical gains. Smart BAs will try to find one aspect of the system that will provide this type of “local benefit”, and highlight it to the SMEs. Even this local benefit is small compared to the value of the system to the business as a whole, it may be much more convincing because that’s just how we humans react to things.
Comics have helped me single out a situation to demonstrate why a problem needed to be solved, and “tell a story” to persuade people. For instance, instead of simply using statistics of inconsistencies and duplicate data to convince resistant stakeholders of the importance of centralizing employee data, I illustrated the problem with a comic strip showing a manager wasting time trying to set up a cross-functional meeting with people in the organization because they have different names in different systems, such as Rebecca O’Neal and Becky O Neal. The example resonated with the audience, and finally enabled the IT team to get sign-off from the HR group to proceed with the the employee data centralization project.
After you’ve made the WIIFY explicit for stakeholders, it typically becomes much easier to keep them engaged. Now they have a concrete example in their minds of why the current situation needs changing, and will be much more willing to answer questions and make the decisions needed to move the project forward.
Another good strategy is to use a wiki or another shared repository to keep project information, and encourage stakeholders to check it out as you advance in the discovery process. This makes progress much more palpable, and gives your audience more visibility into what it takes to go from a business need to a completely defined, optimal solution. The psychology behind it is similar to the “5-Minute Room Rescue” proposed by Marla Cilley, creator of the Fly Lady self-organizing method. By giving visibility into your progress, you’ll be able to show an immediate payoff for your stakeholders’ efforts. This will start a virtuous cycle of more contribution based on the sense of accomplishment brought by the ability to immediately see the fruits of their work, as opposed to having to wait until the system is finally in production to detect any gains.
4. Advertise your value in subtle ways
Once you’ve begun to make higher contributions to your projects, the next step is to start promoting your work. This is not about bragging about your skills or results, but rather explaining to the company the benefits you’re bringing to the organization, and the advantages of having you involved in higher level work during project justification, prioritization, and initiation, rather than only after vision and scope have already been solidified for your projects.
The idea is to give your results enough visibility to enable you to:
- make a compelling case to management for changing job descriptions and regulations that limit productivity or restrict you from doing the BA work that can bring the most contribution to the business;
- continue to have your perspective heard and your leadership accepted by your team, even as inevitable changes in management happen.
Take note of how fast you’re being able to drive alignment around project objectives and requirements, and how you’ve saved stakeholders time by tracking the results of discussions so the same issues didn’t have to be rehashed over and over. Sit down with your boss to explain how your use of analysis tools allowed you to surface issues in advance to drastically reduce requirements churn. Seek your boss’s blessing to send upper management short memos demonstrating the benefits that quality business analysis can bring to projects, from surfacing problems in proposed initiatives that aren’t likely to produced the expected ROI, to refining and clarifying the business problem in order to improve the quality of the business solution and achieve higher end user satisfaction.
###
Having your work appreciated and recognized requires establishing yourself as someone who contributes to the bottom line. Recognition goes to BAs who increase the value a solution will deliver and reduce the cost to implement such solution, rather than for BAs who merely follows orders to produce well-written requirements specifications.
The key is to provide evidence that your business analysis is reducing project rework (by getting things right the first time); speeding up time-to-market (by avoiding duplicative discussions and answers); and improving the quality of the solutions (by bringing together as much contextual information as possible, rather than relying on what the stakeholders say their need is). If you’re achieving these kinds of results, you shouldn’t have trouble talking about the benefits of your work with your manager and your stakeholders, and starting to develop a virtuous cycle of greater recognition and greater contributions to your organization.
Author: Adriana Beal spent 10 years consulting for Fortune 100 organizations implementing large, complex software projects. She currently works as a product manager for Square Root, an Austin-based tech startup that helps large companies understand what's driving organizational performance, optimize daily operations, and align people's work with company's goals.