Some time ago, I received a call from an IT manager from a large NY-based company.

This manager (let’s call him John) wanted my help in Phase 2 of a project whose first phase had experienced serious cost overruns.  The purpose of the project was to customize an off-the-shelf content management system for use by various business departments. “I want to warn you,” he said, “that the stakeholders you’ll be dealing with are very difficult. They worked with the BA initially assigned to the project, signed off on the requirements document, and only on the day we offered a demo, right before the go-live date, decided to complain about things that never came up during the requirements phase. We ended up missing an important deadline because the project sponsor refused to approve the release until a long list of change requests was implemented.”

I asked John a few questions about the requirements that had been missed, and quickly concluded that they could have been easily anticipated and dealt with in a timely manner, had the business analyst asked the right questions to the right people during the discovery phase.

One of the main objections from stakeholders was that the solution didn’t allow members of the Marketing team to easily reshuffle a series of events after they had been published to the website’s calendar. The software requirements clearly described how users would be able to create individual events, preview them in the calendar, make adjustments, and publish to the website. However, the requirements failed to account for changes in dates of connected events after they had been published.

Imagine that in early August, the Marketing team published a full calendar of events for September, pertaining to the release of a new product.  Then, mid-August, the product team announced that the release would be delayed three weeks. In this common scenario, there would be a high risk that the calendar ended up with incorrect dates due to the time-consuming process of reshuffling each associated event manually.

The BA’s mistake was to rely on the stakeholders to tell her which capabilities they needed to perform their job. A good first step here would have been to focus on how the stakeholders are behaving today. Stakeholders don’t necessarily realize that they have a problem to solve (“move around a series of linked events without having to manually change individual dates, to reduce the effort and mitigate the risk of human error”). But they are very good at describing how they perform their tasks today, and this knowledge is an invaluable source of information about what needs to be built.

Here are the some of the questions that would have helped the BA in John’s project identify the deal-breaker requirements that were initially overlooked: 

• Can you walk me through the process you follow, from the time you learn of a new event or series of events that need to go into the calendar, to the time the events are live in the website’s calendar?
• How often do you have to publish events to the website calendar?
• How often do you have to update events after they’ve been published?
• What do you normally do when you have to update an event after it’s been published?
• What is the most frustrating thing that you have to do when you are creating or updating an event?

Note how all those questions focus on how the interviewee is behaving today, as opposed to asking about what he or she would like the solution to do for them. By asking questions about the present, rather than the future, the BA would have learned that it was common for the marketing team to have a series of events with dates that are relative to each other (e.g., Conference Day 1, Conference Day 2, etc.) and that might have to be moved after the schedule had been published.

Stakeholders would have explained how they currently built the monthly calendar using an internal project management tool that allowed them to multi-select the events you need to move and shift them all together to a future date, preserving their sequence in the series. This piece of information would have allowed the BA to identify the ability to move a whole series of events in bulk as a necessary capability in the new solution, to avoid an inefficient and error-prone process of rescheduling events one by one.

You may be thinking, “but each situation is different—what if the missing requirement is not about something that the users currently do, but rather about what they’ll have to start doing in the new application?”.  As any business analyst knows, understanding and translating what our stakeholders truly need into software specifications that deliver the right solution is easier said than done. Different circumstances call for different interview techniques to uncover what the stakeholders’ real needs are.

>>Learn More

If you could use help in this area, check out Adriana Beal’s e-book: Tested Stakeholder Interviewing Methods for Business Analysts. This e-book offers proven techniques and actionable steps to ensure you uncover any deal-breaker requirements early on and avoid last minute surprises in all your projects.

Participants who complete Crafting Better Requirements may have very different educational and professional backgrounds, but they all have one thing in common: they leave the course with a unique set of strategies to successfully communicate requirements to the various audiences of their requirements documents.

Let’s look at the improvements a few selected course participants have made. It may be that in reading their stories, you find your most common mistake and can benefit from their feedback as well.

Issue #1: Using “User”

Take Tina*, for example. In her first attempt to capture functional and non-functional requirements for an online web store, she did a great job creating precise requirements, but repeatedly made the mistake of using the generic term “user” to refer to very different types of users of the web store application. All her requirements started with, “The user will be able to…”  While for business stakeholders this may not be a problem (since they implicitly know what actors are expected to have access to specific functions in the system), for the development team this could be a source of misunderstandings that might delay the delivery of a usable solution. With the feedback provided during the course, Tina was able to quickly improve the way she was capturing requirements, starting to use specific actors to identify who would be able to perform each function described (“the customer can add products to cart”, “the webstore manager can run daily reports of online orders”, and so on).

Issue #2: Vague Requirements

Bob*, on the other hand, already had the habit of identifying the correct actors, but was used to writing vague requirements that elicited lots of questions from the development team. For example, as part of the requirements for a keyword-based search, he would write, “Search engine should return search results fast to customer.” But  what does “fast” mean? The business could be thinking that it means returning results in less than 2 seconds, while the development team is assuming 10 seconds or less (because it would already be a challenge to retrieve the results in this amount of time using the existing IT infrastructure). QA would not have enough information to create test cases in order to ensure this requirement had been fulfilled. Once this weakness was identified, Bob was able to train himself to look at his requirements from the viewpoint of the people who would need to implement and test them (rather than just from the perspective of the stakeholders who will benefit from the solution, and thus know what the expectations are). By always asking, “How would I test if this requirement is correctly implemented?”, he was able to increase the level of detail of his specifications and substantially reduce the number of questions he got from the development team to clarify requirements.

Issue #3: Poor Organization

Jane* was always trying to get her manager and colleagues to look at her requirements to find areas for improvement before she shared her specifications with technical and business stakeholders. However, her manager wasn’t trained in requirements documentation, and the other BAs on her team didn’t have time for more than a cursory look at her documents, so the feedback she’d get was insufficient to surface the problems with her specifications. Only during the final review would the stakeholders give their full attention to her requirements, and ask questions that required Jane to go back and make a series of updates in the documentation before getting the necessary approvals.

During the course, Crafting Better Requirements, Jane finally had a chance to receive in-depth feedback for her requirements statements, and identify the flaws in the way she was documenting them. She learned some useful strategies, such as grouping requirements by functional area and user type to make it easier to spot missing requirements. Using her new set of strategies, she was able to decrease the number of review sessions required to get sign-off for her requirements documents.

* Names have been changed for privacy.

How to Leverage Feedback for Improvement

In these and other success stories collected over the years since the launch of Crafting Better Requirements, the main benefit the participants received from the course is the ability to focus on their own specific weaknesses, rather than follow a predefined curriculum. Based on the identified areas of improvement, some participants will spend most of the time practicing writing requirements statements to make them more concise and less ambiguous, while others may dedicate more cycles to creating diagrams to augment their requirements using visual representation, or learning how to create more effective acceptance criteria for their user stories. Instead of standardized teaching, they are able to experience customized learning based on individual feedback and personalized instruction and assignments which, in the words of a participant, “drastically reduced my learning curve.”

As a result of the customized feedback provided throughout the course, and the opportunity to use deliberate practice to overcome their individual weaknesses, these business analysts not only acquired new valuable skills, but also increased the value they provide to their organizations. The benefits for the companies these BAs work for include shorter requirements cycle time, less back and forth with developers to clarify requirements after sign-off, and fewer change requests submitted during user acceptance testing due to incomplete or incorrect requirements.

If you are a BA working on the IT space, you may be responsible for creating multiple deliverables, many of them intermediate documents such as meeting minutes and as-is/to be business models. You may also be in charge of producing important and high-visibility requirements specifications such as a Vision document describing the application in general terms (including, for example, descriptions of the target market, system users, and the application features), or Business Requirements Document (BRD), describing, at a high level of abstraction, the business needs.

Regardless of how many artifacts you produce in a project, unless you are working on a pure agile environment, the Software Requirements Specification (SRS, sometimes called functional specification, product specification, system specification, or requirements document) will be the most valuable document you will produce during the course of many of your projects. Practicing and improving this skill is something I help analysts do in my course Crafting Better Requirements. What follows is a synopsis of what a software requirements specification is and why it’s a valuable skill.

What is a Software Requirements Specification?

As the name says, the SRS is the specification for a particular software product (or for a specific release, module or component of such product). A Software Requirements Specification must describe all the capabilities a product must have in order to fulfill the business, stakeholder and user needs. It defines the inputs, outputs, functions, and attributes of the system, as well as the attributes of the system environment. According to the IEEE Guide to Software Requirements Specifications, a good software requirements specification leaves out design, verification, and project management details (except for required design constraints), in order to provide the design and development team with maximum flexibility to arrive at the best technical solution that can fulfill the stated needs.

What is the Software Requirements Specification used for?

The Software Requirements Specification is such an important piece of software documentation that it is sometimes produced even after the software product has been designed or developed, to serve as a reference for testing and to address the needs of the operations and maintenance teams.

Besides establishing a clear agreement between supplier and customer on what the completed software must do, a Software Requirement Specification provides crucial information that the Quality Assurance team needs to create test plans that will verify whether the system is indeed fit for purpose. It also offers valuable information for the operations and maintenance teams–for example, an indication of when a software component may be retired because it only supported a temporary need, or which modules or functions of the system are particularly critical for the business, and consequently must be monitored and protected against failure to prevent financial loss or other negative impacts.

A Specification is Not Supposed to Replace Conversations

Clearly, even the finest Software Requirements Specification document will never replace interpersonal discussions that will need to happen throughout the project. It is virtually impossible to discover–and document–every single fragment of information that feeds into software development upfront. A considerable part of the job of an IT analyst is to keep the lines of communication open between the technical and business teams, so that issues that may surface during the project, trade-offs that must be discussed, and requirements details that may have been overlooked can be addressed in a timely and effective manner.

Anyone in IT Will Be Valued for SRS-Writing Skills

In “Testing SAP R/3: a manager’s step-by-step guide”, authors Jose Fajardo and Elfriede Dustin define quality in the context of a software product as:

a system that performs as expected, making available the required system features in a consistent fashion, demonstrating high availability under any type of constraint (i.e., stress, concurrency, security breach, etc.); thus, consistently meeting the user’s expectations and satisfying the system’s user needs can be considered to be high quality.

Undoubtedly, a software product will have a much higher probability to meet users and business expectations if there is a solid reference from which the development team can work and which addresses all relevant aspects of the solution, from the sources of inputs, to performance and external interface requirements. Analysts with the ability to document functional and non-functional requirements that carefully trace back to business requirements and provide a solid foundation for the design and development team to build a solution that achieves the organization’s goals are hard to find, and such skills generate career progression opportunities for analysts who demonstrate talent in this area.

Even when you progress in your career to a position in which is no longer your responsibility to write requirements specifications, your ability to inspect requirements documents to determine their quality will be instrumental for ensuring that the development team has the appropriate input for their work.

If you are interested in developing skills in this area, a good starting point is to dissect Software Requirements Specifications written by talented authors such as Karl Wiegers, read high quality books such as Software Requirements, Third Edition (Pro-Best Practices), keep valuable references to consult during your projects, such as The Software Requirements Memory Jogger: A Pocket Guide to Help Software And Business Teams Develop And Manage Requirements (Memory Jogger), and most importantly, practice, practice, practice.

As well put by Karl Wiegers in his book More About Software Requirements: Thorny Issues and Practical Advice,

You won’t learn how to write good requirements from reading a book on software requirements engineering or a book on technical writing. You need practice. Write requirements to the best of your ability, and then enlist some of your colleagues to review them. Constructive feedback from reviewers can help anyone become a better writer. In fact, it’s essential. Requirements quality is in the eye of the reader of the requirements, not the author. No matter how fine the author thinks the requirements are, the ultimate arbiters are those who must base their own work on those requirements.

You are a good software engineer, database manager, or software quality assurance professional who recently discovered that business analysis is the role you enjoy the most. How do you go from a technical role to a business analysis role?

This is a problem faced by many aspiring business analysts, and even by people who already spend time doing business analysis work in technical positions. What should you do to prove to potential employers that you have the necessary skills to take a formal BA role? How to avoid being constantly “dragged back” to an IT role when the volume of development work grows or the size of the IT staff is reduced?

Having solid technical skills can be a great starting point for someone looking to develop a career in business analysis. In Why do we see technical skills in business analyst jobs? Laura lists a good reason why many BA jobs ask for technical skills: BAs with technical knowledge are more likely to ask the right questions about technical implementation.

The assumption becomes if you can write code now or could write code in the past, you are less likely to be trampled by the developers.

I remember at least one situation in which my technical background (electrical engineering, with time spent programming in C and Java) came to the rescue of a system enhancement project in danger of not fulfilling the business need. The developer (who had inherited the code from someone else), was adamant that one of the business requests could not be implemented without a major code rewrite, which would require time and budget the project didn’t have. I asked him to explain to me the basis for his opinion. After some investigation, I discovered that the initial implementation had a flaw that could be easily corrected. By simply changing a primary key in the database (to the one that actually made more sense from a system and business perspective), it would be possible to implement the feature the business requested. The developer wasn’t exactly convinced by my arguments, but I scheduled a meeting with him and the head of development (a manager with excellent technical background), and the manager immediately saw that my analysis was correct. The featured ended up being implemented without the major code overhaul proposed by the developer.

Situations like the one described are not uncommon when business analysts with a technical background work together with business subject matter experts and the IT team to find the optimal solution for a business problem. A business- and technology-savvy analyst can be instrumental in helping determine the business need and define the optimal solution to meet this need.

The biggest obstacle for IT professionals interested in developing a BA career is the lack of well-developed business skills. One might argue that “soft skills” (the ability to communicate with clarity, precision and eloquence, work well with other people building effective contacts and relationships across and outside the organization, and so on) are more important for a BA than being business-savvy. However, in my experience, software engineers who are passioned about business analysis already value and develop their transferable soft skills, so it’s typically not the main competence gap they face when they try to switch to a BA position.

Understanding things like revenue streams and profit centers, on the other hand, may require a mode of thinking that is relatively unfamiliar to many technical people. Often, IT professionals are more skilled at writing elegant code, and producing software rich and features and functions, than at helping stakeholders determine the right set of project requirements capable of balancing the needs of the company, the market, and the users.

If you have a background in IT, and want to become a business analyst, here are some steps that will help you reach your goal:

1. Read Bridging the Gap regularly. Here you will be able to interact with BAs who successfully made the the transition from a technical role, and read articles like What jobs will lead to a BA role?, which will give you good insight on how to highlight your BA experience in your resume, and how to use other roles as stepping stones to get a BA job. Signing up for the free email newsletter will help you stay updated with the latest posts.
2. Periodically reassess your competence gap and make sure you have a plan to address them.
3. Learn to “talk the talk” of business analysts. The site Modern Analyst offers a useful list of potential interview questions that can help you formulate your thoughts and become better prepared to answer screening and interview questions.
4. If you haven’t started yet, read business books, and blogs such as the ones from Harvard Business, as well as resources that can help you build your business analysis skills, like the ones I recommend here.

Finally, if you are truly invested in developing a business analysis career, check out the book, How to Start a Business Analyst Career.

In my previous article for Bridging the Gap, I wrote about the importance of right-sizing your initiatives to get beyond a career plateau as a business analyst. A reader left a comment saying, “if your management listens, you can think about taking initiative, else, its just a waste of time and energy”.

That comment made me realize that we should be discussing also how business analysts can significantly improve their chances of being heard as they try to create new opportunities, from getting help with eliminating skill gaps, to participating on more high-visibility projects. The formula for successfully selling your initiatives to your boss is actually simple, if frequently overlooked by brain-powered workers:

1. understand your management’s framework;
2. persuade your audience not just to accept your point of view, but to take concrete action as a result of it.

In order to sell your ideas effectively, first you must have a clear understanding of what your organization is trying to achieve, and why. This will help you establish a clear “line of sight” between your initiative-taking goals and your team’s and organization’s goals. But you can’t stop there; you also need to present your ideas in a convincing way. If you typically find it difficult to create buy-in for your ideas, read (or reread) Made to Stick: Why Some Ideas Survive and Others Die and start learning the mechanics of persuasion, and practicing the ability to deliver your message to your target audience.

Remember, your ability to “get management to listen to you” is directly dependent on your ability to take information, select key points, and deliver them in a manner that convinces the listeners to accept your message. The way you present your initiatives to your boss (or the people you need approval from) can have a dramatic influence in how your ideas are received.

The steps below, adapted from an article published at The Cranky Product Manager, provides a good framework to help you to achieve this goal:

1. Create a short, easy to read handout for your boss, making the case for what you want, and including if possible several options for him to consider (see an example in the article mentioned above).
2. Make an appointment with your boss to review your handout.
3. Go over your points one by one, finishing with a persuasive review of the benefits for your boss and the company.
4. If your boss doesn’t immediately choose one of your recommendations, negotiate a time frame for a decision, and immediately set a meeting for follow-up.
5. If you get a “no,” don’t get overly frustrated. Try to understand the rationale behind your manager’s decision, focusing on any bottom-line implications, and see if you can come up with a different strategy to get what you want.

Remember the lessons from Made to Stick: a good story engages the listener with something worth listening to. Make your message relevant and interesting to your management, and the probability of your ideas being heard will rise dramatically.

It’s common for me to receive emails from business analysts who are feeling frustrated with their current situation at work, all related to the same theme: the limited business analyst role they are given in their organizations. Frequent complaints include:

• In my company the BA is involved in projects only when all the important decisions have already been made.
• I’m expected to put together requirements documents without enough time to do the necessary analytical work.
• I’m not being involved in business discussions that affect the scope of my projects.

This is clearly an example of the “medium-sized stuckness” situation described by Laura Brandenburg in her article Where is your business analyst career stuck?. These people have hit a plateau in their careers, and most likely are living a vicious cycle that reinforces itself through a feedback loop. Their work isn’t making a big impact in terms of value creation, which makes it almost impossible to change the narrow view that others have about their role and consequently elevate this role to a more influential level in the organization.

In recent articles, I wrote about the importance of making a more compelling case for management to start seeing the BA beyond the presumed role of requirements recorder, and of taking charge of your learning and career development objectives to create opportunities for yourself.

It’s a theme I feel I have to constantly go back to with BAs asking for help with their careers, and I’ve begun to suspect that the struggle many of these professionals are experiencing has to do with their too narrow definition of the meaning of “initiative taking”.

In the book How to Be a Star at Work: 9 Breakthrough Strategies You Need to Succeed (an excellent resource included in my list of  recommended books), professor Robert E. Kelley describes the problem:

In Chapter 5 on initiative, I told the story of Caren, the production specialist for an advanced materials ceramics company, who confused initiative with “initiative-lite”. Like many average performers, she mistakenly believed that finding better ways to do her job constituted initiative. She was responsible for representing her department at technical team meetings and then reporting back to her coworkers. Her problem: she could not participate in the meeting and also take good notes. So out came a tape recorder, allowing her to participate in the technically challenging discussions. In Caren’s view she had taken an important initiative.

As any star performer knows, doing a job more efficiently seldom qualifies as an initiative. If you are finding it difficult to elevate your role and become more involved in the process of driving organizational change, perhaps you need to reassess your level of initiative taking, and follow some of Dr. Kelley’s recommendations. Spend more time understanding what is the “critical path” for your organization, and what “white space” outside your regular job (but connected to this critical path) you could be stepping into to help your projects in both the local and global context. See if you can move from “horizontal” to “vertical” initiatives (instead of solving a local problem, begin to look for systemic problems that could lead to corporate-wide optimization).

BAs who really take initiative, and seek out responsibility above and beyond the expected job description, get noticed when it counts. If you become known as an individual who can use information and organizational knowledge to improve decision making and efficiencies in the organization, you will find it much easier to get involved in the discussions that were previously happening quietly at the top of the organization and taking a while to filter down to you.

John Davis writes:

We’ve been looking at IAG’s BA Benchmark 2009 that deals with the impact of poor requirements practices on project and organisational success. Short of hiring a company such as IAG, how can we as BAs best help our organisation – or a client organisation for those of us in IT Services – develop more maturity in requirements definition and management?

Speaking from my experience working as a consultant for large organizations which frequently lack structure and discipline in requirements definition and management, making the case for a stronger business analysis practice is not as easy as one would expect. With the number of studies demonstrating how flawed requirements development processes generates all sorts of problems in software development projects (from scope creep to defects found at later stages compromising product quality and resulting in ballooning costs), it is somewhat surprising to see so many business leaders failing to recognize the value of consistently following a mature, disciplined business analysis process in their organizations.

One of the main reasons for this lack of understanding is that it’s not a simple task to connect improved process capability with better results in IT projects. Skepticism about the value of investing in process improvement remains not only for business analysis, but for other disciplines as well (software development, user experience, testing, etc.). Such resistance is understandable in light of the fact that many problems, from requirements volatility to implementation issues, can cause project failure even in organizations with excellent processes in place.

What can a BA do to help overcome the resistance to change? A conversation with senior management about current project issues is a good starting point. Is your company missing commitments? Suffering from late delivery of software products to the market? Experiencing last-minute crunches, or too much rework? By focusing on existing project shortcomings, and the range of expected results that can be achieved by following a better requirements process in terms of cost, schedule, functionality and product/service quality, it is possible to raise awareness, obtain the necessary support in the form of sponsorship, and secure the resources needed to start a process improvement effort.

Once the initial resistance is overcome, what should be done next? A good first step would be to get management and the BA group thinking of what needs to change. A reference guide such as the BABOK can be used to facilitate the process of answering the question: “What is the real situation here?”. In order to improve its requirements practices, organizations may need to work in several directions: processes, planning, training, technology, relationships and coordination with other disciplines, measurement. Disciplined change is important, as well as approaching the problem iteratively, like a series of projects that break the work down into smaller, more manageable pieces, so that inefficient or defect-prone BA activities are identified and replaced or revised in a consistent, effective manner.

There is a lot to be discussed about developing a true business analysis discipline and establishing an effective BA practice that supports the need for both stability and continued improvement. I hope to continue to develop this topic in future articles.

Among the many competencies that business analysts need to develop in order to advance their careers, the ability to manage ambiguity is undoubtedly a critical one. The rapid changes that happen internally and externally to organizations require business analysts to become comfortable acting in an environment in which uncertainty and change are constants, and timely decisions need to be made even when not all the variables are known.

How can a BA improve his/her performance dealing with uncertainty and unpredictability? This is a competency most likely to be developed through informal practices. A good start is to acknowledge that managing ambiguity well typically requires two approaches: working to reduce ambiguity and finding ways to become productive even when uncertainty is unavoidable.

By the nature of their activities BAs plays a crucial role reducing project ambiguity. Typical business analysis tasks, such as clarifying project scope, defining and communicating requirements, and making sure that each business term used is clearly defined in a project glossary, significantly contributes to reducing ambiguity in a project.

In addition to reducing uncertainty in their projects, business analysts are also instrumental in helping the team remain productive amid ambiguity. Examples of steps that a BA can take to achieve this objective include:

• Assisting the project manager in establishing ground rules, roles and mechanisms to foster productive discussions and interpretations of business needs and solutions;
• Prioritizing and organizing issues to reduce the distraction caused by too many unknown factors;
• Making an effort to establish a common understanding of project goals among different stakeholders so conflict is replaced by cooperation.

Finally, BAs can also become more skilled at managing ambiguity by accepting criticism as learning. Leaders who manage ambiguity well understand that they will make mistakes and adopt the attitude that failure only happens if they choose not to learn from the experience. By being open to making mistakes (which are bound to happen in situations that aren’t black and white), and choosing to interpret the criticism as learning, a business analyst can become significant better at managing ambiguity over time.

This post from the website Better Projects talks about how Google is not afraid to fail, and what BAs can learn from the company:

We BAs could learn a lot from that kind of mentality about failure. No requirements document will be perfect on its first (or often even fifth) version. No screen mockup can encompass all the needed functionality and interaction. No use case can cover all possible directions that a user may go. Yet despite knowing the limitations, we should not just toss up our hands when we don’t get it right on the first try. We learn what our customers really need and next time, we get it right. We look for that elusive ‘killer app’ that will win approval from our customers so we have it ready for them, exactly when they need it the most.

This is certainly a good mindset for BAs to adopt while working under highly ambiguous circumstances.

>> Learn How to Ask the Right Questions

Interested in receiving a comprehensive set of questions you can ask in almost any project context to reduce ambiguity on your project? Want to feel more confident asking questions in a new domain? The Requirements Discovery Checklist Pack includes over 700 questions, categorized and cross-referenced so you can prepare for your next elicitation session with a sense of ease and confidence.

Click here to learn more about the Requirements Discovery Checklist Pack

In discussions about the role of the business analyst, it is common to see professionals insisting on the importance of “going beyond requirements” when describing the BA work. These analysts argue that BA activities such as enterprise analysis and process improvement indicate the need for a broader description. Being myself a consultant who often works in activities related to business process modeling and process improvement, I fail to see the benefit of moving away from the term “requirement” when describing the work of a business analyst, and here I explain why.

The IEEE Standard Glossary of Software Engineering Terminology defines requirement as:

1. A condition or capability needed by a user to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a system or system component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

The BABOK provides a very similar set of definitions (differences underlined):

1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2).

Simplifying a bit these statements, it is possible to define requirement as “a condition or capability needed to achieve an objective” (solving a problem can be considered an objective–something toward which effort is directed–, and therefore doesn’t need to be explicitly mentioned here). Based on this definition, it becomes easier to view “requirements” as the core aspect of the business analysis work–even for BAs who don’t belong to the IT space.

Take, for example, business process modeling activities. Process modeling is used to generate a visual representation of the flow and control logic associated with a sequence of related activities or actions. A process model, however, is not an end on itself: models may be created to better understand how certain business scenarios are handled, to help identify problems in the flow, to detect activities that don’t add value to the business, etc. Process models, in most cases, become a source of requirements, helping the organization (and, in particular, the business analyst) identify the conditions or capabilities needed to solve a problem (for example, a bottleneck, or errors caused by a faulty interface between business units), or to achieve another objective (e.g., increase productivity by reducing the time to perform a task or eliminating the wait time between tasks).

Business analysts exist to facilitate organizational change. They study business problems and opportunities and recommend solutions to help corporations achieve their goals. In doing so, BAs are constantly involved in discovering, identifying, analyzing, negotiating, and documenting requirements that address business problems and opportunities.

One of the topics that appear to be on the mind of many business analysts lately is the expansion of the business analysis role. How can a BA make a difference in his/her organization, perhaps going beyond conventional analysis to become a visionary? What are the challenges a BA may need to overcome to respond to the increased expectations of companies who hire business analysts not just to manage requirements, but also to perform project management and participate on decision-making processes?

Questions like these reflect the natural desire that business analysts have to better understand their role and focus on the development of the skills that will not only support their career goals, but also generate the most value for their organization.

Obviously, there isn’t a one-size-fits-all answer, but one thing that may be helpful for BAs pondering these questions is to remember that the most value a business analyst working in the IT solution space can offer to an organization is to excel in the processes related to the discovery, analysis, negotiation, and validation of the requirements of a new or modified software system. End users, project sponsors, subject matter experts, project managers, etc., all get involved in the process of eliciting requirements, but the business analyst (regardless of the job title he or she has) “owns” the requirements processes, and is responsible for making sure that the requirements adequately and completely represent business and user needs. To be truly effective, a BA must consider the project requirements their primary concern, from the development of a product vision and scope to detailed user and software requirements specifications and the change control processes that will be used to manage requirements during the lifetime of the project.

What about blended roles, then? It’s normally hard for a single person to balance goals like getting the project done on time and budget vs. delivering the right product. In my experience as a consultant, the most successful projects typically have a business analyst and a project manager working together to accomplish project goals. Activities such as planning the work to be done, identifying and securing necessary resources, determining tasks that must be completed, assigning the tasks, delegating authority, tracking progress, etc., are the responsibility of the project manager, while the business analyst remains in charge of producing consistent, complete, feasible, truly needed, accurate, traceable and verifiable requirements.

I see the “expansion of the business analyst role” as a double-edged sword. The consequences can be favorable if the intention is, for example, to involve business analysts in enterprise-level activities related to identifying gaps in organizational capabilities, developing models to describe the desired future state of the organization, or performing other tasks that allow BAs to deepen their knowledge of business goals and contribute to the formulation of business transformation projects. If, however, instead of aiming to get more from their analysts’ skills and capabilities by extending their involvement across the enterprise, the organization is simply trying to cut costs by having the business analyst simultaneously act as project manager, tech lead, or QA tester, there’s a substantial risk that the change will result in loss of value and quality of the output provided by the analyst, which in turn may result in extensive and expensive rework, or contribute to the already high statistics of IT project failure.

While discussing the BA role in their organizations, business analysts must be ready to fight unwarranted assumptions, needless compromises, and wild guesses about the responsibilities they have and the contributions they make as part of a solution team. An experienced business analyst is typically busy throughout a software development project, bridging the gap between the business and the technology teams, determining changes in processes and operations that need to take place as a consequence of the new system, investigating and advising on the project’s impact on other systems and initiatives across the enterprise, and so on. While BAs working for smaller organizations (or dedicated to smaller projects) may be able to successfully wear multiple hats, the acceptance of additional responsibilities, particularly when in conflict with business analysis core responsibilities, can have devastating consequences for both the organization and the analysts–a few of whom may even find themselves victims of the infamous Peter Principle.

To borrow the words of Laura Brandenburg,

I do think we need to balance our desire to help with an understanding of what it takes (in terms of time, effort, and focus) to be the best at what our core responsibilities are. It can be tricky… but sometimes it is better to “just say no”.