Managing project stakeholder expectations

In this episode of Workflow, Brian and Tom talk about how to manage project stakeholder expectations.

00:42  What’s happening at Rindle (NFL viewer user experience, NY Air Show)
05:44  What is a stakeholder?
09:20  Things to do for managing stakeholder expectations
26:02  Things not to do for managing stakeholder expectations
32:59  Tips for taking action

Recording: 00:00 This is Workflow Episode 12. Workflow is the podcast that helps teams figure out the best way to work, collaborate, and get stuff done. Brought to you by Rindle.

Brian: 00:28 Hey everyone. I'm Brian.

Tom: 00:29 And I'm Tom.

Brian: 00:30 We're the co-founders of Rindle, and this is our podcast Workflow. Today we're talking about managing stakeholder expectations. Before we get into that, Tom, what's happening at Rindle or on a personal note?

Tom: 00:42 Not too much, a pretty easy weekend. I watched the Giants game last night. Watched them lose, unfortunately. They're not looking too hot, but I thought of a interesting potential, even topic, maybe for the podcast at some point, but the NFL viewer user experience, if you will. I noticed that they seem to be doing a lot more on the screen augmented reality type stuff. Pretty interesting. I think some is good, some is not so good. Yeah, I think they're definitely trying out a whole bunch of new stuff this year, more than I've seen in the past.

Brian: 01:22 Yeah. I noticed a bunch of things myself, and I agree that the Giants are not looking that great. Yeah, I definitely noticed a couple things going on, and I don't mind some of it. Some of it is helpful, and some of it seems to be a little over the top, but-

Tom: 01:36 Yeah.

Brian: 01:36 I also noticed that even the first down line, where they've shown that for a number of years now at this point, but now it's almost regardless of the camera angle-

Tom: 01:47 Sure.

Brian: 01:48 [crosstalk 00:01:48] It's like a closeup of one of the players now. And, it just looks funny because it's kind of floating in the background, not in normal context of a down about to be played.

Tom: 01:59 Yeah.

Brian: 02:00 So you could see where they're headed. So, that I noticed this year too.

Tom: 02:04 Yeah, yeah. They have that line. They have the line of scrimmage line that's in every shot, even closeups. I agree with that, actually. That's where I thought it looked a little funny actually. But, also just the different camera angles that they're really pushing for like the Madden view. I just don't like it. And, I don't know why they're trying so hard to make people like that. Seems like they're showing a lot more plays with that.

Brian: 02:31 Maybe just showing your age and you're not a Madden gamer.

Tom: 02:34 Maybe that is it. Yeah, I don't think I've played Madden in a number of years So ... What about you? What happened with you over the weekend?

Brian: 02:44 Oh, not much. We did go to the New York Air Show, which we've been to once before. We skipped last year, but we checked it out again this year. My son tends to like things that fly in the air in general. So, yeah. It was really hot, which was unexpected.

Tom: 03:01 It was hot yesterday.

Brian: 03:02 Yeah. Just, you expect more fall weather, and it just happened to be probably one of the hottest days we've had in September. But, that made it a little more challenging. My wife is pretty far along in pregnancy, so she was there-

Tom: 03:19 Yeah.

Brian: 03:21 And, so that was a whole mess. But, the parking was crazy. It was just really far away. It's at Stewart Airport in New York and they have shuttles and buses going all over the place, and it's craziness. And, by the time you get there, we weren't prepared with umbrellas and other things that you're allowed to bring in, not thinking it was going to be that hot. But, it actually was. So, you're basically sitting on a air strip with no shade or anything like that so it was pretty miserable. Lot of sweat. But, the Thunder birds are pretty cool and they had some other stunt airplanes and other stuff like that, so my son really enjoyed it. After the initial takeoff of the Thunder birds we were right by the takeoff area and there were five of them, or six of them took off literally at the same time. And the sound was ... I mean, it scared me.

Tom: 04:16 Is it really loud?

Brian: 04:17 I mean, it rattled my whole body. And, of course my son, we had headphones on him to protect his ears and stuff, but that was so loud that he started crying. But, after he got over that one, he was loving the jets. Even though they're still oud flying around you and stuff, but nothing like that initial takeoff because we happen to be standing right by where they took off. So, usually down the strip they'll be already in the air so it's not as low-

Tom: 04:42 Mm-hmm (affirmative)-

Brian: 04:43 So, it just happened to be where we were standing. So, I was like, "Oh, no. This is going to be a nightmare." But, in the end he was fine, and adjusted and was loving it.

Tom: 04:53 Do they go over the Sonic Boom? Do they make a sonic boom?

Brian: 04:57 Yes. There's a couple times and they will ... Yeah. It's pretty crazy.

Tom: 05:02 That's crazy.

Brian: 05:03 And, they do a bunch of stunts and tricks. They're so fast and they do things on purpose to make you look one way and there's another jet flying over you, like real low over your head and it scares you and stuff. So, yeah. It's fun. It's fun.

Tom: 05:16 Before we get started, if you have any questions, comments, topics, team scenarios, or anything at all that you want us to talk about or tear down, shoot us a phone call our voicemail is 860-577- 2293 or you can email us at workflow@rindle.com.

Brian: 05:35 Yeah. And also, please leave a review. It helps us reach more people. Whatever you're using, like iTunes, love a review if you're liking what you're hearing.

Tom: 05:44 So, the main topic: Managing stakeholder expectations. So, I think the best way to start this off is to talk about what is a stakeholder?

Brian: 05:53 Yeah. And, I think we're going to keep this probably not as technical. But, stakeholder's the best way to kind of describe what we're talking about as far as expectations and dealing with different stakeholders within a project or whatever it is you're working on. But, a stakeholder is either an individual, group, or organization who is impacted by the outcome of the project. So, they have some kind of interest in the success of the project, and can be within your organization or outside your organization. Then basically they have ... They're sponsoring it or they're involved in some way in the project.

Tom: 06:26 So, if you work at an agency most commonly it will probably be the customer?

Brian: 06:30 Yeah. I think in any kind of ... definitely in any kind of customer driven environment like an agency or any kind of service organization your customer is probably going to be the main stakeholder that you're dealing with more than others. But, I think there generally always are other stakeholders. So, even at an agency of your customer, but then you have an account manager, maybe as a PM you're working with the account manager that's also a stakeholder, right? They have a stake in that project being successful on behalf of their client, right? And you might have even stakeholders between departments, right?

Brian: 07:02 So, you have a creative aspect of a project and you have development aspect of a project, and those become stakeholders in a project. So, I think it gets much deeper than that. But, yeah, I think the most common definitely is a customer.

Tom: 07:14 Cool. Yeah. Another example might be if you are setting up an event. The sponsors of the event are stakeholders.

Brian: 07:23 Yeah. And, I think we don't think about that a lot of times. We think about the players and what's going on. But, especially if you're not necessarily a formal PM, let's say, or maybe you're just in charge of a project, or every now and then you're in charge of projects. You don't necessarily think of people as stakeholders.

Tom: 07:38 Sure.

Brian: 07:38 You know who's involved, but actually, I think putting some thought into it is interesting to because you really understand well, who's involved and why, and really the scope of what you're managing as the leader or project manager of a project.

Tom: 07:53 Yeah. And, I think there are some unique examples where people are stakeholders that you might not think are stakeholders. We've talked about previously, even rolling out software into your company, and the stakeholders in the scenario are the employees, or the departments that you're rolling it out into.

Brian: 08:17 Absolutely. And, it's interesting because sometimes even in that scenario, but stakeholders typically don't work directly under you, from a hierarchy aspect. So, generally, they're harder to manage. So, a customer is a great example. They don't work under you. They don't report to you. They're external.

Brian: 08:36 Sometimes it's a senior management. Again, they don't report to you. You actually report to them. So, managing those relationships and managing the stakeholders in a project that has deliverables and due dates and all these other things really is a challenge, because you have to handle that relationship in a unique way. It's not as easy as somebody who maybe directly reports to you. It's like, "Well, let's just get done this way, and get to work." You have to handle it with a lot more care.

Tom: 09:04 Yeah. So to, break this out further, to help you manage stakeholders in your project, whatever it is you might be doing, we put together a list of things you should be doing to help with that process, and also some things you shouldn't be doing, that's probably not helping the managing of your stakeholders.

Tom: 09:20 So, as far as things to do, identifying the stakeholders is first. So, this provides clarity for everyone on the project. So, the stakeholders, non-stakeholders, everybody, who are the stakeholders? Is there a customer involved? Are there managers involved, other departments? Who is actually involved? Taking the time to actually identify that is key. There probably are more stakeholders than you think. Because a lot of people think if there's a customer involved, "Well, that's the main stakeholder." And, you don't put much thought into anything else.

Brian: 09:50 I think that's a good point. So, there can be primary stakeholders, and then secondary stakeholders too, to just about any project.

Tom: 09:58 Yeah. And also communicating them amongst the team too. For different reasons, whatever they might be, you might want to communicate this different stakeholders to the different people involved in the project, so everybody does know, not just you. So, there might be advantage to doing that.

Brian: 10:13 So, the second point is you want to define what makes the project successful clearly before the project begins. So, I would even go as far as to ... You should write it down, right? In order for this project to be successful, we need to accomplish this. You don't want to be vague, you don't want it to be too broad. You want it to be very specific in actionable.

Tom: 10:35 Yeah. I think this is harder than it looks. I've always had trouble doing this too. Because a lot of times we have grander scopes in mind. Like, "Oh, yeah. We are creating a website." That's obviously a deliverable. But, making a broad statement like that can mean many things. A website can be many things, right?

Tom: 10:53 Or any type of product. It could be an event you're setting up. It could be ... Whatever it is. In order for the project to be successful, we need to set up the event. What does that mean, exactly? What kind of event? How many people is it holding? How many different types of tickets will be sold? Will there be booths? All of these things are questions, right? Which, if you don't clearly define what makes a project successful, then you end up in the a lot of problems, like scope creep and unhappy stakeholders and all these things. But, I do think it's harder than it looks. What do you actually outline for a website, right? What are the exact [inaudible 00:11:35]? You have to do your homework with the stakeholder to really understand, "Well, what is the purpose of creating this website, and what are we trying to achieve by doing that"? And, a lot of those benefits might be very general, that we kind of just assume. And, others are very specific. We want to be able to take job applications from the website. That's very specific. And, that's really easy to measure.

Brian: 11:56 Sure.

Tom: 11:56 So, you want to get all of those measurable things in a row and even some of the things that might be assumed, make sure you write down and document to where everybody's on the same page as to what makes this project successful.

Brian: 12:08 Sure. Yeah. So, I think the key take away there is you need something measurable in order to define what makes it successful. So, taking job applications, that's pretty straight forward as long as there is a mechanism for taking job applications it can be successful, but maybe for website it might not be that clear so a goal like, "We want to increase time on page." That could be the overall goal that is ... Determines the success of the project. Or, if you are setting up an event, like, "We want more vendors than there were last year, and we more visitors to the event than there were the previous year." Those could be things that you define in order to say, " Hey, if we hit these goals, the project was a success."

Tom: 13:03 Yeah ... Hey, if we hit these goals the project was a success.

Brian: 13:03 Yeah, you probably want to outline too what are you doing in that project to accomplish those goals? So because there are many different things. Something like increasing vendor account could involve marketing and advertising, right? It could involve trial and error, it could involve a whole nother project if you will. So you want to definitely say, "Hey, these are the things we're going to do to improve vendor count, and you're going to measure it," right? And make sure they understand the expected outcome versus what's possible versus what may require additional effort. And that's why I think a lot of times it is very hard to actually document this because even something as simple as that, like a job application form, is very easy to measure. Somebody can go to the site, they fill out the form, they submit it, it works, they received the application, right?

Brian: 13:48 That is done, that it should meet everybody's expectations. But when you talk about something like, improve SEO or increased vendor account, how do you measure that and what are you doing actually to increase that? And that could be a trial and error thing where, "Hey, we're going to do these three things. It could increase it, it could not, we don't know how much, we're going to measure it and then possibly iterate." So just be careful of those situations too. How you're presenting that, how you're capturing that goal and are you doing certain things now? And then if that doesn't work for you to do certain things later, all of those things kind of come into play.

Tom: 14:21 Also, if the project is larger, and you do have multiple stakeholders, even multiple different primary and secondary stakeholders, the project's success could be different for each of those people. Hopefully, it's not drastically different because the project might just be really too large at that point, but it could be different.

Brian: 14:42 Absolutely. Yeah. And that's good to note. Also, will drive how you communicate to people as well. You're not wasting people's time and communicating the wrong thing to different people, and if they don't care about that measure or that stat, whatever it might be. Communicate what they care about. Cool. So another point is don't make stakeholders wait too long before they start to see value. So my whole thing has always been share. Share quickly and often similar to very iterative or agile methods out there where you kind of want to move fast, share quickly, get feedback early. The more time typically there it goes without no value being shown the more questions typically arise in my experience. So the alarms start to go off in the stakeholders head like, "Wow, haven't heard from Brian and a couple of weeks that's strange."

Brian: 15:33 And now they start kind of being, getting concerned, start raising questions. Now, when they look at things that you're delivering, potentially they're going to look a little closer eye potentially. Now, they're starting to say, "Oh, did it took two weeks to do this? That's strange. That seems a long time." So that if you share quickly and often it kind of eliminates all those questions. It keeps everybody in the loop often, and you get that early feedback and everybody kind of knows how the work's flowing and what's progressing on a kind of shorter timeframe.

Tom: 16:04 I think the easiest way to tackle this is actually just to schedule check-ins on a regular interval. Obviously, again, the more stakeholders and the more important the stakeholders are, the harder that will be but even if you schedule a monthly check-in if it's like a really long project, just to keep them abreast of what's happening.

Brian: 16:27 Yep. And it will be a different cadence probably for different stakeholders, so in an agency environment, it might be every week with the account manager because they're the liaison between you and the client potentially. And then it's every month with the customer like you said. So yeah, definitely, and probably different cadences for different situations with different stakeholders.

Tom: 16:46 All right. The next point is to execute against the objective to ensure project success. So you want to manage scope creep, and you want to be sure not to under-deliver. You should always, I think the saying is under promise over deliver.

Brian: 17:03 Yeah. And I think that's a tough thing to do generally when you do have a scope involved, and you do have a kind of defined set of whatever the project deliverables consist of, it's easy to kind of overdo it and increase the scope without knowing it and then having a whole other budget and time issues on your hand. But generally, you also want to be sure not to under-deliver and underwhelm the stakeholder because now they're going to be like, "Well, boy, I feel kind of like we didn't get what we asked for." If you can over deliver within the scope, that's definitely the best scenario. So if you can find quick, easy wins that will make the stakeholders happy for whatever various reasons. That's like the best scenario possible because you keep everything within scope and within the means of the project, but you kind of delight them beyond what they expected.

Tom: 17:55 I think this can be a real sign of an experienced agency if we use an agency as an example versus an inexperienced agency because if you work with an agency a lot, you notice that they constantly are overpromising and under-delivering. It's most likely that they don't have the right resources in place to properly quote things out and that they are biting off more than they could chew, more or less. An example of this ad agency might be that you underestimate the length of time it takes to get various things done. And then when the client accepts your offer, you end up not being able to even get all that you promised on in that timeline, let, alone any extra polish. And that typically is really a problem, right? The client's then going to be less likely to use you in the future. They're going to be just generally unhappy, right? Especially if you leave them in a fairly incomplete state.

Brian: 18:59 Yeah. I think experience those come into play too, like when you're estimating timelines and different things for different projects, right? If you have an experienced team kind of understanding really what it's going to take, you should be able to give a reasonable timeline, and hopefully give yourself room to over deliver. I think another example is even a manufacturing company if you're manufacturing product for a customer, and you've estimated two months for the whole process, and you deliver a week early and that was kind of built in, but to the customer, they're getting something a week early. No extra cost to you, as a manufacturer, but you actually over delivered within the same scope because you were able to deliver a week early. Right?

Brian: 19:35 And those are the kinds of things that really is the magic, right, where you can keep everything within scope, within budget. But something like delivering a week early could make the customer very happy. Same thing with an agency, right? We say the landing page is going to take six weeks to do and we deliver in five weeks. "Wow. You guys are amazing." Obviously, that can get out of hand if you start saying, "Well, yeah, it'll take six months." Right? And then Catherine was like, "Well, that's crazy. I can't wait six months." Right? But if you have enough experience to really understand what things take, you can almost be smart about how to manage those things to kind of build in some over deliver possibilities.

Brian: 20:10 So, the next one is keep it simple when communicating with project stakeholders. I think especially if you work at a technical area, it's easy to kind of over complicate things with more technical language or kind of talk over their head because you're trying to explain what's going on, but to them, they're hiring you for a reason. Mostly because they don't do what you do. So you have to be sure to break things down, so in layman's terms so everybody can understand it and be very consistent with that because I've seen it cause a lot of frustration on the stakeholder side, especially when you talk to customers.

Brian: 20:45 They get defensive, they don't feel secure because it basically makes them feel lesser than you, right. Because you're almost like you're talking down to them because they don't understand what you're talking about because we're using a bunch of technical jargon. So you have to be really careful to kind of speak their language, make sure they understand things and be consistent about that. So they feel comfortable and they're in the loop with you and right along with you. And they don't feel kind of under you or inadequate or, "I really don't understand what's going on, but I trust him." You don't want that scenario to happen.

Tom: 21:16 Sure, yeah. This is especially the case if they are questioning something, you don't want to start being super defensive because then they are going to get defensive or they're going ... It's just going to be a bad situation. So you definitely just want to use a common language, simple, easy to understand language and don't, yeah, just don't over complicate things.

Brian: 21:46 Yeah. And sometimes you can't avoid some of the technical conversation, and I've had situations where I don't want to offend them either where it's like, "Well, oh, you're just assuming, I don't know that." Right. But what gives you the right? So I will ask sometimes be like, "Oh, do you know x, Y, and Z?" And they'll be like, "Actually I don't know much about it." Okay. And then I will then have the power to break it down into more common language. Sometimes they've been drawing simple pictures to explain something. But you don't want to necessarily go right to the picture drawing if they're like, "Yeah, hello, I definitely understand that. You just kind of insulted me a little bit." So again, it comes to a fine line of managing the stakeholder to understand who are they, what background do they have, what knowledge do they have, do they understand what you're talking about or not?

New Speaker: 22:31 I mean I've had more technical stakeholders that I can speak freely with, and they might even know more than I know, right, which is awesome. And then there're times when I've had no technical background at all and I kind of know right off the bat that I have to explain generally anything or everything that has any kind of technical bearings. So it's all in kind of understanding who you're dealing with and how to manage it properly.

Tom: 22:56 Awesome. So the last point I think we want to make is you need to prioritize your stakeholders. Some stakeholders are definitely going to be more valuable than others, and some will demand more attention than others. The first point that some are more valuable than this actually might not be as easy to determine right away as you might think, depending on who's taking ownership of that project within the company. Very often the person that you talk to the most, it might actually be the most valuable person, or it might not be. But even if the person is very high up, they might not necessarily be the most valuable.

Tom: 23:47 Yeah, I think it's really, it's sometimes easy to understand the customer obviously, probably has the most weight as a stakeholder at an agency or any kind of service driven examples that we've given and that's easy to understand sometimes and then prioritizing for them might be a little more challenging.

Brian: 24:05 I know in my experience at the agency it would be customer then account manager then kind of my boss would probably be the normal pecking order and then any internal stakeholders as far as department heads or anything like that. But understanding the value as far as who's the most valuable, who deserves the most attention because of that ranking? And making sure that that most valuable stakeholder's taken care of and maybe gets more of your attention more of your time and then it kind of trickles down from there. That's really more of a time management thing than anything sometimes because sometimes as a PM or anybody dealing with a bunch of stakeholders, it's time, right? If you gave everybody the same amount of time, and you have a bunch of stakeholders on a project, you know you're going to be, and you have multiple projects going on, you're going to be strapped for a bunch of time.

Tom: 24:51 But you also don't just want to ignore someone just because you don't think they're a valuable stakeholder.

Brian: 24:56 Oh, of course, not, but maybe that stakeholder of less value only needs to be checked in on once a month and needs one status report of X nature. Right? That's all they really care about. Instead of trying to contact them every week or every day and giving them an update, which they don't really need or want by prioritizing them, you're also prioritizing your time in that way. So yeah, I mean and if they deserve more time, or they have more value than they'll be hopefully further up on your ranking system. Right? So you will give them the attention that they need.

Brian: 25:28 For example, Tom, you and I, working together at the agency you were the head of development. I was a head of project management. I dealt a lot with the clients you didn't necessarily. Right. So you were a secondary stakeholder for me, but my primaries were definitely the customer, and the account manager because I dealt with them on a daily basis. I dealt with you only in certain scenarios. Right? So not that you weren't important, but you are less important than the customer per se. Right? So as far as giving an update, I would give an update to the customer first and then probably do a secondary update when we met once a week when we had our status updates internally. Alright, great. So let's talk about things ...

Tom: 26:00 Or status updates internally.

Brian: 26:02 All right, great. So let's talk about things not to do. One of them is identifying and prioritizing the wrong stakeholders. So I have personal experience with this. I had a client where it turns out their boss was actually being looped in internally and we didn't realize it. And I thought my main point of contact was the person I was dealing with, which was the case, but the whole time he had somebody above him making all the decisions and approvals. So when it came down to actually delivering the final product, we have a huge problem because that stakeholder, which I failed to identify in the beginning of the project basically said, "Hey, actually this is all wrong, or these things are now wrong." And we're like, "ait a minute, you've been approving this the whole time, what's the issue?" And somebody else kind of comes in at the final hour and changes their mind. So it's really important to kind of identify and prioritize the right stakeholders upfront so you don't fall that kind of trap.

Tom: 26:57 How did you rectify that situation?

Brian: 26:59 Well, in the end the customer is always right. But in the end, we did essentially do a change order, because the customer did realize that, "hey, partly my fault, I didn't really loop you into everything that was going on." And so we kind of compromised with a change order which covered some of our additional costs to make the changes, and everybody was happy. So kind of put out a fire there. But obviously if you're can avoid that situation, that's the best case.

Tom: 27:25 So the next thing not to do is don't over promise ever, which it sounds like this could be easy to do, but it's really tricky because you basically want to obviously promise enough to win the work if you're like an agency, but not promise too much, especially in whatever time period or whatever budget that you have to deliver by.

Brian: 27:52 Yeah, 9 times out of 10, you end up under delivering in the end, even though you think you're doing what's right by promising, because it's kind of like the quick fix. It's like the instant rush. It's like, "Yes, we can do that." And the customer is like, "Great. This is amazing and the project's going to be amazing and we're going to get exactly we wanted." And you've over promised and in the end you will end up under-delivering, underwhelming the customer, there being more issues than needed. It's just not worth it in the end. It's better to be kind of upfront and make sure the scope is intact, the budget's intact for what you're actually delivering.

Brian: 28:23 The other third point here is don't panic. So when you're calm, you're team is generally calm. Your stakeholders are calm. I've seen people where it looks like there's a fire going somewhere, right? They're running around, they're crazy. They're anxious and panicking about kind of how to deal with something. I think part of being a leader of a project, or a PM, or whatever the scenario might, be is remaining calm and focusing on the solution and not so much, "Wow, this really stinks. Like I have to now go talk to the client and have this tough conversation." That's gonna happen. SO you got to just remain calm, focus on the solution, come up with the plan of action that will avoid your team and your stakeholders going into panic mode. You do not want your stakeholders, especially your key stakeholders kind of coming at you with panic and causing you more headaches, right? So the calmer you are, the smoother everything will kind of roll.

Tom: 29:19 And the last point is don't avoid communicating the inevitable. So if you have an issue, immediately communicate it. If there's going to be delay or potentially a change and you're going to require a change in budget, you want to communicate that as early as possible to the customer. They're often difficult conversations to have, but you'll find that if you communicate early and often, it's better than them being overwhelmed at the end by some change order or, or not getting what they expected.

Brian: 29:57 Yeah. It's like ripping the bandaid off, you know, you just got to do it. It's better to just rip the bandaid off and have a little scream.

Tom: 30:04 Bite the bullet, right?

Brian: 30:05 Yeah, bite the bullet, than kind of like avoiding it, which I think a lot of people do because it's easier to avoid sometimes. and you're kind of trying to think of like, "Well I wonder if there's another way around this so I don't have to have this conversation/ Maybe if I let it go another week we can catch up or maybe we can fix it in the backend?"

Tom: 30:25 Yeah, and you're just digging yourself in deeper typically.

Brian: 30:28 [crosstalk 00:30:28] Exactly. And then, you know, I've been in situations where I myself have done this, and especially early on my career when I wasn't as experienced, but I've had other people in my team where it ends up going two, three weeks in, and then it becomes an issue about, "Why didn't you tell me about this three weeks ago? We could have dealt with this." And a lot of times the problem, or the solution to the problem is actually not a big deal. In that scenario, you've made it worse. Now the client doesn't trust you, or whoever your stakeholder is, the trust value goes away. And they're kind of like, "Well, that really ... You're not a really good communicator. You kind of let this go two, three weeks out of hand."

Brian: 31:06 And you know, in the end we could have fixed this with one little conversation and the stakeholder wouldn't have been upset. So it's just not worth it. It's better just to face it. And that's something that I learned the hard way just early on in my career, but became an asset in my project management skills just because I was generally the type of person who'd be like, "Okay, let's get on with the stakeholder or the customer, whoever it might be. Let's get on the phone with them right now and talk about it." And just deal with it head on and just move on. Again, stay calm, deal with it, move on, come up with a solution. In the end, the whole goal is to get the project done for everybody. So it's everybody should be on the same team.

Tom: 31:44 Yeah. I feel like this is a very typical thing that project managers, this is basically a big part of their job. They have to identify problems and help think of solutions. But very often, the solution can't just be thought of by the project manager. They need to run it up the chain of command, if you will, which is the client or whoever the stakeholders are, and come up with a solution with them. Because if it's a time issue, "Hey, okay, well the time is the time," right? We can't extend it if there's a hard deadline, then, "Hey, well can we cut anything out? How can we make up this time?"

Brian: 32:23 Yeah, very seldom does any plan play out exactly as you expected it to. And, and that's on the delivery side and on the stakeholder side, or the customer side. So, I mean I think this is something that we should all expect is really how you manage it, and how you manage expectations, like this whole episode is about. Managing expectations and not letting things get out of control. Most of the time what you initially set out to do will change for various reasons and these tips will help things run a little smoother and avoid issues that are not necessary.

Tom: 32:59 So let's talk about tips for taking action.

Brian: 33:03 Cool. Yeah, think one main thing here, one takeaway for me is that, creating a stakeholder communication plan, if you will, of sorts. I'm not, and we are not fans of tons of documentation or unnecessary documentation, but informally, it just might be helpful to write down all the stakeholders that are part of the project, and if not just a document for yourself to reference back, but also to make you think about, " Hey, did identify everybody? Am I really taking account all the players of this project?" So it will force you to think about it, but also document it so you can refer back to it.

Brian: 33:39 And part of identifying those stakeholders also involves identifying their needs and interests. So if a stakeholder is concerned about meeting delivery date and that's a huge concern of theirs, you can jot that down and be aware of that and make sure you be on top of the timeline discretions with that particular stakeholder, because that's their main concern. So various stakeholders will have different concerns. If you're aware of those, document them, kind of write it down and make that part of your focus. It just makes your communication a lot clearer and more streamlined.

Tom: 34:11 And then the last tip for taking action is, and I think it's a fairly easy one, is to establish a communication cadence early and stick to that. And then on top of just doing that, establish how you're going to communicate. Is it going to be over the phone? Is it going to be email, Slack, in-person meeting? Set that up, stick to it. Should be easy to do. And if you stick to that cadence, I think you'll find that things go fairly smoothly.

Brian: 34:43 Yeah. I think asking stakeholders how they want to be communicated with is important. I've had customers who really just talk, and this is probably dating myself a little bit, but they only want to talk on the phone. They did not like email, they did not obviously like text message or anything like that. And then I've had customers who only wanted to meet in person. That was just how they rolled. And they expected when there's something communicate, we set a meeting, we go there and we present what we have to present.So it's important to understand what they expect and what makes their life easier as well so you're not constantly communicating in a way that's just irritating and not getting the point across or maybe even being dropped.

Brian: 35:24 And then the cadence, the same thing, right? Like the cadence could be different for different stakeholders. Maybe your key stakeholder wants to meet every week, maybe the secondary or lower tiers stakeholders only requires a meeting every month. So establishing that kind of upfront will at least allow you to create that cadence, I guess, ahead of time.

Brian: 35:40 Well, I think that about wraps us up for the day. If you have a question for us, you can call it into our voicemail number at 860-577-2293. Or you can email it to us at workflow@rindle.com. Our theme music is an excerpt from Thunder Rock by Magic Studio used under creative commons. Subscribe to us on iTunes by searching for Workflow and visit rindle.com/workflow-podcast for a full transcript of each episode. Thanks for listening and we'll see you next time.