We all know communication is a massively important part of our project manager role. But what are the tools we can use to be better at it? One of them is a communications plan. Ben talks to Natalie about how you can use a communication plan to manage expectations better – keep listening to find out how you can stop clients badgering you for information, and get the things you need from your clients!
This podcast is part of an article published on The Digital Project Manager.
You can read the article here.
Read The Transcript:
We’re trying out transcribing our podcasts using a software program. Please forgive any typos as the bot isn’t correct 100% of the time.
Ben Aston: Thanks for tuning in. I’m Ben Aston and this is the Digital Project Manager Podcast. Today I’m joined by Natalie Semczuk, one of our resident DPM experts at the Digital Project Manager. Natalie, thanks so much for coming on the show again. We’re welcoming Natalie back, I think, for the third time.
Natalie Semczuk: Hello, nice to be here.
Ben Aston: Today we’re talking about communication. We all know that communication is a really important part of our role, but what are the tools that we can use to be better at it? One of those tools is a communications plan. If you’ve ever found that your clients are constantly harassing you for information or vice versa, it might be that maybe you’re the one harassing them for information and it’s all getting a bit awkward, then you’re in luck because we’ve got a tool that we’re going to talk about today that can help fix all that. It’s the communication plan, but first let me talk about Natalie. Well, let me introduce her properly.
Natalie is a digital project manager who’s actually just gone full-time. This is a big deal for Natalie. She’s a remote project manager in Arizona and was doing freelance gigs but now has gone full-time. She also has her own newsletter, which you should check out, DPMish, and her PM reactions blog, so check all those out.
As one of our DPM experts, Natalie is also going to be making an appearance in our upcoming course “Mastering Digital Project Management.” If you’re not sure what I’m talking about but you know you need some PM training, go and check it out. It’s a seven-week crash course and it includes some interactive video lessons, assignments, group discussions, and webinars. There’s also the option of coaching sessions as well, so head to digitalprojectmanagerschool.com and get yourself signed up. You’ll find Natalie on there.
Natalie, tell us about … Actually, the first thing I want to ask you about is your DPMish newsletter. We haven’t received one for months. What happened?
Natalie Semczuk: Oh, man. I was worried I would be called out on this. As you mentioned, I recently took a full-time job. I kind of was taking a break after the holidays to revamp the newsletter, kind of put a longer term plan in place for the kind of content and topics we wanted to cover, guest editors and things like that. In the midst of all of that, I got a full-time job, so kind of between that and the freelance that I still take on in small amounts on the side and just getting used to everything, it’s taken a little longer to get that plan in place, but I promise a new DPMish will be coming out soon. We actually just passed the one year mark of it existing, so I definitely want to keep that going.
Ben Aston: Oh, congratulations.
Natalie Semczuk: Well, thank you.
Ben Aston: Good stuff. Tell me. I’m interested, though, because you were one of our, I feel like, one of the poster childs for remote freelance PMing, so now with your transition to full-time role, what kind of made you decide to take the leap or the plunge back into … yeah, away from freedom and back to being tethered?
Natalie Semczuk: No, so, you know, I still work remotely, which I super love. It definitely gives me the sense of freedom too in terms of, you know, I’m literally wearing pajama bottoms right now and no one would’ve known if I hadn’t said that. I freelanced for five years full-time and I was starting to feel … When I started, I was pretty junior. I spent a long time learning the ropes and taking risks kind of on the projects I was working on. I just felt like it was time to challenge myself a little more.
I love what I do, freelancing. I loved it. It was really fun, but I was also starting to get kind of burned out with the one-project contracts, which were kind of how a lot of agencies do things, you know? They need relief on a project, you get a project, and then you’re in and out. I was just getting a little bit frustrated that when I worked with such great teams or a new process, I couldn’t really contribute in a lasting way other than just on my project. The successful relationships I’ve had freelancing that I’ve enjoyed the most have been longer term, so I just wanted to start thinking more about that and exploring the chance to maybe … almost take a breather and focus on my own development as well as investing in a team.
Ben Aston: Cool. So, what kind of projects or agency kind of lured you into full-time, then? What are you working on right now?
Natalie Semczuk: Yeah, so that’s actually kind of interesting. In the past when I freelanced, I would do a lot of projects, start-to-finish building, so redesign, development, launching a site. The current position I’m in is more like post-launch project management, maintenance support. I really love it. I spent the last few years specifically giving talks on sort of post-launch maintenance, how to build a site with that kind of thing in mind, thinking about how the client’s going to use the content that we’re giving them on the site, all of the sort of modules or fields or things like that in the back end. That’s sort of exactly what I’m doing now, so I help transition projects from build projects into that post-launch maintenance phase. We kind of take on any additional features that didn’t make it into phase one, so I’m actually, you know, the mystical phase two.
Ben Aston: The phase two’s actually happening?
Natalie Semczuk: Yeah, yeah, it actually exists, come to find out. Who knew? But no, I really love it. It’s been great because it’s a really cool way to get to know a client longer term. Being able to be fully invested in their success after a launch, I don’t know that a lot of places really dedicate someone full-time to that, so it’s been really cool to be able to help them sort of fulfill that vision and jump on updates that are security-based or things like that and really help the long-term health of a site.
Ben Aston: In that transition then from freelance to full-time, what have been the challenges? Can you share any of the challenges that you found actually going back to full-time?
Natalie Semczuk: Yeah.
Ben Aston: How’s that been?
Natalie Semczuk: Honestly, the first thing that surprised me the most was a positive. I was just shocked how many people were there to support me on-boarding because I am so used to being the contractor added to a team where I am like a one-person army. I’m like, “Hey, I need access to this. Hey, my contract needs to be updated.” When I was actually on-boarding with this company, people were like, “How are you doing? Do you need more training?” I was like, “Oh my God, this is amazing.” It was shocking in a way because I just hadn’t experienced that in so long.
I think the biggest challenge is just sort of the pace and volume are very different. It’s not my company. It’s not my future in my own hands. It’s the company that I work with is trying to succeed, so yeah. The pacing, the volume is a lot bigger. When I was freelancing, I only had time for like maybe four to six projects on my plate at once a year. Of course, especially in maintenance mode, I have a lot more clients now, but they also have a very different pace. It was a pace that I wouldn’t be able to support myself with if I was freelance. Yeah, so that’s been a challenge.
I think also communication-wise, I’m working with one company so we do a lot of video meetings and things like that, which is really amazing, but I freelanced for a long time where it was just me and I maybe check in with teams in person, sort of on video, a few times a week. I’ve realized I maybe should make more of an effort with my appearance, but no.
It’s been really great and I think it’s interesting to get to a point where I am invested in a team, but at the same time because we’re all remote, we have really nice boundaries with our personal lives. Work and personal time bleed into each other, of course, but we’re much more respectful of each other because we can just sort of step away, which has been great. With freelancing, you don’t really get that because working is life, so it’s nice to have a little bit of a balance again or finding that for myself.
Ben Aston: Yeah. Obviously whenever you’re starting at a new agency, there’s new processes and systems and tools. Is there been anything in the new agency that you’ve been like, “Oh, this is awesome,” that these guys have got something figured out really nicely that you hadn’t encountered before?
Natalie Semczuk: Definitely, yeah. It’s been really great. The person I work with and support, the other PM, she has so many amazing processes for documentation, so it’s a very structured way of meeting with a client, kind of figuring out what’s going on, having a really solid process in our project management tool, and then documenting it all back to them. I still have a small freelance gig on the side, and I found myself bringing that back to my freelance that still exists and saying, “Oh my gosh. I could be writing so much more documentation,” essentially. It’s been great.
I think the other thing is the team is very senior and seeing developers and designers sort of take on those leadership positions too is really awesome. It takes a load off of my plate and allows me to focus more on refined communications and strategic things for clients, which has been really awesome.
Ben Aston: That’s cool. Are there any tools that they use? You talked about documentation, but are there any tools that they use there that you haven’t seen or used before that you think, “Oh, that’s cool,” that other people should know that?
Natalie Semczuk: Yeah, you know, we use Teamwork. I’ve never used Teamwork before, but I understand it’s a pretty big player in the space. I think it’s nice only in that it’s sort of all-encompassing in terms of how we use it. That’s the other thing. I’m a huge proponent of how to communicate while you’re working remotely. Everything we do goes into Teamwork, which has been really, really helpful, not just in on-boarding but, you know, I’ve had some sick time, I’ve had some vacations since I started, and being able to have everything documented in one place, even if I’m cover for someone else too, makes a huge difference. I was just so pleased to see that because it’s something that I’ve definitely found as a pain point in past experiences, especially on-boarding to a singular project in an agency. If that’s not documented anywhere, it’s super difficult to get on board.
Ben Aston: Yeah, I think that’s why it’s one of the things we asked you to talk about in the Mastering Digital Project Management course, this challenge between, yeah, you can have the kind of best-in-class tools out there, but having that single source of truth and actually one tool that might not be the most awesome at everything but it kind of ties everything together nicely, I think is actually really beneficial, especially if you’re trying to on-board people onto a project and they’re like … From the team who’s got the experience, they know, “Oh, yeah, well this kind of discussion always happens in Basecamp and this kind of discussion always happens in Slack, and we save these files here in Dropbox.” It’s like, unless you know all those things, it’s really hard to get up to speed on them.
Natalie Semczuk: Exactly.
Ben Aston: So, it’s interesting when those kind of … yeah, those “one tool to rule them all” tools kind of actually work. There are some good ones out there, but they’re just typically not as pretty or as well-liked overall, so it’s good to hear that some are working.
Natalie Semczuk: Yeah, and I think you got the key, is not all tools are going to be pretty or work perfectly in all of the places it’s hitting, but as long as you have that consistency and are actually using it, that’s really the key.
Ben Aston: Absolutely.
So, today we are talking about communication plans. Natalie, for those that haven’t read your awesome article yet, which is full of practical, helpful tips ? so if you haven’t read it, go and read it ? but what is a communication plan?
Natalie Semczuk: That’s a great question. Actually, while I was writing this article, I was googling all over, kind of reading about other people’s takes on project communication plans too, and I think really in the end the essence of it is that it just defines how communication will take place over a project, what that structure looks like, what the frequency is, who’s saying what, when, and where, really just kind of a massive expectation setting for the communication itself. It’s not necessarily milestone or deliver will based, it’s actually how you’ll be communicating the progress or issues or questions within a project, and really helping your team but also your client understand that expectation.
Ben Aston: I think it’s one of those artifacts, isn’t it, from kind of traditional project management, that as digital project managers, we can be a bit like, “Ugh. Documentation. That’s not cool,” or we can turn our noses up a bit, I think, sometimes about these kinds of-
Natalie Semczuk: For sure.
Ben Aston: … things, these pieces of documentation, which just sound like they’re just lots of work and documentation for documentation’s sake, but yeah. What’s kind of your take on that? I’m interested, like what do you put in the communications plan to make it actually something that’s useful and not just another piece of documentation just describing the same thing that you described in ten other pieces of documentation?
Natalie Semczuk: Right. Yeah, you know, I like to think of it as sort of, one, a very flexible document. Like you said, it’s sort of an artifact, kind of left over from more formal types of project management methodologies, but it’s definitely something that is so, so useful, regardless of the size of your project, the way you project manage, anything like that. I look at it as sort of two-fold, so something that I can look back on to remind myself what I need to be doing for this project. First and foremost, I like the idea of having something for myself because obviously I’m probably on multiple projects at any given time, and I’m sure most project managers can relate to that. I think it’s very helpful to be able to kind know exactly when you should be communicating with your team or your client and how that is.
On the other side, you know, your client is probably not super familiar with how any of our project processes work, regardless of what industry they’re in or how much they’ve worked with you. There’s always a little bit of that risk and uncertainty when they’re giving you a bunch of money to do a thing that they don’t know how to do, so it kind of helps alleviate that stress and pain and gives them a way to also structure anything they need to tell their team, their board, their manager, the people helping with the work on their end, all of that. So, you have a really nice two-way street of how you’re going to be communicating and what you need to do and also what your stakeholders need to expect and who they need to bring in on that.
Ben Aston: Yeah, and I think that’s an important aspect of it, isn’t it? The fact that it is a two-way street, so we can make this … as much as it’s defining what we’re going to do, so as much as it’s defining who we’re going to communicate with, how often, what we’re going to send them, when we’re going to send it, it’s also saying to the client, we can include within that, “Hey, and this is what we expect from you, so you need to tell us certain things at certain times. You need to give us certain information at certain times, too.”
Communication, it’s a two-way street. The communication plan isn’t just about when we’re going to shout. It’s also, okay, how is this conversation going to happen? That ensures that the client has a responsibility too. If there’s information that we require from them, updates on things being delayed or the timeline or whatever it could be from their side, we can include that within the communication plan too and hold them accountable. I think that’s an important benefit of it too.
Natalie Semczuk: It is, and I think it also gives you that added bonus of … It’s almost like an emergency phone tree or something like that, right? It gives you an understanding of who to go to when. I don’t know if that’s a stretch to kind of compare, but in terms of the communication plan, it gives you a place to reference if things come up. If I am on vacation and someone’s seeing my project, they can look at the project communication plan and say, “Okay, I know that we expect to have these sorts of meetings and we are hitting a milestone this week, so I need to do that.” Same with if you have a new stakeholder on-boarding onto a project from your client team or, if you work internally, from your internal team. They can look and see, “Oh, okay. This is what to expect.” It’s another level of that documentation for the things that, strangely enough, kind of writing the conversation around documentation, but you don’t always document how those things happen, so it’s a really good place to understand that communication within a project.
Ben Aston: Yeah. How are you actually using them? I think it’s one thing to create a piece of documentation. There’s lots of pieces of documentation that as PMs we can feel like are a good idea, then when you create a piece of documentation and then file it away in a folder somewhere and think, “Hooray, I did it.” How do you think the best way is that we can use communication plans to make them useful?
Natalie Semczuk: I would say sharing it with the team, so your team on the project, is really important. It kind of gives them an idea of what the communication schedule or cadence is, regardless of if they’re involved in those things. It’s good for them to have some contextual understanding of how frequently you’re meeting with the client or how frequently your client is going to be checking in or any of those things, so sharing it with your team kind of helps give them that understanding. I think depending on the project, definitely sharing it with your stakeholder or client. I only say “depending on the project” because it might be a case where you might need this more internally just because the client is … or the project is sort of like a difficult situation to grasp, so you might have an internal guide.
I would always recommend sharing something expectation-wise and with communication with your client because then they can also flag, “Oh, I also kind of need a weekly update versus a milestone-based update because my supervisor has meetings with me weekly and I want to report on progress,” or something like that. You can help alleviate their needs. So, yeah, all of that. All of that sharing really makes a difference.
Ben Aston: Definitely. I think it can be really helpful to do this in the project initiation phase. When we’re first meeting with our client, I think it can be great to create a communications plan upfront, and then kind of in that initial meeting that you have with the client where you talk about, “How are we going to work together? How are we going to make this work?” Actually one of the first things you can collaborate on together is a communications plan where you find out, okay, who do I need to say what to when? What kind of information do they need? What’s going to be useful? What’s not going to be useful?
As it can be collaborating with the client on producing the communications plan, I think it can be a great way to get that feeling that you’re partnering together, that you’re on the same team, and that it also gives you a way of … We don’t want to be having to send the client loads of stuff all the time because, you know, it can be a lot of work. If we do it right at the beginning of the project and we kind of manage their expectations there, it means if they then later on in the project say, “Oh, by the way, I actually need every week a full breakdown of everyone’s hours and the tasks that they did and all of this extra reporting,” we can say, “Oh, well, we didn’t agree that upfront. That will be a change request,” because the reality is communication is good, but it comes at a cost.
That kind of level of surface level agreement, if we can agree that upfront for the project, I think it can help alleviate these problems down the road when the clients start getting nervous and then they start asking for loads of information and data that probably they’re not actually using a lot of the time but it’s more just to give them a feeling of confidence.
Natalie Semczuk: That’s so true. That’s such a good point.
It can really help define those boundaries essentially, I think what you’re saying, which makes, you know, it makes sense. You document project scope requirements, things like that. Doing the same with communication totally makes sense.
Ben Aston: Have you got any stories of … Let’s be honest, do you always use a communications plan? Have you got any stories where you haven’t used one and things haven’t gone quite planned
Natalie Semczuk: Oh, for sure.
I’m sure many people kind of listening will be able to relate. It’s wonderful to be able to say to do these things, but then reality hits and you’re lucky to even be documenting tasks in the project, so I definitely understand how that works and how that feels.
I learned about project communication plans, honestly, like much of my project management upbringing, the hard way. I think in the article I talk about a situation I had with a client where things were just kind of a big mess, but it didn’t present itself as a big mess until it was sort of too late. There were a lot of really small flags throughout the beginning of the project, things like the client not being very responsive after the kickoff, even though we knew it was a go-go-go project. They just weren’t answering emails or responding to the needs we had in order to start a project, so we were kind of blocked instantly.
We also had a lot of instances where I was just sort of ghosted on check-in calls, which isn’t … I mean, it isn’t the greatest thing, knowing that your client isn’t there to check in, so quite a few things like that. Pushing off meetings, canceling meetings, but still the expectation of sticking to a schedule was surface to me after all of those meetings were missed and things like that, so sort of a slow roll towards massive red flag. At first I was so busy, I was sort of like, “Okay, they know that they’re postponing it, so it must be fine.” It started dawning on me like, we just have no cadence. Regardless of what we have on our calendars, there’s really no expectation of where this is going and how we’re communicating. My stakeholder definitely can’t be getting what they need because I’m not getting what I need.
In that case, for sure, a project communication plan would’ve made a massive difference and given me the structure initially to be able to say, “Hey, here are these boundaries. We’re not hitting any of these things where we should be, and this is a red flag from the start.” It would’ve helped me a lot.
Now currently I try to at least put together something on my own side internally. Whether I share it with the client or not, I think it’s really, really helpful to at least know per client, per project, the amount of communication that’s right for them and what they seem to not just need, but want in terms of reporting or checking in on the phone or video or email or anything like that. Typically I won’t have a full document for every client, but I try to at least outline it from the start in a living message or document where we can refer to that once every few meetings to say, “Hey, are we still targeting all of these communications that we need? If not, let’s add or remove some.”
Ben Aston: Yeah. I think one of the temptations can be, it’s kind of like what you’re talking about, one of the temptations can be that we’re like, “Okay, well, I’m not actually going to formalize this because then I would have to be held accountable to it. I kind of have my plan in the background but I’m not going to tell the client because if I tell the client and then I don’t do it, they’re going to be like, ‘Where’s that thing you promised?”
I think actually for me one of the great things about the communication plan is that it does hold us accountable. Sometimes when there’s bad news, it forces us to share bad news. There’s a cadence for sharing news, so it forces us because sometimes we can be like, “I think this thing might be going wrong, but do you know what? I’m just going to wait a couple of days. I’m not going to send the status report just yet, just to see how this thing kind of works out over the next couple of days.” Then those couple of days become a week and we still haven’t updated the client. We’re like, “Uh, now? Actually, yeah, it’s gone quite bad.” If we’d have just bitten the bullet and been like, “Well, I have to send my status report on Friday because that’s when the client’s expecting it and I’m going to have to tell them that something is going wrong,” I think it’s a good tool for managing risks as well and that kind of accountability aspect of it.
Natalie Semczuk: Usually, yeah. I think there’s a tendency, and I’m sure we’ve all seen with our team members too, where if something’s kind of off-track, if a designer, development isn’t totally going right but maybe whoever we’re working with kind of gives it another day and another day, waiting to flag it, just hoping that it works out … I definitely have talked about this in respect to remote work. There’s a huge tendency, I think for people in remote work. Your first knee-jerk reaction if someone’s like, “This thing is super overdue. What’s happening?” and you just go dark. I feel like I’ve done that to you on an article or two in the past.
Sorry. I’m full-body blushing here, but it is a good thing if then … I think that you’re always kind of like, “Oh, crap. They noticed,” deer in headlights, and then you hope that they don’t notice until you deliver, yeah, exactly, when in fact you’re actually in the headlights.
Ben Aston: Forget or something.
Natalie Semczuk: So, yeah, it’s exactly that-
Ben Aston: I’ll just stick my head down.
Natalie Semczuk: … that total principle in project management where you hope things get back on track, but you want to be saying it when it’s a small issue rather than a big, gaping hole because they’re expecting to be updated. Then you give yourself that expectation setting of, “Okay, they’re going to be a little nervous, but that’s kind of good because that means they might be expecting something more.”
Ben Aston: Yeah. I think that’s good. Ultimately, though, this is all about managing expectations and partly managing risk as well. I’m interested just to touch on what other tools in terms of managing expectations. Are there any other tools or things that you do as well as a communications plan to manage expectations with a client on a kind of formal or an informal basis?
Natalie Semczuk: For sure, and I think a lot of these are rooted in the kind of documentation-heavy project management style. Honestly, I think you touched on it earlier. Actually having those things in place and then following them and holding yourself accountable is so, so important. Even though it might feel too formalized or a lot of overhead, it gives a structure to all of the things that we need to be managing.
I have my own kind of weekly budgeting template for clients and it kind of varies depending on the project or the client, but I like to send them, especially if I have a weekly check-in meeting or monthly or whatever, a couple of days before that meeting regularly a budget and status update. So, that status update might be talking about how many items have been completed this sprint and what we’re on track to doing and how that compares to the last sprint, or it might be something like, “These are all of the tasks currently open,” like if it’s a support project, “and this is what’s waiting on you for review and this is what’s already been completed,” so kind of just a breakdown so they can see at a glance where things are, especially if they’re too busy, if we’re sharing the project management tool or something and they’re too busy to gather that.
I think we’ve also talked about RACI matrixes, or matrices ? have to be correct here ? on the site as well, so that’s a big one that’s really helpful.
Ben Aston: Yeah, yeah.
Natalie Semczuk: It’s sort of like the project communication plan where you think like, “Oh, I might not need something so formal,” but it really does help hammer out the responsibilities of everyone involved in a project. The benefit of those kinds of things is that it flags or raises any issue that you aren’t necessarily seeing when you’re looking at it informally. It gives you an understanding of what can and can’t be defined within the bound that you’re giving it, and in those cases you either decide we need to go further and actually make these things define, or we need to change the bounds that we’re defining within.
So, yeah, those are kind of the main things that I like to use.
Ben Aston: Good stuff. Yeah. Yeah, I think that’s really helpful.
Yeah, so if you haven’t tried using a communications plan and you’re wondering why your client is always on your case or if you wonder why a client’s not responding, try a communications plan. Helpfully, Natalie is not just … We’re not just talking about this. We’ve actually got a template, so head to thedigitalprojectmanager.com. Just search there for “communications plan template” and you’re going to find it really quickly. Try using it and you’ll find that actually it helps a lot.
Natalie Semczuk: Thank you so much. It’s been wonderful being here again.
Ben Aston: Natalie, thanks so much for joining us. It’s been great having you with us today. Good stuff.
If you’d like to contribute to this conversation about communications plan, comment on the post, and also head to the “resources” section of thedigitalprojectmanager.com to join our Slack Team. You’re going to find more than a thousand other DPMs there and all kinds of interesting conversations going on, and you should be a part of it. Go and check it out, but until next time, thanks for listening.