For the Business Analyst, Why Relationships Trump All!
In projects, the roll of the business analyst is an important one. The business analysts not only understands the organization's structure, policies, and procedures, he or she helps define project requirements from the various stakeholder groups involved in the project. The best way for the business analyst to gather and organize requirements is by establishing strong relationships and channels of communications between him or herself and the stakeholders.
What Are We as Business Analysts?
Based on the Business Analysis Body of Knowledge (BABOKŪ) , we are the liaison among stakeholders, who understand an organization's structure, policies, and procedures. What do we do with this understanding? We use it to help an organization define its needs and to recommend solutions that enable the organization to achieve its business goals.
Whenever I read this description, I am somewhat overwhelmed with the amount of knowledge and the level of skill we need to possess as business analysts in order to fulfill the expectations put on us. Just think about the diversity of the stakeholders who are affected by their organization's structure, policies, and procedures. That's a large and complex audience. Not to mention our objectives of helping them to define their needs (requirements) and recommending solutions (products) that they can all agree with. If there is one thing I have gained over the years that has helped me the most in defining and delivering solutions, it is the knowledge that "relationships trump all."
Business Analysts and Their Relationships
Remember, as business analysts, our first objective is to help define needs (requirements). Defining needs is really about defining change. The need for change can come from several different levels and involve several different roles within an organization.
For a business analyst to be effective when defining needs, it's necessary to understand the various roles (see Figure 1) that we interact with as business analysts. We also need to understand the roles' perspectives on defining change in terms of requirements. Change may include organizational change, strategic planning and policy development, process reengineering or improvement, and IT systems development and implementation.
All change has one thing in common, and that is requirements. Those requirements define the change and come from the roles in Figure 1. If we take the time to understand the different roles and build our relationships around them, we will be able to do a better job eliciting the requirements.
Each of the roles illustrated depicts a specific group of stakeholders. Each will have expectations of the results of change based on their unique perspectives. The following descriptions will help you understand their perspective.
There are two types of management.Executive - These are the strategic leaders of the organization. They are concerned about what their customers' needs and desires are. Since those needs and desires can change rapidly and with little notice, executives need to be agile in order to make relatively quick, course corrections. They set strategic goals and have the authority to make enterprise-wide decisions.
Functional - These are the tactical leaders of the organization. They are concerned about the resources needed to build the product(s) that satisfy the customers' needs and desires. Just when they think they have the right people.in the right place.doing the right thing.the course changes. They set tactical goals that, when achieved, will move the organization toward its strategic goals and have the authority to make decisions within specified boundaries.
Business Process -
Operational Staff - These are the people who report directly to functional management. They are the ones who use the product(s) on a daily basis to accomplish their job. They're concerned about having the right tools, and whatever tool they are using can always be better.
Information Technology -
There are two types of information technology:Software - Application developers design and build the product(s) that will be used by operational staff.Both of the information technology roles are concerned about the quality of the product(s) being built. Information technologists tend to be perfectionists, so, no matter how you define done.the end product(s) will never be quite good enough for them.
Hardware - Infrastructure developers design and build the product(s) that will support the application developers and operational staff.
As you can see, the stakeholders in each role have different perspectives. They also bring to the table a unique knowledge base, expertise, background, and experience. As business analysts, we need be prepared to acknowledge that not everyone is the same and be determined to know our audience. You must be prepared to have conversations on multiple levels, from the strategic perspective to the tactical one. This includes business and technology.
For example, not long ago I was working on a large, complex project. It was a business process reengineering effort that, in the end, required us to replace the client's entire infrastructure, including their core and support applications. I used the descriptions above to help guide me while building the relationships that helped me during meetings where I was a participant and meetings where I was the facilitator.