Skip to main content

Tag: BI

Five Trends in Business Analysis, Project Management, and Agile

Since 2009 we have enjoyed reflecting on what’s happened the previous year

in the world of projects and making predictions for the upcoming year. Here are some of the recent trend topics we have discussed:
  • The digital transformation
  • Roles that help organizations maximize value
  • Agile successes, challenges, and use beyond software 
  • Scaling agile 
  • BAs and PMs in the gig economy
Here are five industry trends that we have chosen for 2020:

BAs Helping Organizations Create Value-Driven AI Initiatives

Many organizations, around 72% according to Harvard Business Review, are finding that their AI initiatives are not meeting expectations,   There are many reasons for disappointing AI results, among them that many organizations:
  • Chase fascinating new technology with no clear vision of the business value (?) proposition
  • Focus on implementing the technology without considering how the organization will get and use the AI results
  • Mistakenly think that implementing AI projects will be easy
  • Seek to implement AI with antiquated and burdensome processes that do not support these initiatives
  • Ignore the immense cultural change needed to adopt AI technologies
Some organizations have turned to a role that is perfect for BAs and that can help organizations implement their AI initiatives. Although this role may or may not be called a BA, the work is definitely business analysis. This work includes:
  • Developing a business case to ensure there is value in undertaking the AI initiative
  • Reviewing the current state and recommending changes needed to existing processes, infrastructure, existing and needed data, and types of new roles and positions needed.
  • Recommending how to get everyone on board, given the enormity and difficulty with implementing this transformation. 


Product Owner Role Even More Challenging for BAs

An emerging trend is a recognition of the challenges faced when the business analyst (BA) plays the dual role of BA and product owner (PO) on Scrum teams. Here are some of those challenges: 
  • The PO role makes product decisions and sets backlog priorities. When there is no PO, a BA is often assigned as a “proxy” or “surrogate” PO. In this role they make decisions on product features and priorities. However, many BAs are finding that their proxy decisions are often overturned by the sponsor or other stakeholders causing rework and delays. 
  • The Product Owner (PO) role is accountable for quick and continuous delivery of value. The BA role is accountable for requirements. That is, for getting high-level user stories down to the details where they can be estimated and developed. This inherent conflict of getting it done quickly vs. getting it done right makes it difficult to play both roles at the same time. 
  • Some organizations understand the need for full-time POs on scrum teams. Because business stakeholders are unavailable, they assign the role to a BA. When the BA is accountable for the product, rather than being a trusted advisor, they end up “owning” the product and are often blamed if wrong decisions have been made.
We’re hearing more and more BAs speak out about these challenges and about the need for both POs and BAs on Agile projects. 

Putting a Little BA in Everyone’s Toolkit

Years ago, we watched project management evolve beyond the skillset expected of an individual with the title Project Manager (PM) into a core competency. It became expected not only of PMs, but of many middle managers even if they weren’t managing projects. 
In today’s product-focused organizations, we are seeing business analysis (BA) evolve in the same way. It seems that everyone is recognizing the value of enhancing their core skills with BA competencies. In today’s change-driven environments, where questions about what customers want and need are always top of mind, BA is used everywhere. So, it’s no surprise that we are increasingly seeing team members seek to augment their primary skillset with BA skills. 
Organizations are recognizing the benefits. They understand, however, that relying on just one or two individuals with the required BA skills is a recipe for gridlock. In addition to the obvious benefit of alleviating bottlenecks, developing fundamental BA skills in all team members also adds depth to their core skills. And we have recently observed workshop and conference participants, even those that do development work, become evangelists for adding a little BA to their toolkit. It does not get lost on them how some BA savvy is going to make them more effective when working with customers, product owners, and other team members. 

Digital Fluency and the Rise of the AI Translator

There are many ways for BAs to help organizations transform to the digital world and take advantage of AI and other digital technologies. Most of these ways require the BA to be a trusted advisor to the organization and help guide it in the right direction. However, to be a trusted advisor, BAs need to know what they’re talking about. They need to understand this complex world themselves. They need to be digitally fluent. 
Many organizations recognize that they need someone with this skillset to be successful. They are becoming aware of the importance of having someone who can translate the technical complexity of the AI world into business language. Someone who can help them articulate the results they want to achieve with their AI initiative. 
That’s why the title of AI Translator is receiving so much buzz. It’s a perfect role for the BA to fulfill, so look for more and more organization to use BAs in this translator role. 

Everyone But the BA Doing DevOps, But That Will Change

We’ve been writing about DevOps for several years, but it seems to us that its acceptance is just beginning to catch on. One of the main reasons that adoption has been slow is because many organizations don’t know what to make of it. They know DevOps supports continuous delivery, but continuous delivery is hard to define. 
Because DevOps means different things to different organizations, its implementation has been haphazard, and frequently does not include BAs. When we ask why, we often hear comments like, “Oh that’s just for Operations.” Or “Sure our organization has implemented DevOps, but it has nothing to do with us BAs.” Organizations understand that having continuous delivery of features does no good if implementing those features upsets the stability of the production environment. Which is what Dev Ops is all about. 
We think that organizations will soon recognize that BAs (and PMs) understand and are well-equipped to implement tools, foster collaborations, and facilitate cultural change, all of which are needed to support continuous delivery. So look for more and more organizations to include BAs in their DevOps adoption. 

By Elizabeth Larson, Andrea Brockmeier, Richard Larson

Andrea Brockmeier, PMP, CSM, PMI-ACP and PBA, is the Director of Project Management at Watermark Learning/PM Academy. She has 20+ years of experience in project management and related practice and training. She writes and teaches courses in project management, business analysis, and influencing skills.
Richard Larson, PMP, CBAP, PMI-PBA, Founder and former President of Watermark Learning, Richard Larson is a successful entrepreneur with over 35 years of experience in business analysis, project management, training, and consulting. He has presented workshops and seminars on BA and PM topics to over 10,000 participants on five different continents. Rich is a frequent speaker at Business Analysis and Project Management national conferences and IIBA® and PMI® chapters around the world. He has contributed to the BA Body of Knowledge version 2.0 and 3.0, was a lead author for the Needs Assessment chapter of the PMI publication Business Analysis for Practitioners: A Practice Guide, and was an author of the PM Body of Knowledge, 4th edition. He and his wife Elizabeth Larson have co-authored five books on business analysis.

Business Analysis & Data Literacy

In a recent article published by Forbes, one of most sought-after skills in the coming year across industries will be Data Literacy.

This comes not as a surprise as organisations, over the last decade have become increasingly aware of the importance of data in business. Data is powerful and with the advent of a number of data analysis and visualisation tools and techniques, the possibilities for an organisation who uses this data is limitless.

A Business analyst, in this midst, can avail of these massive opportunities by becoming data literate. Data literacy begins by understanding the pockets of data available within an organisation, collating that data, converting into insights using data storytelling toolsets and sharing these insights with business during the gap analysis and requirements management lifecycle within a project.

An example in point would be the analysis of a required data point, say, customers’ date of birth, for reporting purposes. An analysis into a source system might highlight that whilst data is being collected, it is not consistent, correct or accurate. This, in turn, would highlight.

  1. Process/training gaps where staff might not be collecting this information,
  2. Policy and procedure gaps where the requirement to collect this critical information is not formalised or
  3. System gaps where the date of birth is simply not a mandatory field.

Thus, an analysis of a single data point and the ability to translate it to business–relevant information will ultimately lead to an increased maturity in a company’s processes, people and technologies.

Whilst traditional business analysis and data analysis have been treated as two different capabilities, the line between the two are becoming increasingly blurred. As organisations focus more and more on data driven projects, both regulatory and digital, the need for a business analyst to remain competitive is to develop skills related to data. Data Literacy consists of three high-level facets:


1. Understanding data and its relation to business outcomes

A BA performing data analysis must always focus on the following data dimensions

  • Accuracy
  • Completeness
  • Currency
  • Consistency

A flaw in any one dimension above might have big repercussions to business outcomes and hence, need to be analysed, documented and communicated as appropriate. A traditional BA has the core skills for analysis and if extended to analysing impacts of data in a business, this can prove valuable to an organisation.

2. Data Visualisation tools and techniques that lets one “interact” with the data

Current popular tools are PowerBI, Tableau etc. A business analyst with the ability to use these tools can derive great insights that will be useful during the analysis phase and beyond.

A point to note here is that the use of tools might be defined as business analytics.
SQL language for backend data analysis is also useful and a skill most BAs already possess.

3. Breaking down data complexities to business understandable language

Data is complex and a business user might not be able to fully grasp the implications of what the data is telling him and what it represents.

A BA is already skilled at managing stakeholder communication and hence can use these existing skills in ensuring that the data complexities are broken down into what a user can understand so that the message is fully understood and actioned.

A business analyst who is already adept at process & requirements analysis can play a big role in enabling change and contributing to business growth in organisations, by acquiring data related knowledge and skills. He/she will be able to convert raw data into meaningful business information, which in turn will allow a business to act upon areas of low ROI, focus on functions that need improvement and use insights provided by data to grow itself.

At the same time, organisations must commit to spending the effort, time and often, dollars in bringing in a shift in focus from traditional analysis to data analysis, upskilling BAs and really investing in enterprise information management for building a more robust data framework.

BA As Detective

Some of you know that I am a big fan of mystery fiction.

There are many aspects of this genre that I enjoy, but what I find the most interesting is watching the detective look for clues to help identify the problem, investigate alternatives, and finally offer the solution. In past articles I’ve noted some of my favorite detectives –Louise Penny’s Armand Gamache, Philip Kerr’s Bernie Gunther, Michael Connelly’s Harry Bosch and Tana French’s various detectives, to name just a few. They are all flawed, but amazingly talented at solving the fundamental problem of “who done it.” What is it that enables them to put seemingly disparate puzzle pieces together to solve the case? Characteristics that are also needed to succeed at doing business analysis work.
In my past articles I have drawn comparisons between the BA and detective. I have explored the need for both to connect the dots and solve problems creatively. I have discussed the need to rely not only on their intuition, but also their rational mind. I have discussed the importance of recognizing patterns, creating structure from chaos, and feeling comfortable with ambiguity. However, one comparison I haven’t explored is perhaps the most obvious and relevant one—the ability to ask good questions. 
As BAs we ask a lot of questions. As Penny’s Chief Inspector Gamache says, “The question that haunted every investigation was ‘why,’” also an important question for all BAs to ask in one form or another. But Gamache knew, as do BAS, that asking ‘why’ by itself is not enough. We need to ask contextual questions. Consider the quote from Dashiell Hammett’s famous detective Sam Spade: “Who shot him,” Spade asks a witness … The witness “scratched the back of his neck and said, someone with a gun.” Experienced BAs know that when we ask vague questions, we’ll get vague answers.
Not only do we need to ask good questions, but we need to be able to understand the answers provided. What happens when we want to ask follow-up questions, but are absolutely “clueless” about what the stakeholder is saying? This can be particularly unnerving when that stakeholder uses highly technical language such as a data scientist describing the algorithms that will be used in the latest AI effort. Like our detectives, we need to clarify. And if we don’t understand, we need to admit so. And if that technical guru asks us questions that make no sense to us (what ETLs need to be developed, for example), we need to admit that we don’t know. One of the tips Chief Inspector Gamache gives each new recruit, is to get clarification when needed. He says that one of the most important things “that leads to wisdom” is saying “I don’t know.” We need to have the courage to say those words modified, of course, for our own situation. 


Of course it gets trickier in the digital world. As BAs we cannot simply say, “I don’t know what you’re talking about,” or words to that effect. We can try the old standby, “Help me understand…” which is great, but we run the risk of still not understanding the explanation. What do we do when we don’t have experience even vaguely related to the stakeholder’s answer? As BAs we often find ourselves asking questions about all manner of things unfamiliar to us, but the world of AI can present new and unforeseen challenges. Yes, we can—and need to– prepare questions in advance. But how can we ask good questions, not just the fundamentals like “why” and “what,” when we know nothing about the subject? 
For example, let’s say I want to ask about algorithms, a subject that I know almost nothing about and therefore am terrified of. Sure, I do research, but when confronted with an answer that makes no sense to me, I might freeze. I want to ask about why one type of algorithm was used instead of another. I want to ask about built-in biases. But answers like “I chose a non-parametric algorithm which uses this method for classification and regression…” might give me pause. What helps me is to go back to the basics and start asking contextual questions, which provide a business context and can set the tone for other questions and answers. Once I establish a business perspective, I can put all my further questions into a business context as well. And importantly, it helps me say “I don’t know” without actually saying it. Remember those ETLS? We can rephrase our answer into a question about what the alternatives are and how each alternative provides the business what they’re looking for. 
We can also start out at a high-level discussion about the AI effort, what business problem it solves, and how it aligns with the organization’s strategic direction. Even if we’ve heard the answers from sponsors and other business stakeholders, we can encourage technical gurus to frame their answers in business terms. Once we have established the business context, we can move to more detailed questions about how a chosen algorithm helps the business, risks of built-in biases, and, as needed, ask about the data, its source, when it was cleansed, and so forth. Or start with a lower level of detail and work upwards. As good detectives, BAs know that solutions rarely occur when we try to investigate in a straight line. Detectives and BAs know that a question that leads to unexpected answers is a source of a myriad additional questions that take us in unexpected directions, but ultimately solve the problem more quickly. 
And that’s where some of the skills discussed in previous articles come in. These competencies. like the ability to connect the dots, help us solve problems and come up with creative solutions. These competencies allow us to follow unusual lines of questions, even if we have no idea what the outcome will be. They allow us to prioritize our work and the questions to ask each stakeholder. They allow us to uncover implicit and hidden requirements. And they enable us to make creative yet practical recommendations. In other words, they help us find “clues” that may seem meaningless at first, but which ultimately help us solve even the most difficult business problems. 

Is AI a Solution, a Technology, or a System…and Why Should I Care?

A recent article in Harvard Business Review (HBR) asks if AI is a system or is it a solution like so many organizations think?

An interesting question, but one that I would rephrase: Is AI a solution, is it technology that supports the solution, or is it part of a larger system? I have always thought of AI as supporting the digital transformation, which includes all the organizational changes that are needed to make use of digital technologies. So I have always thought of AI more broadly than either a solution or technology. The HBR article points out that 1) 80% of organizations surveyed are developing some sort of AI applications and that 2) companies that think of AI as a system rather than a solution will see their revenues grow by as much as a third over the next 5 years[i].

To understand why this might be the case, let’s consider a few possibilities:

If we think of AI as a solution, we need to be pretty clear about what problem it solves, or business need it addresses. For example, let’s say we need to be able to predict which customers will buy our new product. Sure, this sounds like a business need, but it really is a solution. Ah, you might be thinking., predict customer patterns = predictive analysis, so the solution I need is predictive analysis. No, predictive analysis is a way we can predict who will buy our product. It supports the solution. But what is the business problem? It might have to do with loss of market share, decreased revenues, or a number of other real problems.

So instead of:

  • Problem: We need AI to remain competitive
  • Solution: AI

We can think of it as:

  • Problem: Market share has decreased by x% since this time last year with resulting revenues down by $x
  • Solution: Ability to predict which customers will buy our new products to increase our customer base and to increase revenues.
  • Technology needed to support the solution: Software to analyze the data for customer buying patterns and predict customers who will buy our product

But will technology by itself solve our problem? Probably not. What about the related end-to-end processes that will need to change, the massive amounts of data needed to be analyzed and which predictions need to be made, which algorithms to use, the effect of AI on the organizational culture, the jobs that will be created and lost, the business decisions that will need to be made, the business rules to consider and much, much more..


When we think of AI as the technology part of a system, a system in its broadest sense, this starts to make sense. We know that we need to understand not only the technology, but all the context and processes surrounding the technology. When we analyze whole systems, we consider such things as:

  • Problem: In this case, loss of market share to competitors
  • Solution: Ability to predict which customers will buy our new product
  • Technology needed to support the solution: Software to analyze the data for customer buying patterns and predict customers who will buy our product
  • Processes: current processes and how they will change with the implementation of the solution
  • New roles and positions to create and hire for

We also know how to make organizations aware of such consequences as:

  • Wrong staff doing the work, such as creating the models
  • Dirty data leading to shabby analysis and incorrect predictions
  • Minimal acceptance by key stakeholders
  • Wrong people making business rules and other business decisions
  • Biases built into the predictive models

That’s one of the reasons why, I believe, taking a systems approach increases the chances for organizations to see growing revenues. Thinking of the entire system, not just the technology, allows for the distasteful but essential hard work of figuring this whole thing out. If we look at only the technology, we’re apt to fall into the myriad pitfalls that so many organizations fall into, and which lower the chances of successful outcomes.

How BAs can help

  • Understand the problem. We can help explain the difference between a problem and a solution in search of a problem and that a solution in search of a problem does not necessarily help an organization achieve its goals.
  • Ensure data is trustworthy. AI depends on trust-worthy data, data that is clean, that not only has a single source of record, but that comes from an agreed-upon source. That the data business rules are aligned with the organization’s goals and objectives.
  • Examine algorithms and the underlying data to see if there are built-in biases. BAs these days need to get up-to-speed on AI in its various forms (machine learning, predictive analysis, RPA, etc.). They need to educate themselves on the various algorithms that are used and the advantages and disadvantages of using one over the other from a business perspective. We need to ask really good questions to ensure the right algorithm is being used for the business need at hand. We need to ensure that the kinds of predictions and AI recommendations will not harm the organization’s ability to serve a variety of constituents. We need to look for underlying biases.
  • Help evaluate predictive tools to weed out any that intentionally or unintentionally promote biases. As BAs we can help the organization examine various measures of success and explain how subjective measures might insidiously shape a tool’s predictions over time. We can look at end-to-end processes and the input to and output from these processes to examine the data for underlying biases. And once we understand the organization’s “system,” we can work with software vendors to help ensure that the software itself is aligned with the organization’s goals and doesn’t have hidden built-in biases.

If, on the other hand, our scope is simply implementing the AI application, much of the needed business analysis could well be short-circuited, resulting in this sorry statistic—72% of executives said their company’s digital efforts are missing revenue expectations.[ii].

Organizations may want us to help them implement AI quickly, but they need us to help them avoid the consequences of falling into the common pitfalls, as so many organizations have done. In other words, we can do our part to help achieve the revenue growth projections when viewing AI as a system

[i] Taking a systems approach to adopting AI by Bhaskar Ghosh, Paul R. Daugherty, H James Wilson, Adam Burden

[ii] Gartner, 11/27/2018 HBR, Every Organizational Function Needs To Work On Digital Transformation

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

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,

[ii] Ibid.

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