In my last article I wrote on how different roles within projects and organizations view BAs. An important part of being a Business Analyst is understanding how we are perceived and how we fit in with those around us. As the career and roles of Business Analysts evolve we also need to look at our experience as a BA and reflect. Reflect on where we fit, the next step, and how we prepare for the next role we want. At some point the industry, ourselves, the company we work for, or the role itself evolves. No matter where we are in our evolution as a BA we wear many hats, how does each of these hats contribute and influence project results?  What makes a BA the one that leaders use as the example of value that BAs bring?

The idea of what makes a great BA has changed over time as we grow in our careers. Much of this has been due to how the IT industry has evolved and how business groups have changed in relation to IT.  In this article I attempt to follow the growth of a “typical” BA through various stages of progression in the BA skill set. Realizing that we all have a different path and the skills and experience we gain depends on project complexity and the cultural environments we learn these skills in.

Most BAs whether they come from a systems or business background start out by updating documentation on a system or business process; touching the BA deliverables as part of another role within the organization. It could be updating a process flow, or adding business rules to the business rules document, maybe updating the data matrix or requirements document.  Many start their BA career as the keeper and updater of documentation related to requirements.

As a BA demonstrates the curiosity and natural analysis with the requirements documentation, the questions just start coming and coming, the BA is showing the right skills to be an effective analyst and work through getting questions answered in order to drive out what the solution REALLY needs to do. The BA becomes the coordinator and communicator of questions between the developers and end users.

As a BA becomes more entrenched in the details of a project solution and they have been working with the team throughout the lifecycle of the project they naturally begin to become the go-to person. This evolves into the BA being the go-to person as a solution closes in on implementation and the BA does whatever needs to be done for a smooth implementation.

Now that the BA has seen the implementation through, updated and managed the documentation, and perhaps gone through some formal training they are ready to take on the next project. The BAs know what deliverables are needed at what stage of the project and is comfortable using examples from previous projects.  The BA also has seen users frustrated in the implementation process from not getting what they need out of the solution. Here, the BA have evolved into one who fills out requirements document templates, models, and business requirement documents based on what the user told them and what the user needs.

After learning to document exactly what the user wants and experiencing the downside of this such as: other users disappointed, potential increased project cost, and a solution where the exceptions and complexities reign. We start to learn that the user is communicating how they want the solution to work, but our jobs as BAs is really to extract and translate that into “what” they want and figure out the true business need and drivers behind that “what”.  We learn that doing exactly what and how the user wants the solution to work can backfire and can cost the project inefficiencies, rework, and conflict among users and technology alike. This is when as BAs we begin to learn skills in being a creative facilitator and solver of requirements conflicts among stakeholders. BAs learn that through good working relationships with people with the end goal of going beyond what the user wants; we can balance user needs with efficient process and system design. We learn to gather all opinions and work with technology on multiple options that are efficient in system design and operational business process design; while negotiating and facilitating these options with the stakeholders.

As the BA navigates the fine line of how their approach and work impacts trust with executives, technology groups, and the user community most BAs struggle with what skills to work on. It is the struggle between learning more methodologies and hard requirements skills or driving more towards the relationship building, facilitating, and negotiating skills. The path to take depends on ones own strengths and self-awareness of what focus will lead to the right balance of skills and career happiness. At this point many BAs have worked on many projects, have a great deal of BA experience, and are given team leader responsibilities. The BA has evolved to a facilitator and leader of a team of people trying to do their best getting requirements right the first time, creatively using BA tools, SDLC methodologies, and making analysis activities work for everyone’s unique needs to capture everyone’s requirements correctly.

The evolution outlined above can be put into many contexts of project types and complexity levels. All BAs experience elements of these roles; some more than others in varying contexts. Some of the best BA experience comes from working on projects that impact the entire enterprise and every department in the organization. Imagine working on requirements that impact every corporate department, each business unit, and all customers; requirements that clearly and directly link to enterprise strategy. Depending on your company size and experience, this may be familiar. This is where enterprise analysis comes in, yes that is that section of the BABOK that seems a bit mysterious and hard to define. Working in this space a BA has the opportunity to become a strategic goal champion and leader for an enterprise wide project and/or communication framework provider to enable enterprise business needs to be facilitated through requirements processes in solutions and projects throughout the organization.

Ah, the growth of a “typical” BA. It is quite humorous to say “typical” as we all know too well. How fitting to have it in quotes when each company defines it differently? Sometimes even defined differently within groups at the same company? Looking back now, the role, skills needed, and perceptions on what makes a talented BA is not such a mystery. The open mystery remains: What will the industry and companies of today do with the Business Analyst role? I think that we all as Business Analysts have a collective influence in shaping this direction. Perhaps by taking ownership of our careers and growth as BAs, together we will provide more collective value to our project and organizations; moving Business Analysis further into the forefront of critical contributors?