Upskilling Your BA Team

AUTHOR: Virginie Terry

1. This is the way we’ve always done it…

One of the most common barriers to adopting new ways of working is a belief from the long-standing BAs that their delivery or operating models are different from the norm, or that their business stakeholders are unusual, and therefore different BA skills or standards apply. This is particularly true with BAs who have learned their skills on the job: internally and without any formal training. Typically, they will have moved from a different part of the business, and they know the ins and outs of specific departments, including the quirks of their systems. This can manifest itself as skills gaps (e. g. made up notation to model business processes); undertaking tasks which should legitimately sit in other areas (e. g. writing test scripts); or not being effective in their role because they don’t challenge their business stakeholders to work differently when defining to be processes.

These individuals need to understand internal expectations as well as the BA industry standards, and in particular the skills that as a manager you are looking for in new joiners. They need to appreciate that refusing to upskill could put them at a disadvantage in terms of the projects they work on or future career opportunities.

2. I’m looking to retire in a few years, why should I bother?

Not everyone thrives on learning something new and getting out of their comfort zone when they are counting the days until they retire.

As a manager, it’s only worth pushing if there is still time for these individuals to apply new skills before they retire. These BAs need to understand how this will improve or expedite some of the great work that they already do. For example, if you’re looking to get a BA trained on use case diagrams, you can easily demonstrate how much more engaging they are to project stakeholders than Jira tickets or an Excel spreadsheet when it comes to reviewing the outputs of a discovery workshop.

3. My project can’t afford to release me for any training, sorry!

A misconception which comes up time and again is the belief that project teams can’t afford to release their BA(s). The truth is that there is rarely a time in any project when a project or programme manager feels that they can afford not to have their BA(s) around, regardless of the stage of the delivery.

A tough one to win if project teams don’t have enough time to plan it. Give the BAs and project teams plenty of notice – ideally several months, so that the BAs can block the time in their calendars, and the project teams can plan for it. It’s important to show some flexibility and collaborate with programme and project managers, for example by staggering the training dates if multiple BAs work together on the same programme or project, rather than taking them all away on the same day(s)

4. I am too old to learn something new

Not quite the same as the BA who’s retiring soon, in this case we’re looking at BAs who may doubt their ability to learn and apply new techniques, or even have some anxiety about sitting exams because they are out of practice. You may also have a BA who’s just not very academic and really struggles with formal learning and assessment / exam situations.

Getting back into a classroom (albeit a virtual classroom) can be daunting. It is the manager’s responsibility to provide support and minimise stressors where possible. You should be able to negotiate revision sessions with your training provider in the run up to any assessment, and if not there is always internal support available from BAs who have already completed the training. Reminders about exam techniques and dealing with exam nerves are useful – as well as being honest with your team and sharing your own story. It is very powerful for team members to be aware that their manager may have gone through the same thing, and how they have overcome their own demons.

5. Celebrating success in the right way

It is necessary to find the right balance between celebrating the team’s successes, which is entirely legitimate and appropriate, and not inadvertently making people feel any pressure or “less than” if they haven’t taken the exams yet or they have failed.

Ultimately, as with so many situations, the key to success is for BAs to realise what’s in it for them. And in the vast majority of cases, once get a few people over the line – once they are, they become your strongest advocates and allies for change.

The Incredible Expanding Requirement

A simple requirement statement might conceal much detail that eventually must be discovered and addressed.

Image by kjpargeter on Freepik

Some requirements are like icebergs: The portion that you see initially is only a small fraction of the whole thing. Whether it’s represented as text—such as a single functional or nonfunctional requirement statement, a feature summary description, or a user story—or visually in the form of an analysis model, there could be far more to it than first appears. Requirements analysis involves digging below the surface of a presented requirement to understand its full scope, complexity, and implications.

Let’s consider a simple, common nonfunctional requirement: “Only authorized users may access system services.” That security requirement could have originated from a company policy, government regulation, or other business rule. Can you just hand that requirement to a developer, or maybe write it in the form of a user story and add it to the product backlog? I don’t think so. Peeling away the layers shows that that one requirement statement can expand enormously, raising many questions and spawning many child requirements along the way.

This raises the question of how much detail to document for an unrefined requirement versus leaving it in the hands of the developer to process as they see fit. In other words, who do you want to make all the decisions associated with a complex requirement, and when? Considering that question will help you manage the transition from requirements to design.

If you want an initial high-level requirement implemented in a specific way, the business analyst should elaborate it into the appropriate level of detail and precision. That elaboration could impose design constraints on the developer, albeit for good and thoughtful reasons. On the other hand, if you’re okay with the developer having the final say on the functionality and user experience details (preferably with feedback from others on design documentation, prototypes, or screen sketches), then just pass the higher-level requirement along for implementation.

Looking Below the Surface

Consider some of the questions you’d have to answer if you were the developer asked to implement our one-sentence security requirement. It’s unlikely that you’d have all the answers yourself. As you study the requirement, you’d have to make up those answers, research policy standards, or consult with others to agree on how to resolve each issue. That’s what business analysis is all about. Let’s see how quickly an exploration of this single requirement statement expands into many detailed requirements.

First, we’ll need a clear definition of exactly what an “authorized user” is and just what system services cannot be accessed unless a user is authorized. Do different parts of the system require different privilege levels or access credentials?

How should each user be uniquely identified? With a login name, an email address, using a third-party account (like Google, Apple, Facebook, or X), or something else? Will the user ID be assigned by a sys admin or user-selected? What are the rules for the user ID: minimum and maximum length, allowed characters, and case sensitivity? What happens if the user selects a user ID that’s already in use?

Next, what is the primary user authentication mechanism? We have numerous choices, including password, passkey, PIN, and biometrics of various kinds. Let’s just think about the venerable password for now. Here are some questions that come to mind regarding passwords:

• What are the rules for the password: minimum and maximum number of characters; allowed, prohibited, and required; characters, case sensitivity; pattern restrictions (such as no more than two instances of the same character in sequence); required patterns (such as at least one each of upper- and lowercase letters, numbers, and symbols)?
• Must the user re-enter the same password in a separate field during creation to verify it? If so, what happens if the two entered passwords don’t match?
• Can the user toggle the visibility of the entered password on and off, either during creation or during logins?
• How is the password masked in the entry field? With asterisks or dots? One symbol per entered character or a random number of symbols to conceal the password length from an onlooker?
• What feedback will the system provide if a login attempt fails?
• Is the user blocked after too many unsuccessful login attempts? If so, how many tries do they get?
• If the user’s account is locked after too many failed login attempts, how long does the account remain locked? How can the user unlock it?
• What happens if the user forgets their login ID or password? What recovery method is used? I can’t get into my original YouTube account because I’ve long since forgotten the password, and the phone number on the account cannot receive texts. Google offers me no other identity verification options.
• Must the user change their password periodically? If so, how often? Are there restrictions on what the new password can be, such as not reusing any of the previous N passwords?
• Can the user define a personal identification number (PIN) as a shortcut for the password, as on a Windows PC? If so, what are the allowable characters and the minimum and maximum length of the PIN?

These are some of the issues associated with specifying a security requirement for just a simple password mechanism. You can see how the answers to those questions lead to more and more functional requirements to satisfy the nonfunctional security requirement. But the expansion can get much worse.

The Many Modes of MFA

If your project’s decision makers want better security than a password provides, you’ll explore multifactor authentication (MFA) options. You’ll need to choose from numerous options for both MFA techniques and their implementation details. Start by deciding what types of MFA the system should enable to provide the desired security level. Options include:

• Sending a one-time code that the user must enter to verify their identity
• Sending an email containing a one-time login link
• Biometrics, such as fingerprint, facial recognition, voice ID, and iris or retinal scan
• A physical security token
• Using an authenticator app, perhaps on a second device

Here are a few more general questions:

• How many of these MFA options should you make available to the user?
• If more than one, can the user select their default preference to use initially for each login attempt? Can they change that default?
• How will the user enable and disable MFA on their account?
• If for some reason the user can’t employ their initial method (such as not having access to the device with the authenticator app), can they select another method for that session?
• Will there be some other backup action, such as contacting customer support, in case none of these MFA methods work for the user?

Let’s take a closer look at just the technique of sending the user a one-time code. Contemplate these questions:

• What options will you provide for sending the code: text message, e-mail, or phone call? Will the user have more than one option available?
• If text message or phone call, can the user save more than one phone number in their application’s profile? Can they specify the default and select the number to use for each session? Can they change or delete a saved number or change which is the default?
• How many characters are in the one-time code and what are the valid characters?
• How long is the one-time code good for? If it’s limited, should the application display a countdown timer? Can the user request to have the code re-sent? If so, is the same code sent again or a new code? What happens if the user enters the one-time code after the time-out period?
• What happens if this secondary authentication attempt fails? Is the entire login session terminated, or can they try the MFA again? How many tries does the user get at the MFA action? If it’s limited, do attempts using different methods all count toward the limit?
• Can the user opt to have their authenticated device and login recognized for some period of time so they won’t have to re-authenticate for each session? If so, how long is that period? Where should that information be stored? I use some apps that recognize my device even if I restart my browser, while others lose my remember-me setting whenever I clear the browser cookies.

I’m sure there’s even more to it than this, but you get the picture. Drilling into the particulars of an initial, concise requirement statement often opens a sizeable can of worms. The answers to the resultant questions lead to an explosion into more and more requirements. This fact is true whether the exploration is performed by a business analyst during requirements specification or by a developer who’s been tasked to write the user authentication code. The original requirement isn’t actually growing, so this process isn’t changing the project’s scope. It’s merely revealing the true scope.

The good news is that if you can craft a well-thought-out set of requirements for a complex function like user authentication, you can likely reuse them in multiple applications. At the least, they should provide an excellent starting point.

Beware the Blast

I’ve used a common nonfunctional requirement to illustrate how much complexity can hide beneath the tip of that requirement iceberg. The same can apply to functional requirements and product features, of course.

One of my consulting clients held a large workshop to gather requirement ideas for a new flagship product. One of the requirements stated, “The product shall respond to editing directives entered by voice.” This was at a time before speech recognition capabilities were built into all of our devices. That one simple requirement statement looked to be no bigger or smaller than all of the many others in the set. However, you can guess how large the requirements explosion would be when someone looked into everything involved with the details of that speech recognition feature.

Understanding the true scope of a requirement so your team can estimate and plan for its design and implementation often requires a fair amount of exploration. During that exploration, you can set the priorities of the various child requirements, perhaps deferring some functionality to later development iterations and maybe never implementing others. That thinking process is less painful than encountering one additional, unexpected need after another and continually revising the product.

======

Karl Wiegers is the author of Software Requirements Essentials (with Candase Hokanson), Software Requirements (with Joy Beatty), Software Development Pearls, The Thoughtless Design of Everyday Things, Successful Business Analysis Consulting, and numerous other books.

In today’s fast-paced business environment, artificial intelligence (AI) is often heralded as a panacea for a wide range of organizational challenges. Whether it’s optimizing supply chains, improving customer service, or enhancing decision-making processes, AI promises to revolutionize how businesses operate. However, as any seasoned project manager or business analyst knows, the reality is far more nuanced.

Many executives, driven by the latest headlines or industry trends—often referred to as “managing-by-magazine”—may come to you with the next “big idea” for an AI project. While their enthusiasm is commendable, it can also lead to unrealistic expectations and poorly defined projects that fail to deliver the promised results.

The Problem with AI Hype

The marketing surrounding AI often paints it as a silver bullet capable of solving any business problem. This can create a disconnect between what executives expect and what AI can realistically achieve. Without a clear understanding of AI’s limitations and the specific problems it can solve, organizations risk investing in projects that deliver little to no return on investment (ROI).

As a project manager or business analyst, your role is to bridge the gap between executive enthusiasm and practical outcomes. This involves not only understanding AI technology but also being able to communicate its potential and limitations in a way that resonates with decision-makers.

Start with the Use Case

The first step in any AI project should be to thoroughly discuss the potential use cases. What specific problem is the AI solution intended to solve? How will success be measured? By framing the conversation around use cases, you can help executives focus on the practical applications of AI rather than getting swept up in the hype.

For example, if an executive is excited about using AI to improve customer service, you might start by discussing how AI could be used to automate routine inquiries, allowing human agents to focus on more complex issues. From there, you can explore the potential ROI, such as reduced call times or improved customer satisfaction scores.

Identify Specific Deliverables

Once the use case is clear, the next step is to identify specific deliverables. What tangible outcomes will the project produce? These could be anything from a working prototype of an AI-powered chatbot to a detailed report on how AI can be integrated into existing workflows.

By focusing on specific deliverables, you can help manage executive expectations and ensure that the project remains grounded in reality. This also makes it easier to track progress and measure success, as you will have clear milestones to work towards.

ROI: The Bottom Line

One of the most critical aspects of any AI project is identifying the potential ROI. This involves not only estimating the financial return but also considering the broader impact on the organization. Will the AI solution improve efficiency? Reduce costs? Enhance the customer experience?

ROI calculations should be revisited regularly throughout the project lifecycle. As new information becomes available, it’s important to reassess the potential benefits and adjust the project scope as needed. This iterative approach ensures that the project remains aligned with organizational goals and delivers real value.

Refine Through Requirements Gathering

Even with a clear use case, specific deliverables, and a well-defined ROI, it’s essential to continually refine the project scope through requirements gathering sessions. These sessions allow you to gather input from various stakeholders, identify potential challenges, and ensure that the project remains on track.

During these sessions, it’s important to ask probing questions to get to the heart of the matter. What are the underlying business needs? How will the AI solution integrate with existing systems? What data will be required, and how will it be managed? By addressing these questions early on, you can prevent scope creep and ensure that the project stays focused on its core objectives.

Advertisement

The Power of Business Process Mapping (BPM)

One highly effective tool for refining project scope and ensuring alignment with business objectives is Business Process Mapping (BPM). BPM is a visual representation of an organization’s workflows and processes, and it can be instrumental in highlighting inefficiencies, redundancies, and gaps within current operations.

Before diving into an AI implementation, BPM can help you and your stakeholders gain a clear understanding of how work is currently being done. By mapping out existing processes, you can identify where AI might be most beneficial, as well as areas that may need improvement before AI can be effectively integrated.

For instance, if a process map reveals that a significant amount of time is spent on manual data entry, this could be a prime area for AI automation. Conversely, if a process is already highly optimized, it might not be the best candidate for AI enhancement, helping you avoid misallocation of resources.

BPM also serves as a communication tool, providing a common language for discussing process improvements. It enables all stakeholders to visualize where changes will occur, what the expected outcomes are, and how the AI solution will fit into the broader organizational landscape. This transparency can help prevent misunderstandings and ensure that everyone is on the same page regarding the project’s goals and expectations.

Conclusion: Turning AI Hype into Real Results

AI has the potential to transform businesses, but it’s not a one-size-fits-all solution. By taking a thoughtful, measured approach to AI projects, you can help your organization avoid the pitfalls of “managing-by-magazine” and achieve real, tangible results.

The key to success lies in grounding executive enthusiasm in practical outcomes. This involves thoroughly discussing use cases, identifying specific deliverables, calculating potential ROI, and continually refining the project scope through requirements gathering sessions. Additionally, leveraging tools like Business Process Mapping can provide valuable insights into existing workflows, highlighting areas where AI can be most effective and ensuring that the project delivers real value.

By following this process, you can ensure that your AI projects are not only aligned with organizational goals but also contribute to the long-term success of your organization.