How to Target Your Communication to the Stakeholders in Your Business Analysis Project
A business analysis message is only as good as how it’s received. Take the time now to get familiar with the ins and outs of different stakeholders; it pays off in dividends down the line.
How to work with executive sponsors as a business analyst
On a project, the executive sponsor is the your most important stakeholder. He controls the funding for the project, has expectations about what the project will deliver, and will decide if the project is successful or not. Following are some good questions to think about asking the sponsor to find out what the sponsor needs or expects from the project and the project outcome. Knowing the answers to these questions definitely contributes to project success:
Does the executive sponsor have a clear vision of the desired state?
Does he or she understand what it will take to get there?
Is he or she expecting measurable results? And if so, what are the metrics?
Will he or she encourage people to express concerns?
Has he or she considered aligning rewards to support the change?
Has he or she defined success as a business outcome as opposed to a systems implementation?
What is he or she expecting after the project is complete?
How often does he or she plan to interact with the project team?
You may not work directly with your sponsor. If that is the case, you’ll work closely with other management and need to gain this information from them.
How to deal with domain subject matter experts in business analysis
The first thing to understand about domain subject matter experts (SMEs) is that they’re there to do the business of the business. If they sometimes seem to give you short answers or want to just get to the solution quickly, it’s because they want to get back to doing the business. So how can you best work with them?
Keep your interactions with them short and to the point.
Put yourself in their position and learn their business area. The best strategy isn’t to walk in and ask SMEs for their requirements; rather, it’s to ask them about their business problems. Because they know the subject so well, they’re highly likely to give you solutions.
When you approach them, establish a rapport. You can briefly talk about the project to set the stage for the discussion topic, but very quickly go into having them explain what they do in their business area related to the project scope.
Keep it in their world. Don’t stray off onto other topics, even if they’re project-related. You aren’t solving your project; you’re solving their business problem.
Proactively notify them about the project and what it’s all about. They’ll want to tell you all about their experience with the process and probably will give you many ways to fix it.
Keep it simple. Use the business area’s language rather than project-oriented business analysis language.
How to confer with project support personnel as a business analyst
Because project support personnel are not fulltime members of the team, you need to be as efficient as possible with their time. Here are a few tips on how to do that:
Proactively point out what you need from them. Don’t make them search through loads of documentation to find what is relevant to them.
Make it short and sweet. Project support personnel are most interested in how your project interacts with their particular area of support. Don’t over-explain all aspects of the project; focus on how it impacts them.
Just like the technical team, don’t commit project support people’s time or involvement with a project before understanding their time constraints. Asking other parties for information helps establish your credibility as a liaison.
How to use technical personnel in business analysis
Although your primary job as a business analyst is to understand the intricacies of the business, you need to have some technical knowledge so that you can communicate effectively with the tech folks. Here are the situations in which this knowledge can help you:
When you have to understand their explanations so you can offer dialogue on the solutions.
When you need to validate the solution team’s understanding. If a given time estimate seems way off or they say the requirements can’t be met, you need to have enough knowledge to recognize that fact and to question their assumptions. In questioning their assumptions, you want to spark a good debate so the team comes up with the best solution for the business need.
Don’t commit the team to providing a particular solution without consulting the team first. If you want the team to be committed to delivering a solution, the team members need to be part of the process that came up with it.
The same concept applies to the quality assurance team as well. You don’t need to be an expert in quality assurance, but the more familiar you are with the processes followed and the techniques used, the more relevant your conversations with them will be.