The Responsibility of the Business Analyst in Creating and Enacting AI Governance Frameworks

Author: Tosin Clement

Artificial Intelligence (AI) is transforming the way we conduct business by providing unprecedented opportunities for innovation, efficiency, and autonomous, algorithmically based decision-making. However, as AI applications become more complex, ethical, legal, and operational challenges will emerge. A strong governance framework will become the norm to facilitate responsible AI systems. Business analysts (BAs) are uniquely positioned to aid organizations in this process because they sit at the management interface between the business purpose and the technology solution.

Understanding AI Governance

AI governance represents the policies, procedures, and standards that provide structure for the development, deployment, and ongoing management of AI systems. Governance will ensure that AI applications are as transparent, accountable, and ethically compliant as required. Governance of AI will cover some or all of the following areas:

• Risk Management: Understanding and managing the potential risks AI presents, including any associated risks of transparency, bias, privacy, and unreasonable consequences.
• Compliance: Understanding and ensuring compliance with statutory and regulatory obligations for protecting data, accountability for algorithms, and ethical responsibilities.
• Transparency: Ensuring that any decision-making processes, including AI involved where appropriate, can be explained and/or understood by stakeholders.

Changing Role of Business Analysts

Historically, the role of BAs in traditional project planning and implementation has focused primarily on understanding a key stakeholder’s requirements and being able to communicate those requirements to project teams to ensure the solution meets the stakeholder’s business needs. BAs also facilitated communication between other stakeholders to determine the project requirements. In fact, in an AI governance process, the role of BAs will have transformed further; they will become responsible for:

• Managing Stakeholders: Engaging diverse stakeholders (data scientists, legal team, ethicists, etc.) to gather comprehensive requirements for AI systems.
• Policy Development Support: We can assist in developing AI policies by translating complex, technical concepts into language that business leaders can digest.
• Process Integration: We can help by integrating AI governance considerations into current business processes or workflows to facilitate adoption.

Ways that BAs Will Contribute Practically to AI Governance

Requirements gathering and analysis: BAs can identify the required AI project needs and restrictions and assist in developing a governance framework that addresses the real-life problems and business needs.

Facilitating Communications: BAs can facilitate communications to put technical teams into a business context, ensuring the business understands AI’s operational ability and limitations.

Monitoring and Evaluation: BAs can create metrics and KPIs to evaluate the effectiveness of AI project governance frameworks to ensure continuous improvement and accountability.

Training and change management: BAs can continue their traditional role for organizations by leading training for stakeholders on AI governance principles and managing the organizational change associated with AI.

Example – AI Governance in Healthcare

Imagine a healthcare organization that wants to use AI to assist in its diagnostics.

• The BA will engage with medical practitioners to understand their diagnostic requirements and gather medical ethics considerations.
• The BA will work closely with data scientists to introduce the AI model, which is trained in representative and non-biased data.
• The BA needs to work with legal and privacy teams to ensure they comply with all the healthcare regulations and any applicable data privacy laws.
• The BA will assist in developing processes for ongoing monitoring of the AI tool’s impact on their patient summation reports, the patient decisions, and the patient’s outcomes.

By doing this work, the BA verifies that the AI application meets the healthcare organization’s technical specifications and ethics while generating sustainable value to the organization and its patients.

Summary

As technology continues to influence modern businesses, specifically AI, emphasizing good governance frameworks is very important. BAs are positioned to have the breadth of understanding of their businesses’ processes and stakeholders’ expectations to implement these governance frameworks. By embracing the role and task afforded to BAs’ position within organizations, BAs can help ensure the organization is correctly adopting AI technologies for sustained value, innovation, and value for the organization and society.

Author Bio

Tosin Clement is a Business Intelligence Analyst with over five years of experience across consulting, healthcare, and e-commerce sectors. She specializes in transforming complex datasets into actionable insights, with a focus on integrating metrics into business analysis to drive strategic decision-making and operational efficiency.

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.