Author: Aly Cassam

Aly Cassam, CBAP® has over 20 years of experience as a Business Analyst type role in the Wealth Management industry. In the course of his career, he has been a Business Analysis Practice Manager. In this role he co-developed a Business Analysis Practice including training curriculum at for the Wealth Management division of a major bank. He can be contacted at the following email: [email protected]

Approaches for Being a Lead BA

You’ve worked your way up the BA ladder – started as a Junior BA, then a BA, then a Sr. BA, and now you’re a Lead BA on a project working with other BAs. What do you do? This article focuses on some of the Do’s and Don’ts of being a Lead BA. Some of it is science and some of it is art.

Requirements Governance:

1. Who do you take direction from your PM or your BA Manager:

The first place to start as a Lead BA is establishing your own personal Requirements Governance. Who do you provide status updates to and who do you take direction on requirements from – PM or your BA Manager? The scenarios I’ve encountered are:

  1. You as the Lead BA take your BA requirements direction from the PM and provide status updates to your BA Manager.
  2. You as the Lead BA take your BA requirements directly from your BA Manager and provide status updates to your PM.
  3. The third and most often scenario is where both the PM and your BA Manager are of the opinion that you take requirements direction from them and provide status updates to the other.

Tip: Right at the beginning of the project start the conversation with your BA Manager and clearly establish the relationship you’ll have with him or her and with the PM (in my experience coaching BAs too many Lead BAs don’t have the conversation upfront and then find themselves in a bind when scenario C) above becomes an issue during the project itself). If the answer is taking your requirements direction from them, set up a short meeting with your BA Manager and the PM to establish this relationship as PMs generally don’t like that arrangement, and it’s best to get them to discuss it face to face. If the answer is taking your requirements direction from the PM, then simply follow-up the meeting with a confirmation email to your BA Manager and just let your PM know that you’re effectively going to report to them and take, where appropriate, BA approach direction from them.


2. Establish your role as Lead BA on the BA team:

Make sure it’s clear to the BAs you’ll be leading that you are the Lead BA, and they will work with you in that capacity. A couple of ways to communicate this:

  • Ensure you’re called out on the project governance as the Lead BA and ensure the BAs you’ll be leading review the project governance
  • Where you’re taking your Requirements direction from your BA Manager have them send out an email to the BAs you’ll be leading that you’re the lead and that you’ll be guiding the approach etc. to the Requirements deliverables

3. Start by learning about your BAs:

At the beginning you’ll need to establish how experienced the BAs are with eliciting, documenting, and analyzing requirements, how familiar they are with the project subject matter, etc./ by scheduling quick little chats with the BAs you’ll be working with

  1. If you’re dealing with Sr. BAs with lots of experience, then your focus with them will be on making sure things are going smoothly and that they working to the timelines for their requirements work packages; You can give them fairly large and complex requirements work packages
  2. If you’re dealing with more Jr. BAs then you will be in a more guidance/ mentoring mode – periodically reviewing their requirements and providing feedback, mentoring on approach to different types of requirements such as documenting process flows and business rules, etc.; Initially limiting the scope of their work packages to small well-defined pieces of requirements; have little chats with them about how things are going

4. Develop a view of the requirements work packages:

Typically, a group of BAs is assigned to a project because the project is complex and there are multiple “groups/ categories” of requirements that need to be created to deliver the scope of the project. At the outset understand the drivers and objectives of the project and establish a view of the requirements work packages. Some examples of this are:

a. Achieving compliance with regulations or another compliance-related purpose:

    1. You may need to look at work packages focused on complying with different sections of the regulations
    2. If the compliance covers multiple departments or Lines of Business (LOB) you may need to focus on requirements for each department/ LOB to comply with the regulations

b. Developing and implementing a large technology system or platform:

      1. You may need to look at requirements work packages focused around different groups of users with the system – for example if it’s a workflow system you likely have work packages for customer-facing components, back-office-facing components, etc.
      2. You may need to look at requirements work packages focused on different functional features. For example, a customer-facing platform for a direct investing platform may consist of trading-related features, viewing account holdings, researching different securities, etc.

5. Managing the requirements work packages:

a. Establish a view of the project timelines with respect to the requirements work packages based on their complexity etc. I prefer a matrix like this to do so (using the direct investing platform as an example) based on the requirements lifecycle – plan, elicit, analyze, document, get sign-off (note do this in Excel or Project to track progress, etc.)

Plan Elicit Analyze Document Sign-Off
Trading requirements 01/01/22 to 10/01/22 10/01/22 to 25/01/22 25/01/22 to 02/02/22 02/02/22 to 16/02/22 16/02/22 to 28/02/22
Security Research requirements 01/01/22 to 10/01/22 10/01/22 to 25/01/22 25/01/22 to 02/02/22 02/02/22 to 16/02/22 16/02/22 to 28/02/22
View account holdings requirements 01/01/22 to 10/01/22 10/01/22 to 25/01/22 25/01/22 to 02/02/22 02/02/22 to 16/02/22 16/02/22 to 28/02/22

b. Based on what you learned about the BAs you’re leading assign them to different work packages – and monitor their progress on their work packages against the. I’ve found the best way to keep track of this is using a matrix like this that I update on a weekly basis:


P – Plan, E- Elicit, A- Analyze, D- Document, S- Signoff

Trading requirements P – Jan. 1/22
Security Research requirements P – Jan. 1/22
View account holdings requirements P – Jan. 1/22


With these 2 matrices, you can keep track of who’s doing what and how they are doing against the target dates so you can provide status reports to the project team as required.

6. Monitoring progress and connecting the BAs as a team:

The most effective approach that I’ve found to monitor the progress of my BAs is to hold weekly meetings – with a twist. Most people just do a status check-in during their weekly meetings – how are you progressing against your timelines. I believe that weekly meetings are a good chance for the BAs to inform and help one another. I encourage them to talk about challenges they are having – someone else in the team may have encountered this and have a solution/ approach to tackling it. I encourage them to talk about effective approaches that they’ve found to doing things that may be helpful to other members of the team. Finally, I ask each BA to give a brief overview of the requirements they are working on. As most projects with a BA team have a common goal – by talking about requirements it will quite often identify synergies or conflicts between requirements/ work packages that will help move the project forward more efficiently.


Hopefully, these approaches will help you become a more effective BA Lead. There are lots more approaches and in future articles, I may expand on them.

Techniques for prioritizing requirements

One of the major challenges that Business Analysts face is getting stakeholders to prioritize requirements. Everyone is used to high syndrome – where the stakeholders say everything is a high priority.

The key to dealing with this problem is for BAs to understand the drivers of the project and then create priority evaluation criteria to assess each requirement. This is a key step that is often overlooked when starting the business analysis deliverables of the project.

Let’s say the objective of a project is to optimize a business process for an operations group. As a BA it’s important to understand what constitutes an optimized process. It’s a simple upfront question that will surface criteria that the BA can use to help the business prioritize the requirements. For example, the stakeholders may indicate that the optimal process would be one in which the To-Be process has fewer manual hand-offs, reducing the amount of paper that flows through the process, reducing the number of steps requiring manual entry of data, etc.


These criteria can then be used to develop a framework with which to evaluate and prioritize requirements. My preferred approach is what I call the scale approach. With the scale approach, you get the stakeholders to call out how well each requirement aligns with the assessment criteria on a scale of 1,3 and 5 (where 1 means the requirement is poorly aligned with the criteria, 3 somewhat aligned, and 5 highly aligned). This gives a numeric priority assessment of the requirement and a quantitative method of comparing requirements. This helps to get stakeholders out of the “high” trap mode.

Scale Approach:

Here is an example of the scale approach. The scaling approach uses a 1,3,5 scale where 1 is poor alignment, 3 is some alignment (in the middle) and 5 is highly aligned. The max score for any requirement is 15 and the minimum is 3. I’ve tried more granular approaches like 1 to 10…but it just causes a lot more sitting on the fence when you have that many values to apply to a criterion…and it’s not as “distinct” an outcome as the 1,3,5 scale. I specifically avoid using numbers instead of High, Medium, and Low because I find that a numeric approach makes things more subjective than a High, Medium Low evaluation approach.

# Requirement Evaluation Criteria 1 (Reduce Manual steps) Evaluation Criteria 2 (Reduce paper through the process) Evaluation Criteria 3 (Reduce number of manual steps) Total Criteria Score
1 Requirement 1 3 5 1


2 Requirement 2 5 5 3


3 Requirement 3 1 3 1


4 Requirement 4 3 3 3



Typically, with the above scoring system I would then map it to the more traditional High, Medium, and Low using the following ranges:

Low – score equal to 5 or lower

Medium – score of 6 to 10

High – score of equal to 11 or higher

Based on the above you would then prioritize the requirements as follows:

# Requirement



Requirement 1



Requirement 2



Requirement 3


4 Requirement 4


Heat Map Variation:

Most stakeholders are very visual. So sometimes I’ll combine this with a heat map approach. With the heat map approach, each score on the scale is associated with a color.

Score of 1 – shade the cell red

Score of 3 – shade the cell yellow

Score of 5 – shade the cell green

So, if we take the above example and add colors, it will look like:


Requirement Evaluation Criteria 1 (Reduce Manual steps) Evaluation Criteria 2 (Reduce paper through the process) Evaluation Criteria 3 (Reduce number of manual steps) Total Criteria Score


Requirement 1 3 5 1


2 Requirement 2 5 5 3


3 Requirement 3 1 3 1


4 Requirement 4 3 3 3


As you can see above – it really jumps out at you that there is a “strong” fit with requirement 2 and a poor fit with requirement 3. I find the heat map approach helpful when there are a lot of requirements because it’s a lot easier to gauge and compare requirements based on colors than numbers. Also, a lot of times with a heat map you don’t need a total criterion score at the end. It just jumps out at you.

You can further simplify things by just using the colors instead of the numbers.

Does it take more time?

The simple answer is no it doesn’t take more time. All it takes is a little bit of prep, a prioritization meeting and then you have prioritized requirements. When you compare that to having numerous emails, meetings, and discussions about what the requirements priorities are you’ll see it’s a much simpler and effective approach. It also forces stakeholders to really think about the requirements and how they want to achieve their objectives – so less second-guessing of requirements in the future.

One final note:

When I use this approach, I put the actual scoring matrix into the appendix of the requirements document and not in the main body to enable a wider audience to more easily read the requirements document.

Requirements Scope Statements – a tool for establishing the boundaries of Requirements deliverables

The high-level requirements section of the BRD can have many purposes depending on the template you are using.

It can be used to document project information such as a summary of the project, the business objectives, problems/opportunities, scope (often project scope), high-level requirements (although in many cases detailed as opposed to high-level requirements are documented).

Arguably from the perspective of a BA who is responsible for Requirements Deliverables/the Business Requirements Document, the main purpose of the High-Level Requirements section is to establish the scope of the requirements deliverables for the project. That is not to say the other sections are not important from a context perspective – they are. However, the real key for the BA is to convey the boundaries for the requirements deliverables.

One way to set the requirements scope is by following the approach below to document Requirements Scope Statements (RSS) in the High-Level Requirements (HLRs) section of the BRD. I prefer to refer to them as Requirements Scope Statements (RSS) for the simple reason that they establish the scope of the requirements effort.

Guidelines for RSS:

  1. Document RSS using the following syntax (for those familiar with Agile development this is the same syntax that is used to document Epics/User Stories):
    must be able to/ will be able to do in order to .
    – An optional best practice is to indicate whether the requirement is met electronically or through manual means (see example below)
  2. Assign a unique identifier RSS00X in front of the RSS for traceability purposes.
  3. Never make a system/ application a stakeholder for two key reasons:
    a. These are Business Requirements, not system requirements/ design specs
    b. Systems/ Applications should always “do” things for the benefit of someone/ some group i.e. why does a system need to generate a report – for whose benefit?
  4. Document RSS in a table and add a column for priority
  5. The number of RSS depends, naturally, on the size/complexity of the project and number of stakeholders. As a general guide:
    a. Small projects a maximum of up to 6 RSS (remember these are just High-level requirements)
    b. Medium size projects a maximum of up to 15 RSS
    c. Large size projects a maximum of up to 25-30 RSS
    * Note: If you exceed the above guidelines in all likelihood the Business Analyst has gone from documenting High-Level Requirements to documenting Detailed Level Requirements
  6. RSS in Programs – my recommended approach is to document the RSS in the Program level BRD and then assign specific RSS from the Program level BRD to the component projects that make up the program. In general, an RSS from the Program should only be assigned to one and only one project. If the same RSS from the Program is assigned to more than one project, then I suggest breaking down the RSS into smaller RSS that can be assigned to the individual project.

RSS Example:

Reference No. Requirement Scope Statement Priority
RSS001 Investment Advisors must be able to view portfolio performance reports electronically to serve their clients.  


As you can see, from a requirements scope perspective you have identified:

  1. Stakeholders – Investment Advisors
  2. Requirement boundary – mid and detailed requirements (user stories in Agile) will be related to portfolio performance statements

Additional Benefits

In addition to establishing the scope of the requirements deliverables, the RSS provide additional benefits:

  1. RSS help BAs to determine what types of mid, detailed requirements will be produced which in turn provide BAs with the basis to create a high-level estimate of the effort needed to elicit, analyze, and document requirements deliverables
    For example in the above example you will probably have:
    – Data dictionary for the data elements in the reports and on the UIs
    – Mock-ups for the printed reports
    – User Interface (UI) Mock-ups for viewing the reports
    – Use cases (depending on whether or not the Business Analyst is playing a systems analyst role) related to generating, presenting and printing the reports
  2. RSS can trace to specific business objectives/problems/ opportunities to the RSS to ensure the needs are being covered
  3. RSS can also trace forward to Mid and Detailed Requirements (or vice versa depending on what traceability approach you are taking)
  4. RSS provide technology groups with a basis to provide high-level estimates of their efforts
  5. RSS enable BAs to make sure all the stakeholders are covered i.e. compare the stakeholder groups documented in the RSS against other documents/artifacts such as Stakeholder Impact Assessments or Context Diagrams to ensure all the stakeholders/ stakeholder groups are covered. If there is a gap, then RSS enable the discussion with other project team members to determine where and why there is a disconnect.

Sign off on RSS

Does RSS require a formal sign-off? The answer to this largely depends on the BAs organizational project methodology. In some organizations, the entire High-Level Requirements Section (including RSS) is signed off and baselined to help manage scope. In other organizations an email acceptance of the High-Level Requirements Section – specifically the RSS – from the project Business Owner, Project Manager is sufficient.

Ultimately there is no right way or wrong way – the organization just needs to define and follow whichever process they are going to follow.