Future Predictions for Business Analysis!
Angela Wick
| 2 Million+ Trained | Helping BAs Navigate AI | BA-Cube.com Founder & Host | LinkedIn Learning Instructor
As a member of the LinkedIn Tech & Innovation LinkedIn Creator Accelerator Program , LinkedIn has asked me to predict what the future brings to Business Analysis in the midst of all of the dramatic technology and innovation changes we are experiencing. #LICreatorAccelerator
What do emerging technologies and innovations mean to Business Analysis?
This is the question I want to get a rich dialog going on, and I hope you will chime in with your comments (agreement or not), share with your network, and together, let's get ready for the future!
#BusinessAnalysis is a skill and mindset about solving problems, making decisions, and facilitating value for customers and users that also drive business value. It needs to be infused into everything organizations do, it's not an isolated function, group, or department.
For many years this function has been fulfilled by creating requirements and specification documents as the output of this overall goal to facilitate change in the midst of change; often business process and systems changes. This outdated way of working needs to change if it hasn't already in your organization, and we need to become much leaner to help organizations get better results with the emerging technologies and innovations we are experiencing.
The pace of change is not slowing down and neither is the change in how we do business analysis!
Here are my predictions for how Tech & Innovation will impact Business Analysis going forward:
Prediction #1: Business Analysis will become more widely known and talked about as a?skill everyone needs, no matter the role or title.???
Business Analysis has a long history of being misunderstood, or mischaracterized as "spec writers", "requirements analysts", "system analysts", or even misunderstood to be "financial analysts".??
In the near future, Business Analysis as a term will gain significant recognition as a "skill set" that everyone, every business and technology professional, needs and more specifically defined as the skillset to:
Prediction #2: BRDs (business requirements documents) and Specs (specification documents) for software and product development will become?obsolete.
Today's and tomorrow's emerging technologies are not suited for the traditional "requirements phase" and "documenting specifications" to be handed off to a development team.??Teams will need to adapt to work efficiently and fast to compete and to ensure that their plans remain valid as they work. The technology will change faster than any spec can be written. Business analysis will become less about documenting and more about collaborating in real time as the team builds. Teams will need to establish new norms and practices to do analysis collaboratively as they work, and business analysis professionals will need to lead the way in showing teams how to analyze the big picture and details as the team works.
Web3, blockchain, NFTs, modern artificial intelligence, modern data analytics, decoupled architectures, and low-no code environments will drive the investments, project, and product portfolios going forward.
These technologies require cross-functional teams with a focus on outcomes and experimentation over requirements documentation to succeed.?These teams will need a constant focus on defining and prioritizing short experiments and validating hypotheses to implement and work as fast as the technology is evolving, or be left behind.??
Business Analysis moves from BRDs/Specs to:
A few exceptions to requirements and spec documents becoming obsolete may include things like creating detailed system documentation after it is built and tested, or along the way as the team builds and validates it is working. Teams will break the normal "we must document" mentality and start to challenge why? and for whom? we are documenting. Organizations will seriously question the value of detailed spec documents!
Some specific technologies or industry-specific systems may use detailed spec documentation, but the majority of teams will be pressured to speed up the delivery process by working differently without time for a "requirements analysis & documentation" phase.
Prediction #3: The word "requirement" will become?obsolete (sort of), not "Business Analysis"!
Leaders want outcomes/results fast, not projects done fast! Project failure rates continue to be a challenge and we will be forced to rethink what a "project" is and how we determine the team, the goals, and alignment to ensure that "project completion" equals outcomes and results! Even moving towards a "product" approach won't matter enough unless the team has an extreme focus on outcome alignment. Business Analysis skills are a HUGE part of making this happen, but "requirements" are not!
领英推荐
The traditional sense of "requirement" is that it defines what is "required" to be built in a product or system to meet the business and user needs.??
Business and user needs will always be part of business analysis work, and some call these "requirements". But, the more detailed "requirements" that are the center of many software and project teams' that describe the solution/product/system outputs to be built will transform dramatically!
Today and tomorrow's technology and innovation landscape are changing and evolving faster and faster with no sign of stopping the exponential rate of change. We can no longer determine what the "solution requirements" are ahead of time.?What WE CAN DO, is understand our customer's & user needs at a new level of understanding, with context, clarity, and experiment constantly with new technologies to bridge the needs and challenges with the new technologies.?We do this with a nimble business analysis approach based on hypotheses and experiments aligned to strategy and outcomes.
As technologies evolve into low-no code and artificial intelligent automation, business analysis practices will need to be on the leading edge of fine-tuning how this dynamically changing code automation impacts the user experience through monitoring the user experience, determining improvements needed, and working with technical teams to fine-tune the processes.
The extraction of value from data is also something business analysis skills will be at the forefront of. Extracting value is not "gathering requirements" but understanding what value means to users and business leaders and proactively working to extract it. Helping teams understand the quality of input data, extracting what data is valuable, and how predictive and prescriptive data analytics can solve organizational challenges and automation opportunities.
"Requirements" in the past are actually just assumptions and hypotheses about what someone thinks will add value and solve a problem.?
They are not validated until we actually see users using a solution or product AND getting the intended value.?
We need to shorten the cycle from idea to validation, and "requirements" need to change to become more refined to what they really are: User Needs, Business Problems To Solve, Opportunities, Hypotheses, and Experiments.
Think about changing your "Requirement Lifecycle" to a "Hypothesis Lifecycle".
Hypothesis Lifecycle:
Hypothesis Definition - Align - Prioritize - Experiment - Learn - Adapt - Implement - Repeat
This cycle will be much more dynamic and in much shorter cycles than today and integrate the business, product, project, and technical teams more than ever, creating a bigger need for business analysis skills to define, communicate, prioritize and align teams to strategy, outcomes, and user value; while actually doing analysis in real-time as the team builds.
This use of hypotheses will help business leaders and teams create more crisp and focused priorities to align with their strategic direction.
Business Analysis will not be a "do requirements and my work is done", and it never should have been!?Even more important will be the constant "monitoring" of the intersection of user experience,?monitoring the value users get, user challenges, and experiments with new technology & data; using all of this to dynamically manage a prioritized backlog of hypotheses, experiments, and small frequent releases. Navigating uncertainty rather than documenting "certain requirements" will be the business analysis focus.
What's Next?
Some organizations are already doing these things, but the majority are not there yet.?There will be increasing pressure to adopt these newer more nimble approaches and practices as those already there will deliver value faster, setting the stage for how to keep pace with the technology and innovation evolutions.
What are your predictions??What would you add to this? What needs more conversation to flesh out or challenge?
Comment, Share, and let's get ready for the future of Business Analysis!
Your turn, are my predictions:
------------------------------------------------------------------------
Follow me on LinkedIn for more Business Analysis content.
Subscribe to my Newsletter here.
Come to my next LinkedIn {AUDIO} Chat (Thurs Nov 10th, 2022) about Leadership Skills in Business Analysis: https://www.dhirubhai.net/events/audio-buildingleadership-influe6992870042149261312/about/
BA Lead Special Projects / Sr Business-/Process Analyst
2 年For me most definitely Spot On - Very valuable. Business- and User needs will always be core components and your statement that of "more detailed "requirements" that are the center of many software and project teams' that describe the solution/product/system outputs to be built will transform dramatically!" Being part currently of a Transformation Programme at Large Retailer, we never made use of detailed requirements, due to the purchasing of a "Packaged Solution". The need for detailed requirements was actually not required. We are daily experiencing the importance of the needs of the customer, but most importantly the users of the packaged solution and how critical it actually is to understand the detail, their needs, but also how these needs are impacted by the packaged solution, working closely with change management. Ensuring that Process, Solution and People, post Go-Live will still function efficiently and most importantly in Synergy, that does bring about Effectiveness, brought along its own challenges. I wish I can have a 30 min discussion with you on this topic because it is all about Customer Needs, User Needs and the Value that is to be achieved.
I.T. Business Analyst at Children's Hospital Boston
2 年Great article - really got me thinking about a couple things! Here's one: I’ve been wondering how to bridge the gap between now (pseudo Agile) and working with new technologies. Machine learning, low- to no-code environments and AI are the bright light at the end of the tunnel – a train coming that we can jump onto or will run us over. The “Hypothesis Lifecycle” is a perfect segue. If we can begin to look at current work that way, we will be ready to jump on the new technology and take advantage. Even though they appear aimed right at users, these new tools will almost certainly require the BA mindset to translate.
Business Analyst at Boots UK
2 年Interesting article but I am concerned about point 1 - everyone has BA skills. It seems to imply that anyone can be a BA and little or no training is required. As far as I'm concerned this couldn't be further from the truth. Being a great BA takes training, experience and hard work. Not everyone can do it (or should! ??). We should value the good ones and encourage them.....just my opinion.
IT Systems Analyst and Certified Scrum Master
2 年My organization, Minnesota IT, is embarking on an agile mindset. Teams are struggling with how much or how little documentation needs to be captured. They get that they aren't writing volumes of documentation any longer, but they also realize that they need to provide regulators with documentation on how a system meets regulatory requirements. How do you balance these issues with an agile mindset?