The Top 10 Trends in Business Analysis for 2016


Communication Skills Will Drive Client Collaboration and Greater Business Value

Business analysts are experiencing a paradigm shift of their role away from one that has been characterized as a tactical, check-the-box process. Meanwhile, organizations are recognizing the need to utilize business analysis not only to elicit specific requirements, but also to help align and drive organizational strategy.

Forward-thinking organizations that empower their PMOs, business analyst teams and other project talent to think and act strategically are benefiting from their on-the-ground perspective to identify where projects are out of alignment with the organization’s strategy. In this strategic shift, practitioners of the business analysis discipline have ever-increasing opportunities to deliver business value to their organizations and in doing so, advance the profession. Their comprehensive perspective of the whole business can identify how the organization meets customer needs, and what the organization can do to better meet those needs.

The Top 10 Trends in Business Analysis for 2016 examines the evolving ways in which BA practitioners can help organizations realize better business value and the shifts needed within the BA discipline to achieve it. The 2016 trends highlight BAs evolution from “order taker and liaison” between stakeholders to an increased focus on being an “agent of change”, and communicating and collaborating about much more than requirements.

Here are the Top 10 Trends in Business Analysis for 2016 as compiled by a global panel of Strategy Execution senior executives and subject matter experts. 

1. The shifting role of BA toward communicating, instead of documenting.

Those practicing the discipline will embrace the approach that being a strong business analyst requires more than just writing down requirements. It means establishing trust with stakeholders, and persuading them to embark on a journey of discovery together. BA practitioners will be able to impress stakeholders and demonstrate their worth by asking the tough questions that address the impacts a new solution or IT project will have on the organization and its customers. The shift away from cumbersome documentation owes a great deal to Agile, with its light-weight, just-in-time documentation which can have a very short life span.

2. Goodbye to the business requirements document.

There will be a shift from the low-value work of writing and updating text-based documents to visual modeling, online repositories and real-time collaboration tools. Driven by the demands of geographically-dispersed virtual teams, companies will need to invest in changing the way people work together. They will need to invest in modeling tools, each of which has a framework for asking the right questions. While used for eliciting and managing requirements, one of the great values of modeling is that business analysts will spend less time filling out templates and much more time collaborating with stakeholders to get requirements right. The models themselves will be the communication vehicle, reinforcing the old adage that a picture’s worth 1,000 words. Added bonus: the time saved updating requirements documents will offset the cost of the tools.

3. Wider adoption of a professional BA approach to increase organizations’ agility.

As business analysts use tools like use-case diagrams, work-flow models, decision tables and other models that enhance analysis and communication, they will be better able to collaborate with stakeholders and gain their trust in the models. Expect a-ha moments from stakeholders as visual models and text enable them to see aspects of a solution of which they were completely unaware. This buy-in of models will feed into the business architecture for the whole enterprise to collectively deal with complexity and change in the future.

4. Building better business cases that set up projects for success and avoid ones doomed to fail.

The discipline of business analysis will help keep companies from getting into trouble due to their tendency to build business cases that are biased, inaccurate and superficial. Better business cases will tell executives the whole story, will be honest and well-socialized and enable executives to know when not to approve a too-risky or flawed business case. Smart organizations will realize that avoiding one bad project can cover their business analysis budget for the year.

5. More focus on business value, less on project activities.

This year, delivering and optimizing business value should take its rightful priority over the traditional project goals of delivering on-time and within-budget. Traditional time/budget constraints can actually be counterproductive because they don’t focus on business value. Think of drilling an oil well completed on time and on budget, but it doesn’t strike oil. Projects will need to provide better solutions that deliver benefits for years to come.


6. It’s not just about software, it’s about the WHOLE solution.

Changing organizational needs will demand much more focus on the business context, not just information technology. The interfaces, interdependencies and interactions that happen between the people, processes, business rules and other enablers will add to the challenge and “wholeness” of delivering solutions. This is a dramatic shift from traditional thinking of business analysis within the context of a project. In fact, we’re hearing from a sizable percentage of business analysts that they don’t work on projects. They work on supporting existing systems that are in place, fielding hundreds of change requests a year.

7. Business analysis will help deliver better results from IT investments.

Organizations will apply the discipline of business analysis before investing in enterprise-wide solutions like COTS products to ensure the right fit, and show businesses the greater value in changing their processes first rather than customizing software. This trend is driven by industry executives who have halted the prevalent industry tendency to customize COTS software rather than configure it. The light-bulb has finally gone on after the expense and headaches that resulted from customized software that inevitably needed to be upgraded with new version releases. Not only will business analysis determine the right software for the organization by eliciting requirements, it should also ensure the organization’s process is aligned with industry best practices to maximize results. COTS software is industry best practice, and the focus needs to be less on customizing a best practice for old ways, and on embracing a best practice for the organization’s new way. 

8. More business analysis, fewer business analysts drive career opportunities.

The techniques and tools of BA will be applied more, but there will be fewer with the job title of business analyst. This will be a benefit since the business analyst is often thought of as lower down on the food chain. We’ll see more titles such as process analyst, knowledge engineer, project director, client service director and client relationship manager which will actually create greater career opportunities by avoiding the title of business analyst. The opportunity will be generated when those practicing business analysis learn to communicate the value of their skill set and mindset to other titled positions in the organization. These BA positions will be conducting business analysis to determine benefits, better define scope and identify alternative solutions.

9. Yet many will continue to expect the “same old, same old” from business analysis.

Other parts of the organization, as well as other professions and disciplines will remain unaware of the evolution of the business analysis discipline and as a result will hold it back from its greater strategic potential. Project managers, developers, testers and other participants with expectations for extensive text-based documentation rather than communication will be missing the boat by doing things the same old way. What they could be seeing is business analysis pushing into the strategy of the business, understanding where the business is going and driving business process change.

10. Don’t expect to get all the requirements up front.

With about 45 percent of all approved requirements never actually being used, business analysts will use communication tools and techniques to allow requirements to emerge and evolve over time. Agile methods, design thinking, which puts the end-user experience at the forefront of solution development, and other BA practices will enable the process.

Today’s business climate requires project driven change to be executed with more discipline and agility than ever before. The Top 10 Trends emphasize the ability of business analysis to help organizations select the right solution instead of the first solution suggested to deliver business value. The business analyst’s skilled interaction with stakeholders throughout the organization will facilitate the critical need to bridge the gap between strategy and execution.

Author: Joseph R. Czarnecki, PMP, MSP, SCPM,  TwentyEighty Strategy Execution


Joseph R. Czarnecki, PMP, MSP, SCPM, is Vice President Product & Sales Support, TwentyEighty Strategy Execution. Joe's in-depth knowledge allows him to align client needs with course offerings, guide the contextualization of courses to client's cultures and processes, and bring insights from clients to the development of new courses. Joe has more than 25 years of experience in instructional design with a focus on portfolio and program management for financial services, aeronautics, manufacturing, energy, and technology companies. Visit

Like this article:
  75 members liked this article


KJ posted on Tuesday, January 5, 2016 3:22 AM
Good Points!

As a retire veteran, points 2 and 10 cut deep! I'm going to miss my documentation in Courier 10 font!
iglesias posted on Monday, January 11, 2016 9:32 AM
Perfect points!
the only issue that I have is with the point 2:
As the actual methodology an analyst are not perfect, as the parts are often different (the client, even the analysts are often from different entities/suppliers) as the targets and approaches are different, unfortunatelly I still see as a MUST to have at least as short points the requirements named. It can be then linked to visual models, to whatever, but still as a consistent "order" or contractbetween client/supplier (or all entities, I didn't founded any better tool that a final "excel" with the needed requirements to be inplemented, by the project, or the release, or the month, or the team, or before another set, or ... How many attempts to "leave the BRS/SRS or the reqs lists with "agile" "Zachman" (incredible but 1 client made it :-) and other tools and methods", but at the end there was no "master records" about what really is required, from the process models /functional models / uses cases / UML / Archimate diagrams there was so many ambiguity and misunderstandings about what really is necessary to develop or test ...
I don't say that this point is not OK, I am saying that still the BRS is necessary until a real document that will be understable to all parts with different level of knowledge and aims will be able to agree ... and it doesn; matter which country, industry, company, local/global org etc... is modelated... always the same problem.
Of course, "pure" agile environment, don't needs it, but, still, more than 50% of the clients, projects, etc ... are not sincerelly "agile", where discussion and communication is iterative and trust is an integral principle.
ethacke1 posted on Monday, January 18, 2016 6:59 AM
Twenty years ago I changed my profession with the intent to pursue the path to add value to the development, implementation and ongoing value-adds associated with the IT investments made by businesses to support ongoing operations and positioning for future organizational success. I have often felt during the last two decades that the actual deployment of Business Analysts does not reflect this perspective.
When you consider the term 'Business Analyst' within the realm of IT projects, it implies the approach of analyzing the business operations to arrive at an activity that could be used to enhance the alignment of Information Technology and Business Unit resources to support and advance the value-adding outcomes expected from IT projects. I applaud the concepts introduced in this article - they encapsulate many of the objectives that I share as a practicing Business Analyst.
The organization that I currently work for doesn't even have a job title of Business Analyst - their understanding of the job is titled: 'Business System Analyst'. Having spent 11 of the past 20 years working directly in the IT function to gain the understanding of IT so that communications between operational business units and IT development groups are effective, I sincerely believe that knowledge of the IT domain is critical to my success. But I'd like to see the focus of the profession shift to reflect the fact that, in the same manner Financial Analysts are focused on organizational or portfolio financial information, Business Analysis should be focused on analyzing Business needs and solutions, NOT on supporting autonomous IT preferences. IT should not be in a position of a tail wagging a dog and Business Analysts can help the business operations take back control of their investments, supporting expected ROIs.
One misconception that is often presented as 'fact' is the idea that requirements are a project artifact and are set in stone before the design phase of an IT project. In fact, requirements for an IT application are an Application Lifecycle asset. These requirements, when captured and managed properly will reduce costs across the execution of initial application development and the multiple associated enhancements during the application's lifecycle. There is a good reason why Requirements management falls at a lower maturity level within the Carnegie SEI than requirements analysis - the management of these organizational assets is, in my experience, critical. I am heartened by the idea expressed above that requirements are constantly evolving - we simply do not live in a static world.
mvigeant posted on Friday, April 15, 2016 3:14 PM
This article made some strong points and I agreed with much of it, and I'm encouraged with the direction our role is heading. However, I strongly disagree with point #8. It has taken the industry over 20 years to establish, define, and accept the Business Analyst job title. I don't see the benefit of calling it anything other than what it is. In fact, I see that trend taking us back to the frustrating days when I couldn't find a job because everyone called us something else. I was thrilled 12 years ago to learn that what I had been doing for 10 years as a Systems Engineer, Product Specialist, and Business Consultant actually had an accepted common title. And armed with that I could now job search on a key title that meant something specific to more than just a handful of companies. I also don't agree that BAs are "...thought of as lower down on the food chain." The 175 BAs and BSAs in my Fortune 100 company are very well respected. And if it is true that they are generally lowly considered elsewhere, I don't think the solution is to change the title in the hopes of elevating people's perception, but rather prove our value and change people's paradigm of the title. As a business analyst, I think it would behoove industry to do as we do best and further analyze the actual problem before we jump to a solution. I suspect the problem isn't that we have a 'bottom feeder' reputation and that we need a name change, but more likely people don't understand what the title means, what we do, and what benefit we bring to the business. You're suggestion that BAs be referred to by other titles begs the question, do you think that PMs should change what they are called?
Only registered users may post comments.



Copyright 2006-2024 by Modern Analyst Media LLC