Learn how to more effectively identify, negotiate for, and engage the necessary stakeholder resources for your next project through the power of stakeholder profiling.
The Stakeholder Profiling technique works well in any development environment such as agile, iterative, or waterfall, and can be leveraged at any stage of the development life cycle. While ideally used from the project start, this technique is great for projects that are already in motion since it is never too late to engage the right stakeholders.
This course is designed for those seeking to improve their ability to:
By the end of the course, you will be able to:
The ideal student for this course is the:
This course includes 9 modules, 31 lectures, 2 hours and 6 minutes of videos, 10 quizzes, 3 downloadable quick-reference job aids, and a complimentary PDF of ‘Chapter 2: Involve the Right Stakeholders’ from Roxanne Miller’s book The Quest for Software Requirements.
Enroll now and gain access to the stakeholders you need!
Welcome to Stakeholder Profiling!
In this course, you will be learning about a powerful resource planning tool that will help you to better plan your requirements approach, and to negotiate for the necessary stakeholder resources that you need to have a successful requirements initiative. In this first video, your instructor, Roxanne Miller, will provide you with the Course Roadmap so that you know what to expect from the upcoming lessons and modules.
In addition to this Course Roadmap, you will also learn about the first of the four core scoping models, the relationship map. The relationship map is your first key input to scoping requirements as it will help you to identify the knowledge needed before engaging with your stakeholders.
In the second module, you will join Roxanne in the classroom and be entertained by live lectures where she provides you with a high level overview of the Stakeholder Profiling technique, and sets the stage for the modules and lessons that follow.
Modules Three through Eight
In modules three through eight you will learn about each of the six steps of the Stakeholder Profiling Technique as we take deep dives into the tasks and techniques that you will employ to have a successful requirements initiative.
Finally, in module nine, Roxanne will address a variety of frequently asked questions that students often have when participating in live classroom training.
Once again, we would like to thank you for choosing Requirements Quest, and look forward to helping you have more successful projects!
Join Roxanne in a pre-recorded live training session where she presents an overview of the Relationship Map modeling technique.
This quiz will affirm your understanding of the material presented in the overview of the Relationship Map.
In this pre-recorded training video, you will join Roxanne in the classroom as she gives you a high-level overview of Part One of the Stakeholder Profiling Technique.
This quiz will affirm your understanding of the three steps in Part One of the stakeholder profiling technique.
A pre-recorded video of live classroom training is presented in this lecture to provide an overview of part two of the stakeholder profiling technique.
This quiz will affirm your understanding of the three steps in Part Two of the stakeholder profiling technique.
The Two Parts and Six Steps of Stakeholder Profiling:
Part One: Identify Potential Stakeholders
Part Two: Secure the Stakeholders
So, what exactly do I mean by business models?
While the term is very broad, and can cover a variety of different forms of documentation, what I frequently like to use, or look for when I start a project are existing artifacts or deliverables that help me to understand how the business operates. Examples include:
Getting your hands on this type of documentation before engaging with your stakeholders will help give you a better idea of what the project goals are.
This practice is especially important if you are put on a project mid-stream. Reviewing the existing business models that the previous business analyst, project manager, or product owner may have developed before you were put on the project, will help paint a better picture in your mind of the overall scope of what you are expected to contribute to or work on.
Even if you are starting in on a new project, reviewing these existing models is equally important as they can assist you in developing a useful set of questions before engaging with your first stakeholder (likely the product owner or project sponsor).
So, to recap, if you have the opportunity to review any existing documentation that may in any way be related to the project, I strongly urge you to do so. Again, this will help you frame your mind around what the project goals are and will help you better develop a sense of the potential topics of expertise that you need during the requirements process.
This quiz will affirm your understanding of what to look for when reviewing existing business artifacts.
Unfortunately, far too often, business models do not exist. So what can you do if no models exist? Develop them, of course!
To successfully kick off your next project when no documentation exists, start by engaging the product owner or project sponsor in what I like to refer to as the 45-minute scope interview. The success criteria for this initial interview are to formulate a high-level understanding of the project and to draft a relationship map to represent the broad scope of the project. I presented the relationship map in the previous section. In all honesty, regardless of what documentation exists, I always start with this interview, and either review the existing relationship map or create one. I recommend this to form the foundation for planning your work.
On a side note, I suggest that you include your stakeholders when drafting any models for your project. Why? Because, if you create a model, you own it. If you create a model with the stakeholders, they will be more likely to take ownership in it, and be more committed to it. Further, when you bring the model into later discussions, the stakeholders will already be familiar with it, and it will save you time.
Okay, getting back to the 45-minute scope interview, you are going to be asking the product owner, or project sponsor questions such as:
This relationship map will be your roadmap for the project and will really serve as your first key input to drive your elicitation activities moving forward. It will help you to more effectively begin the all-important next step of brainstorming the topics of expertise that you will likely need to successfully define requirements.
Now, why do I recommend the relationship map as the first model you should develop? Two reasons.
First, it is quick and easy. The relationship map is there to give you a high level understanding of the project scope. You should look at the big picture before diving into the details.
Second, it helps to provide both you and your stakeholders with a broad picture of the scope of your project. Did you know that over 65% of the population prefers visuals to take in information? So visually speaking, the relationship map helps you see if you are on the same page.
As you will see in the upcoming lecture, I highly recommend that you bring the relationship map to each and every stakeholder interview that you conduct, and use the visual representation of the project to ask your stakeholders:
The relationship map will help you to communicate your understanding of the project and serve as a way to start a conversation with the stakeholders, and to better understand their view of the project.
Remember, the relationship map is an iterative model, meaning that it will, and should evolve and change with each and every stakeholder that you interview. When you show the relationship map to your stakeholders, they will contribute to uncovering other entities and topics of expertise that you may have overlooked.
This quiz will affirm your understanding of the direction you might take when business models don't exist.
In the previous module, we discussed the importance of reviewing existing business models and creating a relationship map to understand the scope of your project.
In this module, we will be taking a closer look at part one, step two: brainstorming topics of expertise.
We’ll look at how you can better leverage those business models, and specifically the relationship map that you created from the 45-minute scope interview with the project sponsor or product owner, to more effectively brainstorm topics of expertise.
Now, before we begin, I would like to stress that this is absolutely the most essential step to successful stakeholder profiling.
Because if you do not do an effective job of brainstorming topics of expertise based on the business areas that are impacted, you will probably be ineffective with those stakeholders you identify, miss or overlook key stakeholders, and ultimately overlook or poorly define the requirements for the project.
Now that I’ve covered the importance of this step, here is what you can expect from the upcoming lectures in this section.
So what technique should you use to brainstorm topics of expertise?
To have a successful requirements initiative, I often say that it’s not about WHO you know. Rather, it’s about WHAT the who knows. Now I know that the sentence structure of ‘what the who knows’ violates English grammar, and might sound a little funny at first, so let me better define what exactly it means.
When you begin brainstorming for topics of expertise, you should focus first and foremost on the knowledge that you need for your project. Many business analysts make the mistake of jumping straight to identifying WHO they’re going to talk to. I like to refer to this as the “Assumption Trap,” and I will dive into this further in a later lecture.
So just to be clear, in this step you are not thinking about the actual people that may be potential stakeholders you will need to engage. You are strictly focusing on brainstorming the topics of expertise or knowledge that you need.
So again, it’s focusing on WHY you need to engage someone, thus ‘what the who knows’, not who you know. Later, in step three, we will discuss how once you have successfully brainstormed these topics of expertise you will be able to do a better job of identifying the actual people that you need to engage to successfully elicit the requirements surrounding those specific topics.
So, how do you begin brainstorming the topics of expertise?
Well, it’s pretty easy. You start with your draft of the relationship map that you generated from your first 45-minute scope interview with the project sponsor or product owner. From here, you move from entity to entity answering the question, “I need someone who knows ___?”
Fill in the blank with the knowledge that you think you might need involving that specific entity. Now, as you do this, do not worry about the order, or organizing of the topics of expertise. Remember, this is just a brainstorming exercise.
To demonstrate how this technique is applied, join me in the next lecture where I will provide you with a real world example.
This quiz will affirm your understanding of a brainstorming technique named I-Need-Someone-Who-Knows.
As we covered in the Requirements Quest Shopping Cart example, I needed someone who knew about, or had the knowledge of Website Administration, Shopping Cart Features, and Online Payment Processing.
So how did I identify these topics of expertise?
I looked at the entities on my relationship map. For example, one of the entities is online payment processor. At a high level, my topic of expertise is online payment processing. Applying the technique, I filled in the blank, I need someone who knows online payment processing.
Another entity on the relationship map is website administrator.
Similarly, I applied the technique at a high level, and filled in the blank, I need someone who knows website administration. Starting with the entities identified on my relationship map, I answered the question, “I need someone who knows ___?” By answering the question, I need someone who knows (blank)?, I am identifying the knowledge that I need represented to do a good job of defining requirements.
That is, I am focusing on WHAT the who knows. What the Who Knows, is the reason WHY I will invite someone to participate as a stakeholder.
After you have identified these high level topics of expertise, you need to drill down deeper by asking, “What exactly do I need to know about this topic?”
Referring back to our shopping cart example, one of the topics of expertise was, online payment processing. After identifying online payment processing as a high-level topic of expertise, I asked, what exactly do I need to know about online payment processing? In essence, for each high level topic, I ask, “What about it?” As I drilled down deeper on Online Payment Processing, I developed granular sub-topics such as:
Payment processing costs Performance or impact on the current website and hosting And Interoperability, or effort to install or interface with By continuing to ask the question, “What about it?”, I am able to further subdivide my topics of expertise and articulate the specific knowledge that I need to know about each topic.
As a general rule of thumb, you will know that you have successfully completed the I-need-someone-who-knows brainstorming activity when you have identified two to five granular sub topics for each entity that you identified in your relationship map.
Further, I would like to point out that this brainstorming activity is not a solo effort. Whenever possible, you should involve stakeholders, as again, involving stakeholders from the beginning will increase their commitment to the requirements.
In summary, after you have identified the initial high level entities that are impacted within the scope of your project via your relationship map and answering the question, “I need someone who knows ___?”, you will uncover the more granular topics of expertise by asking, “What exactly do I need to know about this topic?”
So again, focus first on the knowledge needed, and the person that holds that knowledge second. If you do not take the time to adequately brainstorm these topics you increase the risk of missed requirements.
This quiz will affirm your understanding of how the brainstorming technique is applied.
A common mistake that I see business analysts make is doing an ineffective job in this brainstorming activity, or they skip this activity altogether. I refer to this mistake as the assumption trap.
The assumption trap consists of a business analyst moving too quickly and automatically engaging with people that they assume have the knowledge or expertise that is needed, despite not knowing the stakeholders’ true level of knowledge in that topic. This is a dangerous road to go down.
Do not engage certain people because you think they know something, or you think that they are an expert on a certain topic.
While your assumptions can undoubtedly be a good starting point for identifying potential stakeholders, working strictly off of your own assumptions–assuming that you know the people that have the knowledge that you need–you may overlook a person that is more of an expert on a certain topic and is more knowledgeable than the people that you assumed to have the knowledge. If you do this, you put your project at risk for missed or poorly defined requirements by engaging with people that have less knowledge than others.
Do you see how you can overlook potential experts by not engaging in effective brainstorming?
To illustrate this, let’s again refer back to our Requirements Quest Shopping Cart Project, and pretend you are the business analyst on that project.
When you begin your project, you may assume that Person A and Person B have significant knowledge or expertise in Website Administration, and you jump ahead of yourself to engaging with those two individuals before going through the stakeholder profiling activities.
By assuming to know that Person A and Person B are your company’s two resident experts on website administration, and engaging with them, you may overlook Person C who actually has far more experience and knowledge in website administration than the other two. Again, do not fall into the assumption trap.
By assuming to know the knowledge or expertise that other people have, and by not utilizing the stakeholder profiling technique, you put your project at risk for missed requirements by overlooking potentially valuable resources that you otherwise would not engage.
When I encounter a business analyst heading for the assumption trap, I ask them the following questions:
Why are you going to talk to that person? What knowledge do they have that will be beneficial to you for this project? And, have you validated that knowledge? You can avoid the assumption trap by focusing first on what knowledge you need and second on the potential person that has that knowledge. Beyond this, you need to validate who indeed has that knowledge.
In part two, step four, I will show you a survey technique that you can use to validate the level of expertise of your potential stakeholders in a particular topic.
So, one more time, and I do not mean to sound like a broken record, but I must stress that this step of brainstorming your topics of expertise, and avoiding the assumption trap is absolutely critical to your success in stakeholder profiling and more importantly, your success in developing good requirements for your next project.
This quiz will affirm your understanding of the Assumption Trap when brainstorming topics of expertise.
So how do you know when you have successfully completed step two—brainstorming topics of expertise?
As a general rule of thumb, you will know that you have successfully completed your step two brainstorming activities, when you have identified two to five granular sub-topics for each entity that you identified in your relationship map.
So let’s define the meaning of the word potential.
In reference to this step, the word potential means maybe. It means maybe you’ll use them and maybe you won’t. That is because it depends on the stakeholder’s level of expertise in a particular topic, and their availability to engage in your requirements development activities.
For example, are they an expert? Do do they know enough to be dangerous? Or do they know so little that engaging with them would not add value to your requirements development activities?
Furthermore, you may identify an expert as a potential stakeholder, but that expert has very limited availability.
These situations will all be addressed by the process of stakeholder profiling in part two.
Your objective in this step is to identify anyone and everyone that you think has the knowledge you need. Do not make the mistake of eliminating potential people from your list because you don’t think they know it, they are unavailable, or you were told you can’t talk to a person. Do not put artificial constraints on who you identify as potential stakeholders.
Let’s look at a few examples from the Requirements Quest shopping cart project, and pretend you are the business analyst on this project.
One topic of expertise is website administration, and we identify Jeff and Sarah as potential stakeholders for this topic. We also have online payment processing as a topic of expertise, and again we identify Jeff and Sarah as potential stakeholders.
Is it okay to identify the same stakeholders across multiple topics?
The answer is yes.
It is more than okay to utilize the same resource for multiple topics. It can be an advantage as you will be able to accomplish more with fewer resources. However, having said that, it can also be a disadvantage because you could potentially be tying up the same resource for longer periods of time.
So, how did we initially identify Jeff and Sarah as potential stakeholders for these topics? Well, you need to start somewhere, and most often that starting point is your own assumptions of who you think has that knowledge.
Now you may be thinking, “Hey, wait a minute, in the last step you told us not to fall into the assumption trap, by assuming to know who has the knowledge that we need.” And that’s true. I did.
However, I also said that assuming does have its place in stakeholder profiling, and that it is undoubtedly a good starting point, particularly for this step, but only briefly. The assumption trap occurs when you jump to identifying potential stakeholders before effectively brainstorming topics of expertise.
Whatever knowledge that you assume someone has in this step will be validated in the next step of the stakeholder profiling process. So let the process do the work for you. The process will ultimately lead you to the right stakeholders.
If you assumed that someone has expertise on a given topic, and later find out that they don’t have the level of knowledge you assumed, then remove them as a potential stakeholder for that specific topic of expertise.
In the previous step, we discussed the brief benefit of assuming who you think has the knowledge of a particular topic as your starting point to identify potential stakeholders. In this lecture, we will be covering how to build your stakeholder survey to confirm actual stakeholders that have the knowledge needed in each topic of expertise. In other words, the stakeholder survey allows you to effectively transition from potential stakeholders to confirmed stakeholders.
Through this step, your goal is to identify at least two stakeholders in each and every topic of expertise that express a level of knowledge that is either proficient or an expert.
Whoa! I’m jumping ahead. Let’s back up and cover how to build your stakeholder survey.
You may recall from viewing the live training lecture that creating this survey is pretty easy. Building the survey involves simply taking the topics of expertise that you identified in step two of part one and translating it into a template such as this.
Down the first column on the left hand side, you will have your list of topics of expertise, and include four columns on the right hand side for ranking the level of knowledge from little to expert.
These columns will be used by the stakeholder being surveyed to rate or express their level of knowledge in each topic of expertise. If they know a lot, then encourage them to place an X in the expert column, or at the very least, the proficient column, and if they know little or nothing, encourage them to put an X in the little column.
After you build your stakeholder survey, the next activity in this step is to interview each potential stakeholder to understand their level of knowledge in each topic.
In the next lecture, how to conduct the 20-mintue interview, I will explain how to best go about administering this survey to not only understand each potential stakeholder’s level of expertise in my identified topics, but to also establish trust, build rapport with them.
Now that you have your survey built, let’s take a look at how you will administer that survey to your potential stakeholders using what I have coined as the 20-minute interview.
Before we begin, I would like to point out that while I call it the 20-minute interview, the reference to 20-minutes is not to be taken literally. Rather, it is named this way to emphasize the casual nature in which I recommend you conduct the interview. Do not pigeonhole yourself to allotting only 20 minutes for these interviews, as they very well could run longer, and most typically will.
Keeping that in mind, let’s dive into how to best conduct this 20-minute interview to successfully complete your stakeholder survey.
During this interview, your primary objective is to come away with an understanding of what that person knows relative to the topics of expertise that you have brainstormed.
Your secondary objective is to ask for their help in confirming the accuracy of your list of topics, as well as identify additional potential stakeholders.
Literally how to accomplish this is spelled out for you in the ‘Stakeholder Profiling Interview Script’ that I provided to you in a downloadable format in the previous lecture. You heard a variation of this script applied in the live training lecture where I pretended to interview Josephine.
If you have not taken the time to review the interview script, I highly recommend that you pause this video now and do so.
If you have already done so, excellent, thank you!
Now that you understand the two main objectives to the 20-minute interview, as I covered in the last lecture, let’s dive deeper into some tips and suggestions on how to conduct a successful 20-minute interview.
In this lecture, I am going to briefly present the following tips:
Tip number one, whenever possible conduct the interview in person.
Enabling face-to-face interaction is your first step to establishing trust and building rapport with your stakeholders. If face-to-face is not an option, then minimally you should conduct this interview via teleconference. As I stated in the live training lecture, do not email the survey to them.
Because you lose out on the opportunity to build rapport, show genuine interest in them, educate them on the process, do you see where I’m going with this? These are the other tips for conducting a successful interview.
My second tip is to be prepared!
Preparation means following good meeting etiquette including a proper invitation and agenda. This demonstrates your professionalism.
For the purpose of this 20-minute interview, being prepared also means printing the agenda to keep the meeting on track, and bringing the copy of your relationship map as an aid to the discussion. And, of course, bring your survey.
Tip number three is to keep it casual.
Keeping the interview casual is necessary to build rapport and establish trust. You should not ask pointed questions about the person’s job that could make them feel uneasy. You are there to determine if they are going to be a good fit as a stakeholder for your project. You are not there to grill them on how well they perform in their role or how they could improve. You are there to understand what they know about your identified topics of expertise.
On a side note, the soft skills as they pertain to the business analysis position and the importance of developing these skills are often overlooked. This 20-minute interview presents you with a perfect opportunity to practice those skills.
Tip number four, and this is really an off-shoot of tip number three, and that is to show genuine interest in them.
Displaying genuine interest helps the individual to relax, and often results in their opening up to you about what they do. Getting the stakeholder to feel comfortable, again, helps you to build rapport with them and to establish trust.
While still managing your scheduled time, opening with some casual conversation such as, “How is your day going?” can help you break the ice.
Finally, my fifth tip is to educate your stakeholders about the process and how it will benefit them, which I will elaborate on in the next lecture.
So again, just to recap my five tips to conducting a successful 20-minute stakeholder interview are to:
As you may recall from the previous lecture, my fifth and final tip to successfully conducting your 20-minute interview is to take the time to educate your stakeholders.
So what exactly are you educating them on?
Well, you are educating them on the technique itself—literally explaining what the technique is, and how it will benefit them.
One benefit is reducing the amount of wasted time in unnecessary meetings. Through effective stakeholder management, you will only invite the stakeholders that have expressed either a proficient or expert level of knowledge around a specific topic of expertise. Moreover, you will only invite between two to four of these resources to the meetings you have on any given topic.
This is to say that if you identify more than four resources that have knowledge on a particular topic, you will only engage two to four of them. This will also help reduce the amount of time spent in those meetings because naturally, the more people you add to the conversation the longer it will take.
Further, if you have a person that is an expert on two topics, and you know that that person is very busy, and in one of those topics you have multiple resources at your disposal, you can give them the option to decline participation as you can leverage others. This way, if they are not invited to a meeting on a specific topic, they are not offended, because they understand why.
Similarly, if a stakeholder is an expert on one topic but knows very little about the others, they will not be offended when you exclude them from meetings on topics that they are not familiar with.
Another benefit of the stakeholder profiling technique that you can educate them on is the opportunity to alleviate resource bottlenecks.
Say for example, there is a thirty year veteran in the office, someone that seems to know everything about everything, and gets invited to everyone’s meetings all the time because they are such a wealth of knowledge on a wide variety of topics of expertise.
Well, through educating your stakeholders you can explain to that person that you understand they are busy and you give them the option to decline participation since you can engage other stakeholders that are proficient, where available.
However, if they are truly your only expert, then you can opt to engage other stakeholders who are proficient in the topic to draft the requirements and minimally engage the expert to validate the requirements.
To summarize, two benefits to the stakeholder for using this technique are:
Reduce the time wasted in unnecessary meetings And, alleviate resource bottlenecks.
So, how will you know when step four is complete?
You will know step four is complete when you have identified between two to four stakeholders for each topic of expertise.
After you’ve completed your stakeholder surveys by conducting your 20-minute interviews, in this step, you will compile your survey results, analyzing each topic of expertise to identify stakeholders with a level of knowledge that is either proficient or expert.
Recapping what you viewed previously in the live classroom lecture in section two, use a table such as this. In the first column on the far left side list your topics of expertise, and in the columns to the right insert a separate column for the names of each of your potential stakeholders. Then, looking at each survey individually, transfer the indicated level of knowledge in each topic for each surveyed stakeholder.
In this example, you can see that if the person marked their level of knowledge as proficient in a certain topic, I simply placed a P under their name next to that topic. Following this same pattern, if the person marked their level of knowledge as expert in a certain topic, I simply placed an E. As you can see from this example, Joe indicated in his survey that he has proficient knowledge in shopping cart features, little knowledge in website administration and some knowledge in online payment processing. Based on Joe’s survey results, the only topic of expertise that I might engage with Joe on further is that of shopping cart features.
Looking further down the columns in our table at Tom, Tom indicated that he has some knowledge in shopping cart features, expert knowledge in website administration, and some knowledge of online payment processing. Based on Tom’s survey results the only topic that I would further engage with Tom on is that of website administration as he has expert knowledge in this topic.
Now again, as a reminder, in our 20-minute interview we took the time to educate each stakeholder that we would only be engaging with them on topics of expertise, where they indicated they have either a proficient or expert level of knowledge. Additionally, this table of complied surveys can also help us identify potential resource bottlenecks. To do this, rather than looking at an individual stakeholder’s column, we will look at an individual row.
As you may recall, I am looking for ideally two to four people in each topic. So looking at the top row more closely, I can see that three of my potential stakeholders have indicated a proficient level of knowledge in shopping cart features.
Taking this a step further, let’s say that hypothetically, Joe is one of the busiest guys in the office. Since we have two other stakeholders that have identified themselves as having proficient knowledge in shopping cart features, it may be more advantageous to engage with Sarah and Eric and exclude Joe thereby minimizing Joe’s involvement.
Analyzing further, we look at the row for online payment processing, and see that we only have one stakeholder, Sue, who is proficient or an expert, which falls short of our goal for two to four people. So what do we do? We raise an issue with the product or project sponsor regarding potential risk of missed requirements due to resource shortages.
In the following section, we will discuss how you can leverage this tool to have that conversation with your product owner or project sponsor to raise attention to project risks and work together to reduce the risk of missed requirements.
Planning your requirements approach using the compiled surveys begins with looking at the total number of topics of expertise. The total number of topics of expertise is your first indicator of the scope and complexity of the requirements development effort. Is this a large project? Medium project? Or small size project?
After recognizing the size of the project, next, work with your product owner or project sponsor to prioritize the topics of expertise. The timing of when the prioritized topics ultimately get addressed will occur based on your development approach, such as waterfall, iterative or agile.
Now, obviously, effectively estimating the time allotted to each topic will come with experience. And that experience is both relative to the development environment you are working within and also your time in an organization.
If, for example, you are operating in an agile development environment, and referring back to our Requirements Quest shopping cart project, let’s say that online payment processing is identified as a high risk topic. The product owner plans to address the requirements for that topic in sprint one.
Based on the stakeholder that I have identified for online payment processing, Sue, I would plan to engage with Sue during sprint one. Accordingly, I would communicate with sue to give her a heads up about the estimated timing of sprint one and work with her to figure out a time that best fits her availability.
Conversely, an example of organizational experience can be better illustrated through Tom. Let’s say that, Tom, being our only expert in website administration is notorious for declining meeting invites, and when he does accept them, is highly uncooperative.
Understanding that Tom is a necessary stakeholder for this topic will help you to address performance issues with the product owner, and develop solutions together for how to best engage with Tom.
In the next lecture, I will dive deeper into how this tool can be used to negotiate and secure the necessary resources.
In the previous lecture we covered how you can use the compiled surveys as a tool to plan and prioritize your requirements development activities with your product owner or project sponsor.
In this lecture we will discuss by way of example, how you can leverage this tool in negotiations to secure resources.
As Business Analyst’s we have all had that project where we are assigned stakeholders by the project sponsor or product owner. We are told who we have access to and who we don’t have access to.
As we all know, this is not the most advantageous strategy to effective requirements development, as the stakeholders that are assigned to our project very well may not have the right knowledge that we need to do our jobs well.
Rather, through the process of stakeholder profiling, you will build a tool that will allow you to approach your project sponsor or product owner with supporting documentation, and request access to stakeholders that have the knowledge you need.
Now, as a business analyst, I would be remiss to not acknowledge that it may be intimidating to request access to certain people from your higher up, especially after they have assigned resources to your project. But by qualifying WHY you need access to them, and explaining how by gaining access to them you will be able to do your job more effectively, and help reduce the risk of missed requirements thus saving the company money in reduced rework; they will not only respect you more, but they will see your value and should more likely give you access to those resources.
To illustrate this, let’s refer back to our Requirements Quest Shopping Cart Project.
As the business analyst on that project, the product owner or project sponsor may assign you three resources that you have unlimited access to for your requirements development activities. However, as you progress through your first few elicitation activities, you might quickly learn that the three resources you were assigned do not have adequate knowledge about shopping cart features, or payment processing, or perhaps any of the other topics of expertise that you identified using your relationship map and brainstorming activity. So despite that unlimited access, these folks will not be able to adequately provide you with the information that you need to write good requirements for the project.
So what can you do?
Well, you could go back to that sponsor and tell them that they don’t know what they are talking about, and that the resources they assigned are useless. But that, of course, would not be the best thing to do to your co-workers or your career, especially because those resources may be highly knowledgeable in a different area of the business, just not about website shopping carts.
For the record, I am not recommending that is what you do!
Rather than throwing your co-workers under the bus, what would be better is to go back to your sponsor with your compiled surveys, and tell them that while you appreciate the access that you were given to the resources, and while they are highly knowledgeable about other facets of the organization, they are unfortunately not the best resources for the specific project.
Further, through using your compiled surveys, you will gain confidence to go back to that individual and say, “I would like to talk to person X,Y, or Z because I believe that they may have knowledge more relevant to making this project successful.”
By qualifying the topics of expertise that you need to your higher up, you will be able to better ask for the right resources and reduce the risk of missing requirements.
The questions presented in this module are some that I accumulated over years of instructing, coaching, and mentoring business analyst practitioners. Interestingly, the questions are not about the mechanics or steps to building the stakeholder profile. Rather, the questions focus on managing the stakeholders once you identify them, and handling stakeholder availability issues. In some respects, they are even concerned with convincing ‘management’ that the stakeholder profiling technique is a valuable investment of time and resources.
In this section, I want to help you gain confidence in applying the technique, and offer tips for handling some of the sticky ‘people problems’ while managing your stakeholders.
Identify when you start the stakeholder profiling process, as well as when you’re done.
Learn how to deal with stakeholders that claim they know more than they really do on a topic of expertise.
Understand how the stakeholder profiling process helps to overcome situations where a stakeholder underrates their level of knowledge on the topics of expertise.
Gain suggestions for using stakeholder profiling to approach stakeholders that decline your meeting invitations.
Learn how to better deal with stakeholders who truly are too busy to participate in the requirements initiative.
Gain suggestions for using your compiled stakeholder surveys as a tool for approaching the project sponsor or product owner about resource needs.
Discover how stakeholder profiling can help you estimate when you’ll need to engage your stakeholders and for how long.
Hear about one of Roxanne’s success stories from using stakeholder profiling.
Thanks again for purchasing the Stakeholder Profiling course! Roxanne invites you to connect with her, and to visit the Requirements Quest website for free resources.
Industry expert and the Requirements Super Freak, Roxanne Miller is a Certified Business Analysis Professional (CBAP) and an engaging, passionate requirements coach, mentor, and trainer. Roxanne's popular book, The Quest for Software Requirements, is a first-of-its-kind reference guide that helps business and IT individuals master the elicitation of hard-to-identify and vital nonfunctional requirements. A companion file, Software Requirements Questions, contains the 2000+ elicitation questions included in the book (sold separately).
Roxanne has been involved in the Information Technology (IT) industry since 1984 and founded Requirements Quest® in 2001. Roxanne is committed to bringing your business into focus®! She has been consulting on requirements process improvement and business analysis practices for over 20 years. As principal consultant and lead instructor at Requirements Quest, Roxanne has consulted, mentored, and delivered live training to over 5,000 business analysts worldwide. Roxanne earned a bachelor degree in Management Information Systems (MIS) at the University of Wisconsin—Eau Claire, Eau Claire, Wisconsin, USA.