Abstract
This paper will take you beyond merely “managing” your stakeholders into the realm of deliberate relationship building. The ability to manage stakeholders' expectations is a critical skill for all program/project managers. But it's more than just expectations; it's the purposeful crafting of a collaborative and positive relationship that truly separates the very good project managers from the superb project managers. Effective stakeholder management requires an action plan and mastery of basic networking skills.
Here we will deep dive into some of the stereotypical stakeholder types such as the Bully, the Ghost, the Micromanager, plus others to uncover deliberate techniques for managing expectations and building collaborative relationships. We will delve into the field of psychology and look at some advanced networking practices to uncover real, actionable ideas for all project managers. All of the techniques discussed in this talk are in practice at Intel today and we will share the tips and tricks to managing the Bully, finding the Ghost, taming the Micromanager and many more useful ideas for project managers of all levels.
Stakeholder Management 101
There is a tremendous amount of information available today on the basics of stakeholder management. At its core, stakeholder management is networking in a professional environment. To be successful, project managers must be experts at managing the expectations of their stakeholders.
Have A Plan
It is common for junior project managers to manage their stakeholder expectations in an ad hoc manner. Sure, they are careful to be friendly and informative when the stakeholders are encountered but there's little deliberation or strategy employed in the overall management of these critical relationships. If this project manager is personable and reasonably adept at the soft skills then this method will work just fine for smaller projects. Where the ad hoc method falls short is with difficult stakeholders, highly matrixed organizations, and large projects. Here the results of this insufficient stakeholder management closely resemble a toddler pageant complete with prima donna parents, indifferent judges, and crying kids. The project manager's reputation is diminished, the team is constantly frustrated with 'bring me a rock' exercises, and the overall scope of the project is inflated.
The good news is that all of this drama can be averted with a couple hours of planning. Creating a stakeholder management plan is fairly straightforward and can be accomplished with a simple spreadsheet. The key here is to come up with a specific plan for managing all of the stakeholders on your project. If you leave this thing to chance or circumstance you will find yourself right back at that toddler pageant.
The first step then is to identify all of the stakeholders on your project. Now's the time to fire up your spreadsheet! List everyone who is officially assigned to the project or attends any meetings associated with your project under a “Name” column. Also, include anyone you suspect might be a stakeholder or who has a vested interest in your project. Use some common sense here. The goal is to identify your stakeholders, not to drag the planning phase out to the end of the year. Yes, your company's CEO is technically a stakeholder in your project, but I highly doubt that he or she's even aware of your project, much less interested in your team's progress.
Next determine each stakeholder's role on the project, their specific functional organization, and their geographical location, including time zones. Record all of this in separate columns in your spreadsheet. If you don't explicitly know this information then go find it or just ask the person directly. Don't skip this step! Now, using your handydandy spreadsheet to identify these people: official project team members, resource managers, budget owners, influencers and/or technical experts, deliverable providers, deliverable customers, and final release approvers. Finally, identify those “unofficial release approvers.” This is a special category for all of those people who truly have the ability to stop a project release irregardless of their position in the organization. There shouldn't be more than a few of these people, but they are incredibly important from a stakeholder management standpoint. Last, analyze the data and pick out your key stakeholders. This is admittedly a subjective exercise and your assessment of a stakeholder's importance may not align with theirs. This is okay! The point of the exercise is to figure out who your stakeholders are and their relative importance.
Now that you understand who your stakeholders are, you can easily craft a strategy for managing their expectations. Decide how often and via what format you will communicate with each stakeholder. It helps here to break them into categories based on how you communicate with them. If this sounds suspiciously like a communication plan, that's because it is! Once you've determined when and how you will communicate with your stakeholders, you need to automate. Use your current calendaring or task tracking system to set up reminders for yourself to contact the various categories of stakeholders. These reminders can be something as simple as… “Invite Melanie for coffee and give her an informal update on the project. Make sure to ask her about her overall satisfaction with the team's progress.” This part doesn't have to be complex or overly managed; it just needs to be intentional. Once you have those automated reminders in place all you need to do is act on them. You still need to employ your networking skills but the automated reminders make sure that you have a consistent, focused, and deliberate strategy for managing each of your key stakeholders.
Networking For Fun and Profit
Okay, now that those reminders are popping up on your calendar what do you do about them? The good news is that stakeholder management and maintaining your professional network are basically the same thing. As with any new contact in your professional network, you need to start by understanding the other person. What's important to them and why? What's their pain threshold when it comes to schedule, scope, and resources? What type of communicator are they? All of these are questions you need to think about when determining how best to engage with your stakeholder.
Once you understand who your stakeholders are, have a plan to manage their expectations, and have automated the process so that it happens at a repeatable cadence, it's time to think about how to engage with them. By far the most effective way to build a relationship is to break bread with the other person. Invite your key stakeholders for coffee, lunch, or drinks and start off on a friendly note. There's just something about breaking bread together that creates an environment conducive to meeting the other person half way. At first you might talk about your differences and hash out collaborative solutions. Later you begin strategizing on issues affecting the project/program in general. As time goes on and the professional relationship strengthens you will start using each other as sounding boards for other work challenges. Years later, I still meet with many of my old stakeholders for lunch or drinks every few months. They've become members of my professional network and I never hesitate to reach out to them for help or to provide help in turn.
To actively manage your stakeholders' expectations, you have to know what those expectations are in the first place. Start by simply asking your stakeholder what they expect from the project. Don't be fooled here as what they tell you is most likely only part of the story. When you begin working with your stakeholders you can nail down the basics like what level of involvement they want to have with the project, the frequency and format of status updates, which decisions they want to participate in, etc. After you've established a relationship, you can then start asking for feedback. Is there something more you and your team can do for the stakeholder? Is the frequency and depth of the regular updates adequate? Is the stakeholder satisfied with the team's progress to date? As the relationship progresses, you can move into brainstorming strategic challenges for the entire program, but you can't get to this point without putting in the work to understand who your stakeholders are and to actively manage their expectations.
A good place to start is with a customer–oriented mindset. Deliberately refer to your key stakeholders as customers, no matter if they are the final end user or not. This makes a tremendous difference with your team and with your own point of view. You see everyone has some understanding of what exceptional customer service looks like. Sadly, many of us aren't motivated to provide that level of service, especially if the prevailing culture is not customer focused. Therefore, the project manager must instill a customer service orientation into their teams and themselves. A stakeholder that's viewed as an important customer by the project team interacts with a team that's bought into their mutual success. This fosters a positive and collaborative environment, which in turn keeps the stakeholder's expectations in check.
Own the Communication
One mistake I often see project managers make is to not take control of the communication to their key stakeholders. All too often those same project managers believe that a well–crafted e–mail will suffice. They then leave it up to the stakeholder to glean meaning and intent from the message, thereby abdicating any influence over the stakeholder's expectations. To actually manage and affect your stakeholder's expectations, you have to own the conversation.
It's obvious that these conversations should be open and honest, but that's only part of the picture. You also need to actively manage the information being conveyed. In short you need to ensure that you're not sharing too much information. Now I'm not advocating deceiving your stakeholders but I do believe you should be very careful about what information you do share. How you determine what and how much information to share is situational and frankly a matter of experience.
First, let's start with the information you should always share. Changes to committed dates must always be disclosed, even if it's bad, especially if it's bad! This is a matter of integrity since you've essentially given your word that the team can deliver to a specific date. Nothing less that complete honesty is acceptable; just make sure you have a recovery plan to share when the news is bad. Further, changes to the execution strategy that could affect the customer should be shared. If your team decides to drop a particular test to accelerate the timeline, then the customer probably cares and needs to know. Conversely, if your team decides to use a different software package to develop the code, then the customer probably doesn't care and there's no need to disclose this. Essentially any information that could be actionable to the customer should be shared.
Likewise, any information that does not inspire action on the customer's part should be withheld. Ask yourself what the customer will do with this particular information. If the answer is “nothing,” then consider not bringing it up. Often project managers will provide their stakeholders with updates to tasks that are not on the critical path. There's nothing inherently wrong with this, but consider that the stakeholder probably doesn't care. Yes friends, that's the harsh reality…they don't care! My customers frankly couldn't care less if I get the assembly instructions done on time because all they care about is whether or not manufacturing can deliver consistently. I have to care about those documents; they don't.
In fact, the percentage of work your team is doing that your stakeholders actually care about is surprisingly minimal. What the stakeholders really care about is whether or not your team is on track to the committed dates and the final quality of their deliverable. The stakeholders are expecting you, as the project manager, to care about and manage the details. It's your job to ensure all of those day–to-day things turn out right and do not affect the final deliverable. It's a mistake for project managers to disclose this level of detail to the stakeholders. Consider this, when you tell your stakeholders that the team is behind on finishing the CAD work for the chassis assembly, what you are really saying is that the team is behind schedule. Your stakeholder hears that you're behind schedule and the implication is that this schedule slip will affect the committed delivery date. Now you and I know that that impression is most likely false. Let's say, for argument's sake that this type of thing happens multiple times throughout the life of the project. When you continually give your stakeholders the impression that the work is out of control, you lose credibility. Once you lose credibility it's really hard to influence those stakeholders and any negotiation becomes rather painful. In short, because you disclosed a bunch of information that was not actionable by the stakeholder, you lost their confidence. If you're anything like me, then you've been in this situation before and know it's not pretty.
Finally I should make a few comments about spinning your message. News Flash: You are not an ad agency! Don't put unnecessary “spin” on a status update. Don't try to obscure the true meaning or hide a looming problem. That's just plain unethical and it's a kissing cousin to a flat out lie. Don't do it! On the other hand, you do need to make sure that your message is communicated at the correct level of complexity. Keep status updates to those outside your immediate team succinct and to the point. Remember that your message needs to be actionable to the stakeholders. Don't add so much detail that the person being communicated to has to spend an hour to decipher the message to figure out what actions to take. If the project is on track, then just say so. If you're trending two weeks late, state that and then follow up with your recovery plan and potential impacts to other stakeholders. Last, where at all possible, use quantitative data. It will lend instant credibility to your message.
Apply Some Psychology to Your Stakeholders
There is a tremendous amount of research out there regarding how the brain works and project managers can gain useful insights into how to influence their stakeholders by studying this data. This insight is particularly useful when determining a particular strategy for conveying bad news. You know that you shouldn't go into your most important stakeholder's office and just blurt out “We're now a month behind schedule because someone dropped the controller off the forklift. Oops!” and run out the door. Instead you need to understand how the brain works and craft an appropriate message. What you need to do is describe just why that forklift driver dropped the controller, in detail. You see explaining an event lessens its emotional impact. By dropping your bomb and running away you actually enhance its emotional impact thereby ensuring an enraged stakeholder. (Gilbert, 2007, pp. 207–208) Explaining why it happened is a critical component of delivering bad news.
Another critical component when dealing with stakeholders is their overall sense of control. It's vital that you help your stakeholders maintain a sense of control over the project and a belief that the project itself is under control. You see it makes people happy to have a sense of control over their environment and it is gratifying to exert that control. (Gilbert, 2007, p. 22). So knowing this, the astute project manager will deliberately go to their key stakeholders on a periodic basis and ask them to exert some direct control over the project. For instance I might go to the stakeholder to ask for their assistance removing a roadblock. In this instance, it doesn't matter that I could have taken care of the issue myself. It will make my key stakeholder happy while giving her a sense that she's part of the team and can influence what's going on with the project. Now obviously you would not want to over–use this technique and create the impression that you're incompetent but a judicious use can be highly effective and maintain a happy and supportive stakeholder.
While a project manager may go to a stakeholder for help removing a roadblock, it's much more common to consult with a key stakeholder over a major decision about the direction or prioritization of the project. In these instances the project manager will prepare a set of recommendations for the stakeholder to review and make a ruling on. Understanding how the brain makes decisions can be extremely useful in this scenario. You see when it comes to making decisions the brain behaves a bit like that toddler in the pageant I mentioned earlier. When presented with a side–by-side comparison of data the brain tends to zero in on the differences even if they are not relevant to the decision that needs to be made. (Gilbert, 2007, pp. 157–158) Think of the toddler who at the start of the pageant only wants to leave with a sparkly tiara. When she does place in the contest and the emcee negligently grabs the tiara with the blue stone off the judging table to plunk on her head, she's immediately starts wailing because she now passionately wants the one with the pink stone. Prior to the competition she only wanted that sparkly tiara, but when it comes time to receive it, she's making a value decision about a difference she did not even care about at the beginning. Of course your stakeholder isn't going to carry on like a toddler with a blue stone tiara, but they will certainly focus on any comparative differences in your data, so make sure that you only include those data points that are relevant to the decision to be made.
What makes managing stakeholder so very challenging is the people. We each have our own quirks and idiosyncrasies which require the project manager to continually build a toolbox of techniques for effective communication and influence. Developing a solid plan for regular interaction with your stakeholder, owning the conversation, and applying some of the learnings from the field of psychology can move you from a good project manager to a great one.
The Trick Bits: Managing The Tricky Stakeholders
No matter how good you are at stakeholder management there's always a few special ones that require more advanced strategies. I'm talking about those tricky stakeholders like the bully in purchasing who uses bureaucracy to exert control over your project, the marketing representative who's always on a plane to see another customer, the R&D scientist who has a whole new paradigm in mind, the micromanaging resource manager, and the poor soul who would love a root canal so that she doesn't have to work on your project. How do you manage those tricky stakeholders?
Managing the Bully
There's one type of stakeholder that regularly hands you your hat as a project manager and that's the Bully. Many a project manager has fallen by the wayside, simply because they failed to address and effectively deal with the Bully. My worst nemesis was a guy, who we all called “Crazy Chris.” This guy was so tightly wound he could not accept anything less than perfection and often got so close to the edge of his temper that we worker bees would take bets on when he'd completely lose it. I can close my eyes right now I see him standing in front of me, red of face, all but bouncing up and down with aggression, screaming at me that my team could not “read the test procedure.” He was completely focused on having me admit that my team and I were illiterate. Needless to say, I didn't handle that situation well and I've definitely learned a lot about dealing with a bully since then. Today, there aren't as many “Crazy Chris’” around but, there are still people who dominate others through aggressive force of will. To be successful leading a team, all project managers need to have strategies for dealing with this type of stakeholder.
A Bully Stakeholder is frequently the most aggressive person in any confrontational discussion, they exhibit low emotional maturity, are myopic about their solutions, and dismissive of anyone else's viewpoint. You know what I'm talking about here and I don't think I need to spell it out. I'd bet my week's lunch money that each and every one of you has an example of a Bully Stakeholder either in your current project or from one in the not too distant past. The thing you need to understand about bullies is that it's all about winners versus losers for them. If they can intimidate you (and your team by extension) then they “win.” Likewise, in that scenario, you become the “loser.” These folks are definitely keeping score and trust me that score is very important to them. The trick to effectively dealing with these stakeholders is to change the game for them while refraining from putting them in the “loser” position.
So just how do you curtail a Bully and turn them into a collaborative stakeholder?
The first thing you must do is establish a strong first impression. Don't give into their intimidation, don't back down from their aggression, and avoid getting sucked into this ‘winners vs. losers’ game they have going. Maintain your emotional maturity and strive to keep things on a professional level and call a timeout if you think they are too close to the edge to give them a chance to pull it back together privately.
The next thing you have to do is actively utilize your positional authority or subject matter expert status. Remember that for the Bully it's all about winning vs. losing so establishing yourself as a ‘winner’ in their eyes instantly increases their respect for you. Try saying something like this “Ok, Melanie I appreciate your input, and as the project manager responsible for making the schedule commitments for the board team, I am holding to my earlier, 10 January commit.” The key point here is that you emphasize your authority to make the commit and imply that you will take full accountability for meeting that commit. Don't justify your commit; just make it clear that you and you alone own that commit.
This next strategy aligns with the previous two and it is to demonstrate extreme self–confidence. Speak clearly and authoritatively but not loudly. If you're on the phone, stand up; if you're having the discussion in person look the Bully directly in the eye. Any hesitancy on your part will be perceived as a ‘weakness’ by the Bully so it's doubly important to come off as very confident in these situations.
You must be actively and aggressively facilitating any meeting the Bully attends. This will frequently require that you interrupt them and “pull” input from other, more subdued team mates. Make no mistake, this may be very hard for you at first, but by actively facilitating the meeting, you're sending a message to the entire team that everyone's opinion will be heard and considered, not just the Bully's.
This last one is a bit sneaky but I've found that it works brilliantly if done carefully. Give the Bully assignments to produce data that supports their argument. This does two things; first it acknowledges the validity of the Bully's point, thereby allowing them to feel like they've ‘won’, and second it reinforces the concept of data–based decisions. If the Bully has a good point and the data to back it up, then you definitely want the team to execute their way. However, what often happens is that the Bully realizes the flaws in their argument via the process of data collection and the problem resolves itself. Either way you and your team win without having to go through a Death Match to make a decision.
All of these strategies are well and good but don't kid yourself; you just can't change a person that much. However what you can do is change the team dynamic so that they want to collaborate and in that collaboration they see themselves as “winners”. The real trick to dealing with Bullies is to get them to respect you, and then help them get into a position to ‘win’ in their own minds through effective collaboration with the rest of the team.
Managing the Ghost
Ghost stakeholders are as familiar to project managers as they are frustrating. They appear to be ambivalent to the project status, major milestones, quality standards, deliverables, etc. They travel frequently, making it virtually impossible to connect with them live and in person, which makes it extremely difficult to meet with them. They don't return your e–mails in this millennium and they do not see the project as a “high” priority.
The big “tell” for me that I'm dealing with this type of stakeholder is my own frustration with their apparent lack of involvement in the project planning. That's when I know I've got a Ghost on my hands. In general these are nice folks who are easy to get along with. if you can capture their attention for a few precious minutes. Tie the fate of your project to their responsiveness at your peril. They mean well, but make no mistake this is a very challenging stakeholder to manage and you need a specific strategy to deal with them.
So just how do you go about managing this type of stakeholder without irritating the ‘you–know-what' out of them? How do you keep the project execution on track if it's at all tied to this stakeholder's input? Well, here are a few strategies I have refined over the years to deal with the Ghost Stakeholder:
Provide concise, regular status updates in their preferred medium.
Trap them in an abandon conference room and get agreement on their ‘guardrails’ for how far they will let you and your team run without their direct input/knowledge/approval/etc. Be sure that you understand the aspects of the project they care about, decisions they want in on, budget limits, and tolerance for meetings.
Respect these ‘guardrails’ and then leave the stakeholder alone.
Be extremely concise in your direct communication with them.
Double check that this person is the right stakeholder for your project. Perhaps they can delegate that role to someone with more time to support the team.
The key thing to remember about this type of stakeholder is that they really do care about your project…just not as much as you do. Your goal is to limit your project team's dependence on this stakeholder's input, direction, and approval, all while ensuring that the stakeholder remains happy with the team's work. It's also worth noting that you might have made a mistake and this person isn't truly a stakeholder at all! When that happens, have a quick chat with them to confirm that they aren't in the game, then remove them from all meeting invites and e–mail distribution lists.
Managing the Visionary
Another very challenging stakeholder to manage is what I call the Visionary. This is a stakeholder who's got a big picture understanding of the deliverable, but has difficulty communicating that vision to you and your team.
What does this look like in the real world? The requirements are typically vague and high level. This stakeholder is frequently the primary customer who tends to talk about the importance of the project and what the project can enable in the future, rather than the specifics of the deliverables. There's a tendency to dive in and discuss how to start development; often dictating approaches or methodologies to be used. Further, there's often little or no understanding of the security, regulatory, and other established business process implications. The customer clearly sees how to implement their idea and can become impatient with the project team if they don't catch on quickly. Finally, there's a tendency to want to continue playing with or tweaking the deliverables; resulting in projects that just won't end. To a lot of project managers this sounds like a nightmare, but it doesn't have to be.
So, how do you manage key stakeholder's expectations to deliver a product that looks like their ‘big picture’ vision while balancing the triple constraint? Exhibit 1 breaks out specific strategies that can be used to address these challenging stakeholders.
Exhibit 1: Strategies for Managing the Visionary
Two years ago I worked on a proof of concept (POC) project with a customer who was friendly, flexible, and open to my team's ideas. The challenge with this particular customer was that he was exactly that kind of stakeholder I mention above. He had a ‘big picture’ understanding of the project deliverables but struggled with documenting the nuts and bolts of the requirements. As a result, he wanted a very sophisticated proof of concept despite the extremely short development cycle all while dictating the software tools that would be used for the proof of concept work. By using these techniques I was able to successfully manage the project and deliver a tool that met the intent of my customer's ‘big picture’ while adhering to a very tight schedule. Further, because my approach was collaborative and I actively worked to complement the areas he struggled with the project was a positive experience for all involved. The customer now has a very slick POC he can troll out to future customers and I have a very satisfied customer.
Managing the Micromanager
We've all led projects where either our direct manager or another key stakeholder has micromanagement tendencies. This is not only frustrating for the project manager; it also completely undermines their authority. You can re–direct those micromanagement tendencies, or de–fang the monster with a few carefully applied stakeholder management techniques.
First, so that we're all on the same page, let's talk about the characteristics of a micromanaging stakeholder. If you find yourself having to provide project status often and on an ad hoc basis, then you may be the victim of a Micromanager. If you find yourself providing deep dive level details in your regular status updates you might be dealing with one or more Micromanagers. You could also just be over communicating so see the previous discussion for some ideas on how to manage that. If you see your stakeholder providing updates on your team's commitments, then you've probably got a Micromanager on your hands. And finally, the most obvious (and destructive) sign that you are dealing with a Micromanager is when the stakeholder in question goes directly to your team members for updates rather than coming to you, the project manager.
Sound familiar? I thought it might. Luckily there's a pretty simple solution for all of those symptoms. The absolute best way to de–fang the Micromanager is to provide consistent, regular status updates. This sounds a bit naïve doesn't it? Well I'm here to testify that providing concise updates on a regular cadence will eliminate almost all of your headaches for dealing with a micromanaging stakeholder. Let me break this down a bit for you.
When I say “concise” I mean just that. Your status updates need to be at the appropriate level for the intended audience. You may even need to provide more than one format if your stakeholders have significantly different needs. It also needs to be something that the stakeholder can skim and pick up the primary messages of “on track/not on track,” “look Ma we done good/bad,” and “here's how you can help us.” Personally, I prefer the format of a single summary slide per project with a nifty stoplight that tells the audience immediately if things are good, aka green or bad, aka red. At the end of the day, you want to provide information that's relevant and actionable to your stakeholders.
When I say “regular” that's pretty obvious right? One thing I've noticed though is that those Micromanagers are also the ones who are a bit more informal and who don't have a regular forum set up to review project status. If you're dealing with this micromanaging stakeholder scenario, then I'd guess that you aren't required to provide a regular project status. In this case, it's up to you, the project manager, to establish that project status review forum. It can be as simple as an email update you send regularly, or you can set up a standing meeting to go over project status. In general I prefer to do this on a weekly basis, at the end of the week, but the cadence and timing should really be negotiated to meet your micromanaging stakeholder's needs.
This is exactly what happened when I started managing projects for my current boss. He was constantly stopping by my desk to ask for an update or worse yet, going directly to the team members for updates. I suggested/instituted a weekly, 30-minute meeting where the two of us go over the status of all projects in flight. Once my boss got comfortable with the quality of the updates, he stopped those micromanagement tendencies. I think what he really needed to believe was that I knew what was going on and that I was actively managing the work. Today we knock out status for three projects and still have time to discuss strategic actions he wants me to take all within a 30-minute window.
Finally, I know what you're thinking, something like this…“Melanie I'm busy enough as it is! Why should I seek out the time to do another status update that I'm not required to provide?” Hey, I get it; you're busy and this seems like ‘extra’ work right? Well first, it won't take you much time at all. Trust me, you already know that project status off the top of your head and it will only take you 10-15 minutes per project to update a summary slide once you have that template established. Yes it will take an investment of about an hour or so to populate a status slide with your initial project details but you only have to do that once for each project. When you stop to consider how much time you're wasting by responding to all of those ad hoc status requests, the investment of 10 minutes per week on a status slide seems much more reasonable.
How to de–fang the micromanaging stakeholder? Easy, provide project status information that's actionable and at the appropriate level for that stakeholder and provide the status at a predictable cadence that the stakeholder can rely on. If you do these two things, then you can de–fang, tame, and rehabilitate almost any micromanaging stakeholder.
Managing the Prisoner
Almost every project has a Prisoner; it's the person who would rather be getting a weekly root canal than sit in your project meeting. I'm sure I don't need to explain that I'm not talking about orange jumpsuits, scary tats, and the ole bread and water routine here Instead I'm talking about the people who are on your team that really don't want to be there.
First let's talk about the characteristics of the Prisoner. A project Prisoner is often the person least engaged in meetings. They are those silent few who sit slightly separate from the group and commune with their laptops. In virtual meetings they remain utterly silent. The truly hardcore prisoners have given up caring and are frankly just enduring your team and your project. They don't get angry or excited because it just doesn't matter to them. A Prisoner will not volunteer for extra work, even if it's to help out a teammate. The work they do for the project will be at best, merely adequate, and at worst it's late and sloppy. You tend to see a lot of this type of stakeholder on all volunteer teams especially those projects that involve quasi–process improvements. Honestly, it's hard to get excited about yet another ‘solve world hunger’ decision making process even if you are willing to be part of a solution, so imagine how little the Prisoner can care about that kind of project. I'm serious here…they…just…don't…care!
So how do these project Prisoners come to your otherwise amazing team? Well for the most part they get nominated or directed to work with you by a direct manager. No one who voluntarily signs up for a process improvement team is going to be a Prisoner; conversely almost anyone who's told to participate has some level of Prisoner mentality going. There are also those folks who are coasting in their career and they can have that Prisoner mentality too. It doesn't really matter to the project manager what the root cause is; the reality is that you have a Prisoner on your team and you need to manage that stakeholder carefully to avoid tanking your team dynamic early in the project lifecycle.
So now you know what a Prisoner looks like on your project, how do you go about ‘managing’ them?
For some teams at Intel, there's a straightforward strategy for dealing with Prisoners. At the beginning of a new project, the project manager meets with each team member and asks them straight up if they see themselves as a Camper, a Tourist, or a Prisoner on the project. A Camper is someone who's settled in, committed, and ready to work. A Tourist is someone who's curious but not yet convinced that the project is worth their time and effort. Obviously, the Prisoner is someone assigned to the team who really isn't bought into the project or who simply doesn't want to be there. I really like this approach because it drags the elephant out from under the rug in a humorous and non–threatening way. Once you get it on the table that the Prisoner would rather be working at the local stockyards than work on your project, you can both work together to solve the problem. If the project manager lets the Prisoner continue to endure the project, dragging everyone else' morale down with them, then the first step in dealing with a Prisoner is to get the elephant out in the open so you can deal with it.
Once you're eye to eye with the elephant you have to figure out what to do with it. The first and most obvious tactic to consider is whether or not you can get them off your project, peaceably. Sometimes this is as simple as meeting with the Prisoner's direct manager to see if there's a different resource that's a better fit. If you can pull off getting the Prisoner reassigned without damaging their reputation with their manager, then you look like a hero and everyone wins, including the Prisoner.
Okay we all know life isn't always that easy so let's say that both you and your Prisoner are stuck on the project. A really good tactic to employ is to assign them work they can reasonably get done. Don't even think about expecting them to do anything outside of their perceived job description because that's just asking for trouble. If at all possible, try to configure the work around the Prisoner's areas of expertise or whatever they are passionate about. For instance if you've got a Prisoner who's passionate about compliance and doing the right thing, then they might be a good candidate for coordinating the legal and security reviews that need to happen. If you can tap into something they care about and feel is important, then you have a decent chance of breaking them out of their prison.
Another tactic you should consider…and I can't believe I'm saying this…is to just let them be. If you've tried to get them reassigned to no avail and there's no way to assign them work around their passions, then your best bet might just be to let it go and focus on other more urgent things. If the Prisoner is quietly doing their work and not disrupting the team dynamic, then don't create a problem you can't solve. You're not off the hook for continuing to try to motivate and inspire them as part of your team, just realize that you might not win that one.
Some of you are probably wondering what you should do with the Project Prisoner who frankly, needs to be kicked off the team. They aren't team players and they just suck the joy out of the room every time they walk in the door. They don't want to be there and by golly, everyone's gonna know about it. To be honest this isn't the norm and it's rare that a project manager will need to get serious about removing a resource. If you do have to go down this road, there are a couple of things to bear in mind. First, have you done all you can to turn this person and the situation around? Second, does the Prisoner realize your next steps will involve escalations to their manager? Third, do you have specific, documented evidence that the Prisoner is not meeting their commitments? As I mentioned, this is a rare occurrence but don't take it lightly. You're messing with someone's career and livelihood so make sure you've got the facts to back up your request that they be removed from the team. Not quite comfortable taking this step? Well to be blunt, suck it up! The rest of your team is counting on you to address the problem in a timely manner. Remember that you are the team leader and you have a commitment to each member to provide an environment that is conducive to getting the work done. It's pretty simple to “fix” this problem for both your team and the Prisoner with a little effort. Just remember the worst thing you can do is ignore the elephant under the rug and hope it will go away on its own.
Conclusion
Managing stakeholders can be challenging and you need a structured, deliberate plan for how to do it. Determining a deliberate plan is straightforward and reasonably quick to accomplish. Automating the plan creates a self–sustaining system that ensures you are reaching out to all of your stakeholders regularly. Taking control of the conversation and ensuring that the data you share is actionable to your stakeholders will go a long way to helping them feel that the project is under control. These are the basics of managing stakeholders.
However, there will always be tricky stakeholders that require the project manager to pull out a different tool from their stakeholder toolbox. In this paper I have discussed specific tactics for dealing with some of these tricky stakeholders. For the Bully the project manager must balance the other person's need to win against the team dynamic. The Ghost is best managed by setting guardrails for communication and interaction. The Visionary needs the project manager and the team to lay out the concrete work that must be done. The Micromanager must have their need to feel in control fed by regular updates. Finally, the Prisoner is best managed by accepting their lack of motivation and positioning them to do their best work.
All project managers deal with their stakeholders' expectations. Some merely muddle through the process relying on charisma and charm; these are the good project managers. Others, the great ones, have a focused strategy that uniquely addresses the needs and desires of each of their stakeholders. This paper has outlined specific steps to move any project manager from merely good to great by employing a deliberate stakeholder management strategy.
https://www.pmi.org/learning/library/basic-stakeholder-management-relationship-techniques-6082