People want to work with those they know and share similarities with. Communication is easier (and problem-solving is just faster) when individuals have good relationships. You can better manage tasks when you’re familiar with the team members’ strengths. Therefore, a key way you can foster success is to get to know the stakeholders beyond just knowing their titles and roles in the organization.
Build relationships with your project team and business stakeholders before you get assigned to a project to help ensure project success. Go to lunch, grab a coffee, or chat in the hall with your teammates and other stakeholders. Do what you can to get to know the ones you work with before they’re your stakeholders or project partners.
Objective characteristics of business analysis stakeholders
Here are some objective characteristics about your stakeholders that you want to know. These are characteristics you should keep track of for both current and future projects:
Physical location: Any time zone differences affect meeting schedules, and location differences affect face-to-face meeting availability.
Availability for project work: Remember that the project may be your first priority, but your stakeholders may have other projects higher on their lists. If a stakeholder is only available for the project a few hours a week, the project schedule must reflect this limitation.
Subject matter expertise: A stakeholder’s level of expertise helps determine how much of his time is needed for elicitation, reviewing, and approving requirements. This information also helps you formulate questions.
The technical team’s experience with you: If a developer or other team member has never worked with you and is unfamiliar with how you approach the analysis effort, plan to spend time explaining detailed needs in walk-throughs.
Experience on previous projects: If the stakeholders have had good experience working on previous projects, they’ll be very helpful. If they’ve had bad experiences or no experience, however, they may need more time to learn the process.
Preferred level of formality/mode of communication: Is this stakeholder someone who likes casual communications/notes or very formal, documented work products? Does he prefer talking on the phone, using instant messaging, or having face-to-face conversations?
Decision-making authority: Know who has authority to make decisions for this project. If key decisions aren’t being made, make sure you raise that issue to the people who can make the call to keep the project moving forward.
Everyone’s heard the golden rule: Treat others as you’d like others to treat you. For business analysts, the platinum rule applies: Treat others as they’d like to be treated. As business analysts, you need to adjust to your stakeholders’ preferred mode of communication.
For example, Kupe was working with a client right around the time he discovered text messaging (and his addiction to it). He texted the client about the project repeatedly throughout the week. Finally, she called him and said, “Kupe, stop texting me!” She didn’t have a text plan, and he was costing her money!
He made a huge assumption: that texting was a fine method of communication and that she liked it because he liked it. He should have confirmed whether she liked that form of communication before he started using it.
Subjective characteristics of business analysis stakeholders
You also want to be aware of some subjective characteristics. These are areas you want to know about but may not openly share:
Value to the organization: If this stakeholder is the main (or part of the main) talent or revenue generator of the organization, he may get more respect than other employees.
Think of those people in your organization who always get their way. Is it because they scream louder, have better political connections, or are they people who bring revenue into the business and therefore have greater needs based on that ability?
Culture/language: Understanding the native language and culture of each stakeholder helps you improve communications. Learn local customs whenever possible, and be careful not to offend stakeholders in various cultures. Making connections on a cultural and personal level helps the whole process go more smoothly, so build time in for really getting to understand a stakeholder’s customs.
Relationship to other stakeholders: If negative issues exist between stakeholders, plan more time for building consensus.
Emotional commitment to the project: If the stakeholder isn’t excited about a change, plan more time for requirements elicitation and organization change management.
Technical team skill level: If a developer on the team doesn’t have much knowledge in the solution technology, plan for more detailed functional requirements.
Ability/speed of decision making: Know your audience. Is this stakeholder comfortable making decisions quickly, or does he take more time and thought to come to a conclusion? In either case, make sure you take this characteristic into account.
Give someone who needs time to come to a conclusion info ahead of time. For someone who likes to get information at the last possible moment, don’t frustrate him by giving him information too early.