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?


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.

Should you pursue a certification in business analysis?


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

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

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


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

The exchange goes like this:

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

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

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

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

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

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

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

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

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

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

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

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

by Adriana Beal


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

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

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

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

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

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

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

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

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

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

# # #

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

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

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

By Adriana Beal – Jan 2015

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

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

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

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

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

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

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

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

On the Usefulness of Job Titles

By Adriana Beal – Apr 2015

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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