The BA Role: Has it really changed in the last 15 years?

As I tweet my latest BA adventures, I ask Siri to find the best restaurants near my hotel, Skype with friends in Mexico, and order my favorite bottles of Napa Valley wine on Amazon, I can’t help but be amazed by how much technology has saturated my life in the last 15 years.

Internet, email, mobile devices, “the cloud” and social media have transformed the personal and professional lives of a huge portion of our world’s population in such a short amount of time.

Visionaries like Bill Gates, Steve Jobs, Jeff Bezos, etc. get most of the media credit for the technology explosion, but instead of focusing on their undoubtedly awesome leadership, I often find myself thinking about project teams. I think about the thousands of programmers, project managers, architects, testers, and of course business analysts—that move the vision to reality.

Given this technology explosion, one would expect that the tools, processes and procedures used to deliver technology have evolved dramatically in the past 15 years as well.

What do you think? Has project life changed in the last 15 years? A lot, a little or not at all? When focusing on the BA role, have the primary functions of the BA evolved? Have BA tools and techniques changed? Have the deliverables changed?

Have the mindset and behaviors changed?

Here are a few thoughts about how project life has changed and how those changes impact the BA role:

Higher Stakes

Whether a project delivers solutions to internal or external customers, the stakes are higher in 2014 than they were in the 1990s. In the past, system and process errors often had manual back-up procedures. The people around then still remembered what the business rules and logic are.

Now, we are so dependent on technology, that, in many cases, business shuts down when the system does not work— orders don’t process, inventory does not move, money doesn’t flow, customers/employees jump ship.

These high stakes impact the BA role in the following ways:

• Accurate requirements become even more important than in the past as customers and operations are impacted more when requirements are missed.
• Contingency plans for key functions become critical to protect employee/customer relationships.
• BAs become risk managers and need to effectively communicate risks, dependencies, and constraints so that projects do not move forward with bugs, gaps or inefficiencies that will compromise the value of the solution being implemented.
• The partnership between BAs and QA (test teams) needs to be stronger. BAs need to help QA prioritize test cases and provide context and expected results for key test cases.
• The partnership between PM and BA needs to be stronger than ever, both managing key aspects of value, risk, and complexity impacting how both roles work with stakeholders and manage scope and priorities.
• A competitive environment in most industries that changes quicker than most project can keep up. This means high stakes if teams cannot flex to the changes, BAs need to be able to adapt and work with changing requirements to ensure the most value is delivered.

Increased Complexity

Fifteen years ago, most BAs were probably working on in-house software/process projects that involved 2-3 systems and a multitude of manual paper procedures, supporting a single business unit or product. The entire project team probably shared space on one floor (or even one large room) and many of the stakeholders were just a few floors away. BAs often grew to understand systems and processes so well, they did not need extensive assistance from subject matter experts.

Business and project complexity grows as companies expand and merge, and it’s happening more often and faster than before. In many cases, dozens of systems interact, integrations and interfaces are critical and complex, users expect more form systems, and BAs gather information from people across the country and even across the globe.

Increased complexity pushes BAs to:

• Strengthen their elicitation techniques to account for the immense amount of information complexity, and cross-functional connections; amounts no single person can possibly keep up with as their own knowledge base.
• Transform elicitation skills and techniques to discover requirements that are unknown when the project starts. Helping the team discover requirements they did not know they had, but add immense value to the changing landscape.
• Strengthen analysis techniques to make the critical connections between functions, processes, rules, data and user experience end to end.
• Increase the use of collaboration techniques. In the past, solutions may have been more obvious. Now defining solutions for complex systems requires meaningful collaboration from a diverse group of stakeholders who are rarely in the same city.
• Strengthen their facilitation techniques to help stakeholders focus, prioritize, and discover requirements as we learn together.

More vendor package software

Packaged software purchases from third-party vendors also add complexity to projects. Organizations assume packaged software solutions offer reduced costs and efficient implementation and are surprised when project delivery is not seamless.

As organizations expand their use of packaged software, BAs must:

• Define vendor roles and responsibilities, especially understanding the role the vendor BA and client BA. The vendor BA’s role is to be a functional expert of the vendor application, functions and options. The client BA needs to be the voice of what the user and process goals and business rules are to meet the solution objectives.
• Quickly build strong and trusting relationships with vendors, yet keeping vendors accountable for bringing options and alternatives to realize requirements.
• Understand and evaluate vendor requirements strategies, and options to meet requirements. Escalate any related issues that would impact solution value.
• Quickly map current systems/processes to packaged software process/functions. Understand and communicate gaps and changes to stakeholders. Prototype, pilot and test quickly to understand requirements and designs fully.
• Understand when to leverage vendor knowledge and when to leverage business knowledge to ensure value from the package.

Less time to do requirements

Time and cost have always been focus of solution delivery. Organizations apply strong pressure on their project teams to deliver solutions faster. Our stakeholders have less time too, which means we need to alter our practices to work more efficiently.

In recent years, this pressure has resulted in tighter timelines for business analysis and requirements. With increased complexity and shorter timelines in 2014, BAs need to:

• Reevaluate BA practices and techniques to maximize efficiency.
• Reevaluate how we use meeting time, collaborate more, and in smaller groups to get work done.
• Reevaluate how we document requirements; watch our level of detail for each audience; document in pieces and context rather than big requirements documents.
• More alignment to other projects needed to integrate value across solutions.
• Understand and communicate solution priorities and risks; base the requirements and testing plans accordingly.
• Ask for more time if needed with a solid plan in place to provide value to the stakeholders, and identified risks in business terms if time is not allocated.

Agile Approach

In the 1990s, most BAs worked in a traditional waterfall environment where templates were the norm and the software development life cycle was clearly defined with a regimented organization-wide or application release schedule.

Many organizations continue to operate in this fashion, but more organizations are trending to using an Agile or hybrid approach to deliver solutions.

The role of the BA in projects using an Agile or hybrid approach can be a bit ambiguous, but in general this Agile or hybrid approach compliments a movement toward more collaboration and flexibility in solution delivery, and less focus on SDLC process.

BAs working on projects using an Agile or hybrid approach need to:

• Utilize techniques that inspire collaboration and meaningful dialogue to generate effective and innovative solutions.
• Understand their role and how it adds value to the solution delivery.
• Understand timing and deliverables may change, but mindset and what we do as a BA does not.
• Advocate for the value they add to the project.
• Let go of role definition based on governance processes and focus on the essence, value, and goal of what you do as a BA.

How has your BA role changed over the years? Are you still generating 100+ page BRDs?

Don’t forget to leave your comments below.