Tag: Stakeholder

The Digital BA Series: How BAs Can Help Reduce Bias in Hiring Caused by AI-related Bias

Written by Elizabeth Larson on June 13, 2019. Posted in Articles.

A recent article in Harvard Business Review (HBR) raises an interesting question:

do hiring algorithms used by companies to recruit staff prevent bias or amplify it?[i] Their conclusion is unclear. The article warns that the technology has to be “proactively built and tested” to remove any intentional or unintentional bias.”[ii] In this article I want to make the case for why the business analyst (BA) is the organization’s best-hope for ensuring that AI technology is built and tested to avoid this bias.

But first a little background related to how organizations are using AI/machine learning in various stages of the recruitment process.[iii] Companies are already using AI to help them recruit candidates. They want AI to help them:

Reduce recruiting budgets
Score resumes
Find candidates who will fit the job description
Advertise jobs in venues apt to draw the best candidates
Assess candidates’ qualifications
Add consistency to the recruiting process

However, these benefits can easily backfire. Let’s look at a couple of examples.

Reduce recruiting budgets. With machines taking over some of the functions formerly done by live people, organizations hope that in the long run the cost of the recruiting processes will be reduced. However, the long run is very long and the road is rife with pitfalls so the expected cost savings may not be realized. Not only are there technical challenges, but it is likely that the organizational culture will need to change as well.
Score resumes. When scoring is based on historical data that contains built-in biases, the machine learning algorithms can learn those biased patterns and use them going forward. Data such as the candidate’s name (Susan vs. Sujata for example) or sports played in school (hockey vs basketball perhaps), might produce unforeseen results.
Find candidates who will fit the job description. Again, let’s say that historical data has shown that a certain type of candidate has traditionally been successful in the organization. It might be natural to program the algorithms to look for candidates with those same characteristics, thus replicating institutional biases.

In addition, it can increase bias in unforeseen ways.

Predictive algorithms help advertise job openings and play the role of head hunter. That is, it can find both candidates who are actively seeking jobs and those who are not. On the surface this sounds good. But if algorithms suggest advertising the job in venues that cater to a certain class of candidates, such as men, chances are only men will apply. The organization might be able to say, “Well, we looked for a woman, but none applied.”
Such biases may not reflect the diversity of the company’s customers. This is particularly true for large organizations with diverse customers and/or global companies.
Some algorithms have been known to predict who will click on an ad rather than who’s apt to be the most successful candidate.

One way organizations avoid some of these digital pitfalls is to ensure that business analysts are included on these digital projects. A BA can help in many ways. Here are just a few examples:

Evaluate software options. They can help in the evaluation of AI tools and recommend only those that do not promote the kinds of biases discussed above. Helping with commercial software selection and implementation has always been something BAs do well. This assumes, of course, that the BA has done their homework and has become familiar not only with various options available, but also with how AI is being or will be used throughout the organization.
Examine the algorithms. This means that the BA has to actively engage with the data scientist (or person creating the algorithms) to understand the type of algorithm being used and why. The BA needs to ensure that the algorithms being used will promote the goals and objectives of the organization and that the AI effort is meeting a real business need. Part of examining the algorithms is to look at is how to measure the success of potential candidates. BAs need to look the end-to-end recruitment process and where AI is used in each part of the process in order to detect where the potential for built-in biases may occur.
Cleaning the data. It is well-known that one of the aspects of AI that most people dread is cleaning the data. Yet data cleansing has to be done if the results of the machine’s predictions are to be trusted. Part of this cleansing process is to examine the historical data to ensure it doesn’t contain underlying biases.
Testing the software. BAs can help proactively test these tools with the goal of removing biases in mind. The BA can review test cases to ensure that any biases are thoroughly tested and that anomalies are called out and removed.

To summarize, there are many ways for bias to find its way into AI recruiting technology. Business analysts can add a tremendous value to organizations by helping them recognize and remove biases from these applications.

[i] All the Ways Hiring Algorithms Can Introduce Bias, by Miranda Bogen, May 06, 2019, HBR, https://hbr.org/2019/05/all-the-ways-hiring-algorithms-can-introduce-bias

[ii] Ibid.

[iii] In this article I’m going to use the terms AI and machine learning interchangeably although there is a distinction.

Tyrion the Trusted Advisor: What Game of Thrones Teaches Us about Influencing Without Authority

Written by Elizabeth Larson on May 23, 2019. Posted in Articles. 1 Comment on Tyrion the Trusted Advisor: What Game of Thrones Teaches Us about Influencing Without Authority

I have always loved the Game of Thrones TV series.

And what has fascinated me the most is the treatment of the Trusted Advisor, beautifully portrayed by Peter Dinklage as Tyrion Lannister. Tyrion embodies important ingredients of a trusted advisor who influences decision-makers as we’ll see below (warning – some plot spoilers ahead)

To influence without authority, we need to establish trust, be prepared, and have courage

Simply put, it’s impossible to influence anyone who doesn’t trust us. In the Game of Thrones (GOT) trusted advisors are called Hands, probably because they are really the right-hand of the king or queen and it is a highly powerful position. Hands have the ear of the ruler, but if the ruler doesn’t trust the hand—watch out! In Season 1, for example, the Hand to King Robert Baratheon is Ned Stark, who reluctantly accepts the position. Although King Robert trusts him and accepts his advice, his queen does not. When the king dies, the queen and her ruthless son, behead him in a shocking warning of what happens to advisors who are not trusted.

Tyrion, on the other hand, is not initially trusted by anyone. However, throughout the series he works to establish trust by being prepared before giving any advice to his queen, Daenerys Targaryen, and by having an overabundance of courage. Early in the show Tyrion is an exhaustive reader, doing his homework and his advice, as Daenerys slowly realizes, is usually sound. When she follows his advice, it almost always works (I know fans, there are instances when Tyrion gets fooled). When she doesn’t listen to him, things don’t go well for her. For example, in the penultimate episode, Tyrion advises sparing the lives of innocents, but Daenerys rejects that advice, leading to her ultimate destruction. And as Hand, Tyrion shows unimaginable courage when he provides advice knowing that it’s unwanted, but also knowing it is absolutely the right course of action.

One more example of Tyrion’s courage. In the last episode of Season 8, Tyrion understands that he can no longer support a Queen who wants power so much that she is willing to do just about anything to get it. Although he knows that he will be arrested for “treason,” Tyrion cannot support such actions. In an act of defiance that he knows will condemn him to death by dragon fire, he deliberately resigns his post, taking off his Hand badge and throwing it away.

Our projects require us to build trust, to be prepared before giving advice to decision-makers, and to be courageous. In some organizations it takes a great deal of courage to be the bearer of bad news as when we need to provide accurate project status or when we point out risks. Although not as dire as in the GOT, it still takes courage to recommend the right thing for the organization. Not all decision-makers want to hear from us about why the organization should move in a new direction, or develop a new process, or build a long-term solution when the organization wants short-term fixes. What gives us courage, of course, is knowing what we’re talking about. It’s having the facts and the statistics to back up our recommendations. It’s being prepared. It’s also the ability to articulate and sell our recommendations. When our recommendations turn out to help our organizations, we, like Tyrion, gain credibility and build trust.

To influence without authority, we need to provide advice to the decision-makers, but not own the decisions.

In an episode a few seasons ago Tyrion gave Daenerys a piece of advice that she refused. Tyrion then says to another advisor, Lord Varys, that he, Tyrion, can give the queen his advice, but he can’t force her to take it. In Season 7 Tyrion advises against killing traitors with dragon fire. When she kills them anyway, Tyrion agonizes over what he could have done to stop her.

This is what we call the trusted advisor’s dilemma. We need to provide advice—good, sound advice backed up with facts, but we are not the decision-maker. We can point out risks and consequences, but we cannot make the decisions ourselves. We want to make our advice so sound that if we know the decision-makers are off course we can convince them of another course of action, but that is not always possible. The only thing we can do is to ensure that our recommendations are in the best interest of the organization and not promoting our own personal goals, even when our goals seem in conflict with the organization’s.

The trusted advisor’s dilemma: “We need to provide advice—good, sound advice backed up with facts, but we are not the decision-maker.”

Years ago I was a manager in the unenviable position of having to eliminate an entire department. The department supervisor remained positive throughout, recommending shut-down and transfer processes. Somehow, he communicated the business need for the shut-down and his own optimism to the staff. In the end he was promoted and none of the staff lost their jobs.

Respect, authenticity, and empathy help us to influence without authority.

Throughout the 8 seasons of Game of Thrones, Tyrion experiences tremendous growth. He goes from being not much more than a selfish, heavy-drinking womanizer to a Hand who agonizes over the consequences of his advice, his conflicting loyalties, and giving advice that truly benefits the realm, rather than what’s best for him. He becomes a true friend, caring brother, and overall good guy. He shows respect for the would-be Queen, even when she makes terrible decisions. He demonstrates authenticity (we can see his pain), and empathy for his friends. By the end of the series Tyrion becomes perhaps the most influential character.

In our organizations we have a greater influence when our approach is respectful, authentic, and empathetic. Expertise alone does not create competency. Most people do not relate well to “know-it-alls,” and trying to showcase our expertise rarely builds credibility. We are most successful when we use our expertise to support the organization, rather than for personal gain or visibility.

To summarize, as trusted advisors we provide our advice, but we do not make decisions. We build trust in many ways, including establishing credibility by being prepared when we make recommendations, being respectful and empathetic when giving our advice, and by showing courage.

A “Novel” Way of Gathering Requirements

Written by Kathleen Booker on May 9, 2019. Posted in Articles.

You look at the clock. The hands tick toward midnight.

You know that you should not be up this late because you have a meeting with your project team first thing in the morning. But you simply cannot put the book down. The latest novel by your favorite author is one of the best you have ever read, and you are so deep inside the protagonist’s head that you lost all track of time. It is the turning point for the main character, so you sigh deeply and concede that you have to read just one more chapter.

As you finally put the book down and rest your head on your pillow, you think about how well the author lays out the characters and plot. Being an avid reader, you recognize that this particular novel is written in third person omniscient point of view. The thoughts, desires, needs, and motivations of the characters in the book are all there for you to examine and absorb. With this point of view, it is easy to relate information about and between each character in the story. When any novel is weaved in such a way that the reader gets lost in the pages, when he or she understands each character’s plans and goals, and when there is insight into potential outcomes, the writer has done his or her job well.

As project managers, our objective is not to present a best-selling novel to our stakeholders, but we should be creating well thought-out and complete (as possible) requirements documentation as if we are writing from the third person point of view. It is up to us to make sure that the requirements are in tune with each of the stakeholders’ desires and needs and, of course, what the project goals demand. To accomplish this, we must get inside their heads to make sure we understand the thought process behind the requirements.

In the PMBOK® Guide a requirement is defined as “a condition or capability that is necessary to be present in a product, service, or result to satisfy a business need.” It is important to note that just like many things in business (and in life) one person’s definition of satisfying a need may be a lot different from another person’s.

Achieving an as-perfect-as-possible requirements document takes time and effort, and like writing a novel, this part of project management, in my opinion, can be an art. Just as a writer might have several drafts of his book before it is ready for publication, so too will the PM have a requirements document that may go through several iterations before the final version will be circulated to the team (and even final versions can be subject to change). Each requirement needs to be dissected and assessed to determine if any errors in assumptions or conflicts between individual stakeholder input exist. Key in this requirements gathering process is that the project manager has a good understanding of what each one means. You do not need to be a subject matter expert, but you do need to have a high-level understanding of the requirements. Make sure you ask your stakeholder enough questions if you do not grasp the purpose of the requirement so that you can document it accurately. In other words, get inside the stakeholder’s head to extract exactly what he means, not just what he says. Make sure it aligns with the project charter and scope, and insure there is a clear vision of how it fits in the plan. Everyone, not only the stakeholder, should be able to understand the purpose of each requirement.

If conflicts arise between what one stakeholder requires and what another stakeholder desires, a good course of action might be to meet with both of them to discuss the nuances and come to a common ground. Resolution may not come at once, but the conflict must be addressed as soon as possible. The solution may become apparent while creating the cost or risk management plans; or perhaps it is a time or quality concern that will dictate how to proceed. It is possible that a conflict will not be fully resolved until the proof of concept phase. It is in everyone’s best interest to try to resolve issues while insuring the best possible outcome. But keep in mind, that while stakeholder “A’s” requirement may have initially been deemed more in line with the project goals, since requirements management is iterative, it could happen that Stakeholder “B’s” requirement may turn out to be better suited to the project.

Ultimately, it is the PM’s job to make sure that all documented requirements are clear, concise, and achievable. Each stakeholder and project team member should be able to read the document and envision how each requirement contributes to the project. It should be apparent that the PM has put in the time and effort necessary to develop the requirements story that will engage the team and propel the project to a successful outcome.

5 Killer Questions Types For Digital Transformation

Written by Elizabeth Larson on March 26, 2019. Posted in Articles. 1 Comment on 5 Killer Questions Types For Digital Transformation

A recent article concludes that for an organization to get the desired results from their digital initiatives,

such as data analytics, predictive analytics, machine learning, AI, etc., data scientists have to ask the right questions.[i] The article was written as a guide for data scientists to help them ask questions to get at the business decisions needed to be made when developing predictive models for these applications.

However, the article’s questions are stated in a way that might cause even the most informed business stakeholders to scratch their heads. If most decision-makers can’t answer them knowledgably, what can the organization do? Get BAs involved, of course! Having a BA participate in the question and answer sessions can alleviate a great deal of misunderstanding and help ensure success with digital projects.

This article imagines that for each of the 5 question types, there is a three-way conversation with a data scientist, a business decision-maker, and a BA. The questions the data scientist asks are from the article, which the BA rephrases to be more easily answered.

Type 1 – Alignment with the organization’s goals and strategic direction

Data scientist to business stakeholder – First things first. What exactly do you want to find out with this digital effort?

Business stakeholder to data scientist – I’m trying to predict sales of a new product we’re thinking of launching.

Business analyst to business stakeholder:

I’m sure this project can help with that effort. But before we talk about specifics of the types of information you’re looking for, what is the business need for this effort? That is, what problems are you trying to solve? Let’s make sure this initiative, which is not going to be an easy undertaking, will address your need. Perhaps there is a quicker, less costly way to achieve your goals. And I have some related questions that will give us more context:

How does this effort align with the strategic direction of the organization?
What are does the organization do well that will help ensure the project’s success and minimize risks?
How will this project help overcome some of the things we don’t do so well?
What opportunities are out there and how can the organization take advantage of them?
What should we be worried about? How are competitors, for example, doing with their digital initiatives?

Type 2 – Scope of input needed to create and train models

Data scientist to business stakeholder – Where will your data come from?

Business stakeholder to data scientist – I’m sorry, I don’t know the names of the specific databases. I thought I was here to make business decisions, not answer questions best answered by the IT folks.

Business analyst to business stakeholder – At this point we don’t need to know the names of the specific databases. What we mean by where the information will come from are things like:

Which business areas will be involved in this project?
Which stakeholders will have input into the decisions affecting the creation of the models?
Given that this effort will affect divisions in different parts of the world, who will establish the business rules?
What types of information will come from other sources, like social media and Google analytics?

Type 3 – Data presentation

Data scientist to business stakeholder – What data visualizations do you want us to choose?

Business stakeholder to data scientist – I’m sorry, I don’t understand what you mean. Do you mean like how I want to see the data? If so, I don’t know. What are the possibilities?

Business analyst to business stakeholder – There are a lot of tools that will take the data and interpret the results for you. They help you make sense of the tons of data you’ll be presented with. They can help you analyze data, point out anomalies, and send out alerts that you specify. They can be in the form of charts, dashboards, or whatever, but keep in mind that if they are hard to read, they will be meaningless to you. I can show you some examples and the pros and cons of such things as animation and use of images, but first let’s talk about the information itself.

What results are you hoping to get?
What type of predictions about your customers would be helpful? Your products?
What types of trends would be helpful to you in making business decisions?
What types of exceptions do you want to be alerted about?
What information do you want that’s actionable vs. historical?

Type 4 – Statistical analysis leading to the desired outcomes

Data scientist to business stakeholder – Which statistical analysis techniques do you want to apply?

Business stakeholder to data scientist – Well, statistics is not my strong suit. What are my choices?

Data scientist to business stakeholder – Regression, predictive, prescriptive, and cohort, and there are others, like descriptive, cluster.

Business stakeholder to data scientist – blank stare

Business analyst to business stakeholder – Maybe I can help here. These types of statistical analyses have a number of similarities. They include use of historical data, algorithms, models to train the machines, and business rules. Not to oversimplify and at a very high level, all predictive models make use of historical data and algorithms to predict future outcomes.

Here are questions based on examples of different outcomes using different statistical analysis:

What groups of customers do you want to target? Cluster analysis classifies data into different groups and can help you target certain customer groups.
What types of trends do you want to track? Cohort analysis allows you to compare how groups of customers behave over time.
What kinds of recommendations might you want as a result of the analysis? Prescriptive analysis not only predicts future outcomes, but it will “prescribe” or recommend the best course of action.

So to answer the question we need to understand what you’re trying to accomplish. We’ll let her (nodding to the data scientist) figure out the most appropriate analysis method and tool.

Type 5 – Creating a data-driven culture

Data scientist to business stakeholder – How can you create a data-driven culture?

Business stakeholder to data scientist – We already have a data-driven culture. Everyone in this organization understands how important data is to our ability to survive as an organization.

Business analyst to business stakeholder – This might be more complex than it first appears. In order to use historical data, which we need to do regardless of the chosen algorithms, it needs to be cleansed. Cleansing is needed to make the data predictive, and cleansing data takes lots of time and money. And it’s the last thing anyone wants to do. So I have some questions for you:

What’s the organizational commitment to cleansing dirty data?
Who will decide how clean the data needs to be? How clean is clean enough?
Who will decide who owns the data when the same data exists in multiple databases? In order to get the outcomes we want, there needs to be one single source. If the same data exists in multiple databases, someone needs to be its sole owner.

In sum, we’ve provided questions within 5 question types. However, to be effective, we BAs need to learn as much as we can about the digital world—about the world of digital transformation and what it means for the organization. We need to immerse ourselves in research and journal articles and think of how to make sense of it for our organizations. We need to think of digital projects from both the data scientist and business perspectives. And we can do that. After all, we’re BAs and that’s what we do best.

[i] Your Data Won’t Speak Unless You Ask It The Right Data Analysis Questions, By Sandra Durcevic in Data Analysis, Jan 8th 2019, https://www.datapine.com/blog/data-analysis-questions/

Why Don’t They Get It? Understanding Learning Preferences for Better Business Analysis

Written by Janelle Edge on February 8, 2019. Posted in Articles.

I am not a visual person.

This came to light early in my career when a stakeholder came to me with a beautiful diagram full of lines and colors and a few keywords. He handed me the picture and very proudly stated, “Here. This is what we want to do”, and then walked off. I stared at it for the longest time. There may have been tears. I spent hours translating that beautiful nightmare into written language trying to figure out what I was being told. My stakeholder was attempting to communicate with me the most efficient way he knew how, and yet I had a huge disconnect. There was no shared understanding. Eventually, I did figure it out, but it was a very frustrating process.

I never saw any value in images, so until this defining moment, I saw no value in including them in requirements. A picture may be worth a thousand words, but my question is, which thousand and what do you mean by them? For me, only words could answer that. Visuals just took up space and duplicated information that was already there.

Now I have much more empathy for those who rely on those symbolic representations. That one interaction started me on my search to incorporate all learning preferences into my business analysis processes. There was a lot of information on adapting teaching styles for each type of learner, but I could not find good examples of utilizing different techniques for different learning styles outside the classroom. Most people can absorb basic information through any method, but complicated material is easier to understand and retain when communicated in their preferred method(s).

Learning preferences can be categorized in several ways. However, for purposes of this discussion I will use:

Visual – Preference toward pictures, images, and spatial understanding
Auditory – Preference toward sound and music
Linguistic – Preference toward spoken and written language
Kinesthetic – Preference toward body, hands, and sense of touch

Most people have a combination of the above learning preferences. However, Business Analysts are a communication bridge for everyone on a project, so we don’t get to have a weaker area. We must learn to work within all learning preferences, regardless of our own personal style.

My first step was to take a free online self-assessment. My results were not all that surprising – Read/Write 13, Aural 8, Kinesthetic 5, Visual 1. That’s right. A one. No wonder mind maps trigger hyperventilation and all sorts of other stress responses! Unfortunately for me, visual is one of the most common learning styles. I needed to learn to speak that language quickly. I wasn’t going to become fluent overnight, but I at least needed to become proficient.

So, what’s a BA to do?

I now knew how crucial it was to start using visual aids. I created a guide to help me remember how to use several common diagramming tools. I started by using illustrations that were similar to my preferred linguistic style such as process flows and matrices, then expanded from there. I often refer to my catalog of visual aids for ideas on how to bring that aspect into my requirements as well as a reminder before joining large group meetings.

I’ve seen a lot of success since I consciously started considering diagrams and other images in requirements. I’m getting more feedback. I take that to mean more people are reading and approving the content rather than just approving to stop my nagging. I’m still not able to start with creating a visual rather than text, but maybe it is like a foreign language and I can get there with enough practice. I take consolation that I’m helping everyone get to that mutual understanding.

What are your learning style preferences? Are there any that you would like to improve?

Look for ideas in the lists below if you are struggling with a specific audience. Turn to your peers as well. If you notice someone skillfully incorporates a learning style, ask them for some ideas to expand your communication strategy or ask them to be a test audience when you try out a new technique. Once we’re aware of our own learning style preferences as well as those of our stakeholders, it becomes much easier to spot potential misunderstandings earlier or prevent them entirely – saving time, minimizing frustration, avoiding rework and helping us achieve a successful project.

Visual (learn through seeing)

Visual learners prefer:

Drawing pictures on the whiteboard
Organizing concepts into separate areas on the whiteboard to create “piles” that can be worked through
Color coding
Including diagrams of overall concepts in requirements documentation

How you can get there:

Allow yourself time to translate into a picture.
Arrive early for key meetings to create models on whiteboards or allow pre-meeting prep time to create images that can be shared virtually.
Write a legend for color coding and reference it as you write.
Review documentation to find areas that can be displayed pictorially.

Auditory (learn through hearing)

Ever had someone ask to discuss an email or an invite, even with a clear agenda? I had a Project Manager that was an egregious offender. Every email, instant message and meeting invite sent was followed by a call. Everything was discussed at length until she understood. She is a purely auditory learner.

Auditory learners prefer:

Earworms
Minimizing silence during meetings
Repeating things out loud
Meeting in person rather than discuss through email

How you can get there:

Keep and follow a meeting agenda so that you always know what to discuss next. (Always a good idea regardless of who is in the meeting.)
Incorporate music where appropriate, such as at the beginning of a workshop while people are finding their seats.
Ask the auditory learning participant to summarize the meeting or concept just discussed.
When creating an email, offer to be available for a brief call or meeting to discuss or clarify.

Linguistic (learn through language)

Linguistic learners prefer:

Clear & precise written documentation
Exactly the right word to express a concept
Lists

How you can get there:

Provide summary talking points or step by step instructions with visual aids and demonstrations presented in meetings.
Use illustrations with a verbal component such as grids and process flows.
Keep a glossary.
Use unfamiliar terms regularly to reinforce their significance.
Review pictorial documentation to verify all requirements in the image are also put in writing.

Kinesthetic (learning through doing)

User Acceptance Testing is a wonderful time to leverage the kinesthetic learning style.

Kinesthetic learners prefer:

Demonstrations
New skill practice
Content in bite-sized chunks
Frequent breaks and activities that provide opportunities for movement during longer meetings

How you can get there:

Add activities such as role-playing to meetings.
Use a prop that can be moved around (sticky notes, ball, modeling clay, etc.).
Incorporate real-life stories and examples
Try collaborative games.