Skip to main content

Author: Laura Brandenburg

5 Ways to Find Missing Requirements

Doesn’t it seem like we can hardly go a day without reading about how missed requirements are leading to incredible amounts of wasted time, energy, and money on information technology projects? I have been on enough projects to know that the statistics are most likely telling a realistic story about how projects get scoped, defined, and delivered, but that they are not necessarily giving a comprehensive account of the situation.

In this article, we’ll look at 5 practices we employ as business analysts to discover hidden requirements, and how organizational pressures, project circumstances, and business analysis processes can negatively impact the outcomes of those techniques, leading to the costly reality of overlooking requirements.

Practice #1 – Requirements Reviews and Buy-In

It is not uncommon to discover dozens of requirements during the final requirements review stage. Walking through a requirements specification, or a portion of a requirements specification, with the goal of being sure everything necessary has been included, almost necessarily uncovers additional information.

When you are getting ready to approve, finalize, or simply be done with a requirement, your stakeholders tend to invest a little extra time and energy in being sure it is right.

But the review process only works if you establish the importance of the review, making it very clear that once we review this document, development will begin based on what is inside it, and that means the cost of change starts to go up.

This stage of the process can go wrong if stakeholders do not show up to requirements meetings, do not understand the enormity of what approval means, or do not feel bought into the project in the first place. It also does not work if a critical stakeholder is not invited in the first place, which leads us to the next way to find missing requirements.

Practice #2 – Include All Possible Stakeholders

While it is never a great idea to invite dozens of people to a single requirements meeting, good business analysts ensure that all relevant stakeholders are looped into the project and given the opportunity to share their concerns, needs, and expectations. If you are consistently neglecting requirements in a particular area, identify a new stakeholder from that area to include on your project teams.

This part of the process can go wrong when business analysts are assigned to specific areas of the business and projects are assumed to only impact that area. It can also go wrong when managers assign uninformed stakeholders to projects or refuse to assign stakeholders at all. Organizational politics can also be a factor, say, if a business sponsor purposely excludes one or more stakeholders from the project.

Practice #3 – Apply Analysis Techniques

While stakeholders are the source of many requirements, other requirements are discovered by analyzing the stakeholder needs and discovering implications. The result of good business analysis is a complete view of the solution. For example, every field on a report must be entered into the system at some point, whether directly by a user or by some sort of data feed.

Unfortunately, well-intentioned templates can negatively impact the analysis process. When you are capturing requirements in long lists, it is difficult to make all of the necessary links between requirements. As luck would have it, the same is true if you are capturing requirements in a substantial product backlog. You need analysis models, such as business processes, use cases, or data models, to help you discover the missing connections.

What’s more, a large template can give the false sense of security. Just because you have filled out a 30 page template with twice as many sections does not necessarily mean that you have discovered all of the requirements!

Practice #4 – Invest (Just) Enough Time

Good requirements take time from stakeholders, from technical experts, and from someone performing business analysis activities. Part of being a business analyst is putting together a reasonable plan that explains the steps you will go through to elicit, analyze, and confirm the requirements, identify who needs to be involved in each step, and about how long each step will take.

While it might seem counter-intuitive, more time is not always better. Business and technology contexts change quickly. Investing too much time in the requirements process can mean that your early requirements become stale before they are even ready to be implemented. Minimizing missed requirements comes from crafting a plan that secures just enough time to discover the best possible requirements given the project goals and constraints.

However, it is not uncommon for a business analyst to be assigned a mere week or two to finish requirements before development on a sizable project is targeted to start. When organizations shrink project timelines, or the time dedicated to the requirements aspect of the project, without also shrinking the scope of the business analysis effort, then we nearly guarantee we will miss requirements.

Practice #5 – Start at the Beginning

You cannot solve a problem that you do not understand. You cannot address a business need that has not been defined. You cannot sell a product that the customer does not want.

Business analysts understand the big picture of the project, which includes why the organization is investing in the project and the over-arching goal to be accomplished.

I would venture to say that the vast majority of missing requirements are actually missed at the very beginning of the project. If no one inside the project compels the business community to be clear about exactly what problem needs to be solved, or if a business sponsor resists a business analyst’s typical “why” line of questioning, the entire team is working like a ship without a rudder. You run the risk of chasing rabbits down holes and discovering a lot of requirements that are irrelevant, while overlooking the big important requirements that should be staring you right in the face.

Create More Positive Outcomes

As business analysts, we can expect to face circumstances that, if left unchecked, will cause us to miss requirements. It is up to us to clarify the conditions under which we can do our best work and improve our contexts so we can improve our requirements.

Don’t forget to leave your comments below.

From QA to BA: 4 Effective Ways To Demonstrate You Are Ready to Be a Business Analyst

FEATUREJune26thWhen I think about my transition into business analysis, the first thought that comes to mind is a hallway conversation. A senior BA on the business analyst team approached me on my way back to my desk and mentioned a new position was opening in the department. She recommended I apply.

My first response was “well, there are a lot of projects in QA right now; it might not be a good time.” And her much wiser response to me was “Well, then when will be a good time? This is a good opportunity and probably more money too.” It was good advice. After a lot of soul searching about whether or not moving into business analysis was really a good career move for me, I acted on her advice and applied to the internal position. About a month later, after just a year and a half on the QA team, I found myself moving from the second floor to the third to sit at my new desk with the BA team.

But in all reality, my career transition into business analysis did not start with that conversation. And while at the time I saw this conversation as a lucky one, I had been unknowingly approaching my QA role as an aspiring business analyst.

In what follows I’ll share what I now understand to be the key activities that helped me demonstrate I was ready to be a business analyst.

#1: Participating in Requirements Review Meetings

I wasn’t immediately invited to attend requirements review meetings. But I was interested in learning more so I asked to be invited. Again. And Again. And Again. Finally I got myself on the invite list. I listened and learned and eventually started to speak up.

I found errors. I questioned details. I helped make the requirements better by being a critical consumer. From the perspective of the business analysts leading these meetings, I was probably erring on the side of being annoying. I have no doubt that this factored at least some degree into that hallway conversation.

I can just hear them scheming: Maybe if we get her on our side, she’ll stop pestering us in our meetings!

My advice to you: Get yourself invited to meetings, especially those related to requirements. Listen first, learn everything you can, and then make yourself as much of a pest as you dare!

#2: Creating a New Process

The particular role I was assigned to was one of those business activities that everyone realized was necessary but no one wanted to own. The type of testing I did had been bunted around from department to department for the last few years. The last person in my role had left after 6 months.

After being hired, I took ownership of the work and created a process. Over time I took things further by organizing related work done by other departments and automating part of the process. By the time I left things were running smoothly and my work could be transitioned to someone else in the department.

My advice to you: Take ownership of work that’s laden with solvable problems and that no one wants. You’ll face very little resistance and get noticed when things get better quickly.

#3: Jumping Into the Liaison Role

Testers tend to be liaisons. When a business stakeholder finds an error, it’s logical for someone from the test team to validate it, write it up, and submit it to the software team for fixing. There was another gap here in my organization and I jumped in to fill it. Before long I was talking to developers from different offices to explain the problems we were seeing and validating issues submitted from our user acceptance test process. 

My immature communication skills were put to the test and over time I learned how to communicate with developers as well as how to communicate technical information back to business stakeholders.

My advice to you: Jump into the fray and communicate. It doesn’t matter where the communication break-down is, if you can help fix it, you’ll demonstrate many BA competencies.

#4: Developing Product Knowledge

And while doing all of the above, I learned our products inside and out. I understood how the software was put together and what the key features of most of our products were. I also got to know all of the key business stakeholders.  This knowledge proved immensely valuable for my first business analyst role, although it was eventually career limiting and I think I was wise to leave it behind when I moved into a BA role in another organization.

My advice to you: If you know the business, learn the technology. If you know the technology, learn the business.  Then leverage the business, industry, or software domain experience you already have for your first business analyst role.

Hindsight is 20/20 But

Of course, at the time, I couldn’t have explained any of this. It’s taken a lot of self- analysis for the patterns to emerge. But that doesn’t mean the pattern wasn’t there. I just didn’t see it at the time.

Today, in my role as a coach and mentor for aspiring business analysts, I find that most of the mid-career professionals I talk to have similar patterns. They’ve been jumping in and demonstrating they have the mindset of a business analyst for a long, long time. And now they are waiting for their chance meeting in the hallway – for someone to give them their first shot. The thing is, once you see your own pattern, you are empowered to change the conversation and seek out the opportunities where you have the most chance of success.

I hope that by sharing my pattern, I help you see parts of your own.

What elements of my pattern resonate with you? In what other ways are you already demonstrating your capabilities as a business analyst?

Don’t forget to leave your comments below.

Interrogating the Business Analyst Process to Discover Your own Value

Brandenburg_Sept_14_3One of the ways we can unknowingly hold our careers back is failing to understand and communicate our value effectively. Many of the business analysts I work with in their job search and career development initially lack an appreciation for how they contribute to the organization’s bottom line.

There are two common challenges that I see:

  1. Failure to understand how business analyst activities tie to clear business objectives.
  2. Failure to fully appreciate the value of the contributions they make as individuals.

In an earlier Business Analyst Times article, “Think “I” Instead of “We” When Talking about Your BA Career,.”  I’ve already touched on point #2 above. Today I’d like to discuss how an intrinsic focus on business analysis activities unframed in a business value context can be career-limiting.

In an often-quoted article from the value of the business analyst was cast in relief:

“For two decades, the CIO has been viewed as the ultimate broker between the business and technology functions. But while that may be an accurate perception in the executive boardroom, down in the trenches, business analysts have been the ones tasked with developing business cases for IT application development, in the process smoothing relations among competing parties and moving projects along.”1

This statement speaks to a business-focused value of the business analyst. From an executive perspective, business analysts are valued because they help contribute to successful projects that have a solid business case. They are in the trenches ensuring that IT investments create value for the business.

However, oftentimes we see and hear business analysts talking about their value in terms intrinsic to the BA process. They focus on what we do as business analysts over and above why we do it. For every what, there is a why. And one of the best things we can do for our careers is to interrogate our own process with the same rigor with which we might challenge the process our stakeholders use to complete their work.

For example, one of the guidelines for writing textual requirements from the BABOK® Guide is “using consistent technology”. This is a worthwhile attribute and we all know that any decent business analyst will use terms consistently throughout their requirements specifications. But “using consistent terminology” is an answer to “what we do” or “how we do it”. It does not answer “why do we do things this way.” Let’s interrogate our own process to discover the why:

Interrogator: How does “using consistent terminology” create value for our organization?

Business Analyst: It reduces confusion about requirements.

Interrogator: Why does that matter?

Business Analyst: Well, if stakeholders are confused about requirements, we might spend extra time validating the requirements.

Interrogator: Why does that matter?

Business Analyst: Stakeholder time costs money.

Interrogator: Why does that matter?

Business Analyst: It means that creating the requirements for the project costs more than it should. If we use consistent terminology in our requirements, then we should be able to complete our requirements cycles faster. Oh, and it also means that we’re less likely to build the wrong thing and have to waste development resources reworking the system.

Interrogator: Nice!

Executive Level Summary: Business analysts help reduce the costs of project implementations by bringing clarity to the requirements. One way they do this is by using consistent terminology in their requirements.

Any activity we do can be diagnosed in this way. But sometimes the answers are not quite so flattering. Let’s interrogate the infamous “software requirements specification.”

Interrogator: How does “creating a software requirements specification” create value for our organization?

Business Analyst: This document tells us everything we need to know about building the system. Sometimes its 50 or 60 pages long. We’re really detailed.

Interrogator: Why is that important?

Business Analyst: Well, if we don’t document everything, we’ll miss something.

Interrogator: I can see that how it’s important not to miss something. How does the document ensure we don’t miss something?

Business Analyst: Well, we conduct a walk-through with everyone that needs to know what’s in the document and everyone that will be building what’s in the document. That way we know it’s complete.

Interrogator: Why does the walk-through ensure that nothing is missed?

Business Analyst: [Blank stare]

Now, your answers might be different. Maybe your software requirements specifications are required for regulatory reasons or you’ve found a solution to organize a walk-through of a long document that ensures completeness (I haven’t).

The point is not so much to pick apart a process that receives an almost constant beating. The point is to challenge you to evaluate your process with the same rigor your interrogator might do. What if this interrogator was your CFO or an external consultant who had promised you boss to find ways to reduce the costs of building software? Would you be able to justify the activity is worth your effort and the effort of your stakeholders? And, even if you could, are there other approaches to the same problem that would work just as well or better?

My challenge to you is to begin your week by looking at your calendar and to do list and asking yourself “why” for each significant item on the list. If you don’t know the answer, start researching it with your peers and your manager. Focusing on “why” is one of the most impactful career habits you can develop, both in becoming a promotable business analyst or in framing up your applications for your next job. We do it in our projects, why not also do it for our careers?.

1 Why Business Analysts are so Important for IT and CIOsCIO Magazine.

Don’t forget to leave your comments below

Laura Brandenburg is a business analyst mentor and author of the free “3 Career Habits for Successful Business Analysts“, a primer to becoming a promotable business analyst. She hosts Bridging the Gap, a blog helping business analysts become leaders and advance their careers. She has 10 years of experience leading technology projects and has helped build business analyst practices at four organizations. If you’d like to learn more about discovering and increasing your value, including an ROI framework for business analyst activities, additional career habits that help you increase your ROI, and techniques for communicating your value to stakeholders and managers, check out Laura’s upcoming BATimes webinar.

Be Promotable; How to Increase the Value of Your Business Analyst Qualifications

How do you think about your professional development? When you hear the term, does your mind shift to training courses, webinars and reading books? How about the project work you do and the “extra” tasks you take on?

Whether you are looking for a job, seeking a promotion, or just want to make sure that your investments in professional development are keeping you up with your business analyst peers, it’s important not to focus just on training, certifications, or specific experiences. Managers in a position to hire or promote you want to know that you can perform at the level expected for the position you are seeking. They want to know that you’ll be an effective contributor. They are looking for an indicator of successful future performance.

One way to frame yourself as a successful future performer is to focus on what I consider marketable qualifications. Consider the following formula.


Think about what this means. A marketable qualification is formed by knowledge of how to do something and the experience gained from actually doing it. If I’m a manager and I’m considering you for an open position or a promotion, I’m not going to be so concerned about what you know. I’m going to be most concerned about your experience. The flip side of this equation is that you may have lots of valuable experience, but little or no formal knowledge. This often happens when you use your instincts to deliver successfully. If you have the experience but not the knowledge, you might overlook marketable qualifications because you simply don’t know the value of the experience you have. This is why marketable qualifications are created by both knowledge and experience.

Laura Brandenburg

As you think about your professional development, it pays to consider both parts of the marketable qualification equation. Look for opportunities to build your knowledge base and your experience and seek to keep these two aspects in sync for the best indicators of top performance.

What follows are some general rules of thumb for using the concept of a marketable qualification in thinking through your professional development strategy.

1. Focus on knowledge acquisition where you’ll also have the opportunity to build relevant experience.


I meet a lot of potential business analysts that have invested countless hours and lots of money in formal training programs and educational certificates. Oftentimes these individuals have spent a scant amount of time in the workplace and have little experience facilitating meetings, defining project scope, or analyzing and specifying requirements. They have a lot of book knowledge about business analyst techniques but no experience applying them in a real-world setting. No experience, no marketable qualifications.

The same holds true for mid- and senior-level business analysts within an organization. If you’ve read lots of books on agile but never used agile practices, your book smart not street smart. The first time you find yourself on an agile project or create the opportunity to apply an agile practice to a more traditional project, you’ll really learn what it takes to be an agile business analyst.

As you look at training options, even employer-sponsored ones, really focus on where you can learn and then apply your learning the day or the week you learn it. What chapter of a book could you read tonight and apply tomorrow? What archived webinar could you attend over your lunch break and use this afternoon? Immediate application of newly acquired knowledge means you are more likely to build valuable marketable qualifications. If you don’t apply what you learned, that learning will not really sink in. You might develop a slightly broader perspective on how you might use the skill, but without practice you don’t know if you can actually use the skill. If you are talking to a hiring manager, they are going to want to hear about your experience exercising your skills, not what you learned from a book or a training class.

2. Don’t overlook your project experience as opportunities to expand your marketable competencies.


One common challenge business analysts face, especially in our current economic environment, is that there is little funding for “professional development”. And by professional development here we typically mean training opportunities, conferences, and other high-cost learning opportunities. If we are employed or able to volunteer our time, there are typically ample opportunities to develop professionally through the work we do day-to-day. But to take advantage of these opportunities requires some forethought.

The easiest place to start is to look at each project assignment for opportunities to increase your qualifications. Is there a pain point that needs to be addressed? Is there an especially challenging stakeholder to deal with? Are there non-technical subject matter experts? Project anomalies of any kind provide opportunities for you to experiment with a new technique. Anything that is different this time around or in which your team struggled the last time around, are ripe opportunities for you to try something new to achieve results.

By framing these new career experiences within the pain points of your project team or organization, you are also ensuring that your efforts better align with your manager’s expectations. It’s very difficult for a manager to condemn you for doing something “outside-the-box” when you are trying to address a new problem or fix an old one. It’s much more difficult for your manager to support you if you apply a technique simply for “the experience”. Projects provide opportunities to build qualifications. Find them and take them. (And revisit point 1 to seek out relevant learning opportunities as you find them.)

3. Back-up your prior experience with the formal learning


For many senior business analysts our experience supersedes our knowledge. This also often happens to experienced professionals who find the business analyst profession after having worked for several years in a variety of related roles. Having the experience without the knowledge base will make it difficult for you to appropriately frame that experience as a marketable job qualification.

As a senior business analyst we might have experience performing very senior-level tasks, such as developing a business case to secure approval for a project, but never had any formal education about what should be in a business case and how it should be used. In this situation, some formal knowledge acquisition, coupled with previous work experience, can develop a marketable qualification. Education provides you with the confidence to use the right terminology and explain experiences you’ve already had in the formal terms used within the profession or your industry. Many business analysts I have interviewed report that CBAP study groups or reading the BABOK help them solidify their prior experience.

As you look back through your career history and your key projects, what have you naturally done well? What resources could you leverage to solidify that experience into a formal marketable qualification? How do other professionals talk about that kind of experience? What qualifications in job postings require that experience?

Finding and validating our marketable qualifications is no simple task. It requires introspection, honesty, objectivity, and a healthy dose of realism. The path to accumulate new qualifications is often no easier as we set out to balance our knowledge acquisition with our new experiences. But on the other side of this journey lies the ability to build career experiences in ways that line you up for career advancement, new jobs, promotions, and leadership positions. Is it worth it to you?

Don’t forget to leave your comments below

Laura Brandenburg hosts Bridging the Gap and is the author How to Start a Business Analyst Career and of the forthcoming eBook The Promotable Business Analyst, a guide book for crafting a fulfilling and successful career as a business analyst. To receive a special offer when The Promotable Business Analyst is available, sign-up for our early bird list.

Think “I” instead of “We” when Talking about Your Business Analyst Career

Picture yourself in an interview for your dream business analyst job. You are confident in your qualifications. You have prepared for the interview by researching the company, the hiring manager, and anyone else with whom you are meeting.

The manager asks you a few questions about your experience with a focus on business analysis. You answer confidently about how your team accomplished exactly what they were asked to do. You give an example. But the manager still looks at you a bit puzzled and probes for more information. She or he doesn’t seem to fully trust your answer.

One possible cause of this situation is that you are using “we” in your answers instead of “I”. You are a team player. You know that as a business analyst you help teams achieve great results. You focus your answers on what the team accomplished. This is a great way to look at your day-to-day work. But in an interview situation, the hiring manager is interviewing you not your team. Answers talking about “we” seem vague, are ambiguous, and can leave the impression that you are avoiding the questions.

From my own personal experience as a hiring manager for business analysts, one particular candidate among the many I interviewed with the “we” tendency, stands out among the rest. I share his story to help the other candidates out there who may unknowingly be facing his same challenges.

The candidate’s answers to my questions revealed a strong team orientation and other professional qualities that I respected and desired, but when it came to his BA qualifications, I couldn’t quite nail him down. In answer to every question about every project, he started the answer with “we”. We created a requirements document. We came up with an elegant solution. We implemented a successful project. We, we, we.

Truly liking the individual, I started probing and prodding then finally asked, “I understand what your team accomplished and that’s great. It’s important for me to understand what you contributed. What did you do, specifically, to help the team accomplish that success?” Unfortunately the candidate failed to come up with an answer and defended his “we” stance: “My contributions were only part of the team. That success was impossible without the whole team.” Although my gut said he was a good candidate for the position, I couldn’t validate his BA qualifications with any hard evidence. He was not hired.

I want to help you avoid this same shortfall. The difficulty is that his answer is true and valid. We accomplish more as part of a team. No matter how we think about it, we are not solely responsible for the outcomes we achieve as part of a group. But the career-defining questions remain unanswered: What did you do? Why should I hire you? Why should I believe that you will make a contribution on one of the teams in this organization?

In preparing to speak about what your team accomplished and what you contributed to help your team succeed, it can be helpful to keep a catalog of your projects and accomplishments. For example, let’s consider a requirements document. There is no doubt that significant project documents, such as a business requirements document or functional specifications, are the result of contributions from many individuals. When evaluating this experience for your contribution, think about the following activities:

  • Did you author the document? Alternatively, did you edit a document started by someone else?
  • Did you solicit feedback on the document and collate comments and reviews?
  • Did you elicit the requirements and ask the questions that ensured the document was complete?
  • Did you facilitate the meetings, pointing out disparate input or conflicting requirements?
  • What else did you do?

While the document you produced is the collective output of the team, it’s likely you had a very distinct role in that accomplishment. Catalog your specific contributions and be prepared to speak about them in detail.

Alternatively, if you were part of a BA team, you might consider quantifying your part in that team. For example, if the team collectively produced 50 use cases, maybe you drafted 20 of those use cases and provided critical feedback on the other 30. Can you think of an example where your feedback addressed a problem no one else had considered? Maybe you owned a part of the review or approval process. Maybe you owned the use case list and model.

Another way to think about this concept is to answer the following question: What hole would have been left if you had been plucked from the team? Looking at the team trying to achieve its objective without your efforts, analysis, and influence can help you see the situation with a fresh set of eyes. It can help you identify your slice in the team’s overall effort.

It’s also possible to use this approach to explaining your experiences while still showing you are a team player. One of the line items on my resume talks about a career experience from my early days as a QA engineer. I entered into a situation where developers across two different locations were often at odds with each other about the root cause of defects and who should fix them. I partnered with the developers from the other location, began testing their output directly, and helped drive more effective communication between the groups.

In my resume, I speak about breaking down communication barriers to reduce the length of time it took to resolve a particular category of defects. Of course, I did not single-handedly fix the issues, nor was I the only contributor to the improved success of this group of people. Every member of the team had a critical role in that improvement. But I am confident in calling myself out as the catalyst and talking about my role in bridging the communication gap, an accomplishment that helped carve my path into the business analysis profession.

So I ask you. What do you have to say for yourself and your career? Are you a career casualty to the ambiguity of “we”? If so, I challenge you to start a catalog of your recent projects and think long and hard about your contributions. This is a great step to take to advance your business analyst career.

Don’t forget to leave your comments below