All these problems share a common root cause: lack of concrete evidence of the value a skilled business analyst brings to organizational initiatives. For example, if you join a company that previously only hired weak BAs who never contributed substantially to the outcomes of software projects, stakeholders might forget to invite you to the discussions during the early phases of your projects. They may also decide to talk directly to developers to define the solution without seeking your contributions, and deny your requests for training, certification, or conference attendance, because they don’t see the potential return on that investment.
But BAs have a powerful tool on their side to help influence management to elevate their role and increase their exposure to enterprise analysis, high-profile projects, and professional development opportunities: performance measurement.
Even if your company doesn’t measure the performance of individual BAs, or does it poorly (measuring things that aren’t directly related to value creation, such as time spent by BAs on each task, number of requirements, requirements volatility), you can establish your own effective performance measurement system. Then, with the performance data collected, you’ll be able to provide solid evidence of the value you bring to your projects and demonstrate the benefits that further investments in your skill development can bring to your organization.
Here’s an example, drawn from my own experience:
Several years ago, I was asked to return to one my clients, a financial institution, to help bring one of their software projects back on track. In the course of the new project, I happened to find, lying on a shelf, a copy of the requirements document I had produced for my previous project. At the time the document was approved, the business stakeholders had offered high praise for my work, but when I opened that copy of the document, I saw many questions from the development team, hired only after I had left for another assignment.
For instance, while the business stakeholders had been satisfied with my requirements describing the “happy path” of a wire transfer being successfully completed, the development and testing teams also needed to know what should happen when an attempt by a customer to submit a wire transfer failed. The expected behavior could be anything from just presenting an error message to the user, to sending an alert to the appropriate account manager so he could immediately follow up with the customer to fix the issue. The right solution could not be built until the desired behavior was clarified.
That experience opened my eyes to an important aspect of my performance that I had been overlooking: writing requirements that not only the business stakeholders found to be in excellent shape, but also the development and testing teams considered to have enough information for them to be able to to build and test the right solution. Providing incomplete or vague information to development and testing teams may cause unnecessary delays when the teams have to list the questions they have and wait for someone to analyze these questions and provide a suitable answer. For that reason, when I saw that annotated document full of questions, I decided to start monitoring my performance in this area.
One of my professional goals became: “reduce the number of questions my requirements documents elicit from development and testing teams”. I defined a target of no more than 3 questions per document for year one and 1 question per document for year two. (This would give me some time to identify the patterns that caused developers to need clarification of my requirements and fix the issues before I started to hold myself to a higher standard.)
With my new goal in mind, I started thinking about requirements not just from the perspective of the business stakeholders (who already were very satisfied with the quality of my work), but also from the perspective of developers and testers. After writing each section of a requirements document, I’d ask myself: “If I were writing the code for this capability myself, would there be something else I needed to know?” And, “If I were in charge of testing this set of requirements, would I know the expected results for all relevant test scenarios, such as entering an out-of-range number, or skipping a required field?” These questions helped me find the omissions in my documents before they were released, drastically improving the quality of the final products from a perspective of the delivery team.
By the end of year two, I had exceeded my goal, with most projects yielding zero questions from developers. From time to time, I still get questions posted to the wiki page reserved for questions about requirements, but I can always map them to one of the following scenarios, which don’t affect my individual performance:
- The question isn’t about requirements (e.g., “How many search results should be displayed in each page?” when the decision about how to display search results had been left for the UX designer, who might even design a solution with “infinite scrolling”, so there isn’t pagination to worry about);
- The question has been answered in the document already (e.g., “Do we need to worry about different levels of permission for different user roles?” when the Table of Contents of the wiki space that stores the requirements already has a section titled “User Roles”);
- The question is about a gap in requirements that is known and noted in the appropriate section of the requirements document (e.g., “Pending definition of which file formats the import capability will have to support”).
Now, how can this approach of setting goals and measuring your performance help you demonstrate your value to the organization and justify more investments in your professional development? Here are some steps that you can follow:
- Show the results of your performance measurement and improvement efforts to management, accompanied by an analysis of the impact these results have in project outcomes. Example:
“Because our development team is in India, each question raised by a developer may cause a delay of up to 24 hours in completing a portion of the code, due to time zone differences. Clear requirements that eliminate the need to ask questions and wait for the answers mean more productivity for the developers working on the implementation of new capabilities.”
- Describe the goals you are pursuing next, accompanied by what value reaching this goal will add to the overall performance. Example:
“My goal for Q1-2014 is to become fully knowledgeable on the business aspects of creating and maintaining promotional discounts for our webstore. This knowledge will help me better understand the business and user scenarios our tools must support, so I can propose better solutions and avoid the change requests that we keep receiving at the end of each development cycle to accommodate missing functionality.”
- Ask for whatever resources you need to reach your goals. Examples:
“In order to help me achieve this goal, I’d like to ask permission to start spending 20% of my time in the marketing department, so I can observe their work when they are creating and updating promotions.”
“There’s a conference coming up about new trends in web analytics that I’d like to attend so I can bring some new ideas to the marketing team about how they can better track the results of their promotions. Based on better analytical data, I can help the business stakeholders prioritize future enhancements to our promotions engine to reduce the backlog of our projects by cutting scope that isn’t going to contribute to the bottom line.”
The main pitfall to avoid when discussing the value you bring to your organization is what many professionals do in their resumes and cover letters: talk about alleged personal traits (e.g., “I solve puzzles and fix problems better than most”, “I’m good at taking complex ideas and making them digestible”). You want your discussion about value to focus on clear and objective data that highlight recent accomplishments and show the benefits that your current performance and future improvement efforts can bring to the organization.
If you are a business analyst working on the IT space, you’ll probably be looking for evidence of how your work improves the quality of requirements artifacts, lowers the number of defects and change requests, increases user adoption rates, and/or saves time and money by helping the business focus on high-value features. For a process improvement BA, good measures would provide evidence of the return on investment of your recommendations on quality improvement and process modernization, the number of problems affecting customers or employees that have been fixed by your change proposals, and so on.
With a list of accomplishments backed by objective measures, you’ll be able to offer concrete evidence of the value you bring to your team and develop solid arguments to convince decision-makers to elevate your role and give you access to better information and training resources.
Don't forget to leave your comments below.