Project Management Hacks (with Natalie Semczuk)

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: Hey everyone and welcome to this latest edition of the Digital Project Manager Podcast. Today, with me, I have Natalie, and I’m very excited to do the first of our podcasts, where we’re gonna be talking to the people who have actually written some of the content and the articles on the site.

Natalie just recently published an article with us on the Digital Project Manager, Project Management Hacks, and everybody loves hacks. If you like hacks, we published an article a while ago about slack hacks that was massively popular. Natalie here has created a list of ten different hacks that she’s been using over the years as a digital project manager, and they range from the very practical to perhaps the more philosophical and more just around how we approach project management. We’re gonna discuss that today.

First let me allow Natalie to introduce herself. Natalie, why don’t you just give us an overview on who you are and the kind of projects you do and all about you.

Natalie Semczuk: Sure, thank you. It’s great to be here. I’m a freelance Digital Project Manager. I mostly work remotely with smaller to medium-sized firms, typically web design and development, sometimes apps. And I work with teams to help them achieve success on their projects, I work with project clients, and I also consult on operational processes and making your remote team even better.

Ben Aston: Cool. Do you want to just give us a quick overview on perhaps some of the projects you’ve been working on recently, if you can talk about those. What kinds of projects, what kind of digital project management do you do? Is it more strategic, or is campaign stuff, marketing campaigns or site builds? What kind of flavor of DPM is it?

Natalie Semczuk: It’s more, usually site builds or deeper web development, things like that. Right now I’m working on two active projects. One is a small elementary school, a private school, and they’re upgrading a lot of their back end system. So how they classify and sort students, things like that. I’m overseeing the project management, the development work and rebuilding and integration that pulls all of that student data from existing systems and puts it into a pretty custom solution of a website where teachers can log in and see their students, and parents can also log in and see their student’s progress throughout the year.

I’m also working on sort of a straight forward website design and rebuild, or a build in general, for a small start-up based out of San Francisco with some exciting products coming along. I don’t think that I can talk more about that, but it’s one of those typical design development phases, a little strategy thrown in, but it’s been a lot of fun so far.

Ben Aston: Cool. Good stuff. Yes, so let’s deep-dive into your ten hacks. We probably aren’t gonna go into each one of them in a lot of detail, but first perhaps give us an overview on how you came up with these. We’ve got some that are quite executional and practical and some that seem to be more philosophical about the way that was should PM. How did you come to these hacks?

Natalie Semczuk: I guess it’s a mix of seeing what other PMs have done that I’ve worked with, and seeing what worked really well for them, and just experience. A lot of comes from working remotely, where you have both a little more and a little less control over your surroundings. Less control over your team that you work with, more control over your personal environment. I think as DPMs, we all use a lot of tools and we communicate all the time. That’s a huge part of our job, and it can be very easy to forget about the details of refining those tools and communications to work well for us so that we’re spending less time on the repetitive boring stuff, and spending more time on what we need to spend time on.

Ben Aston: Cool. So that’s a nice segue into hack number one, “automating your project management tools as much as possible.” So can you tell us, in your article, and if you haven’t checked out the article, go to thedigitalprojectmanager.com, and you’ll find the project management hacks article there, on the home page at the moment. Tell us briefly about the PM tools that you like to use and how you’ve come to choosing those tools.

Natalie Semczuk: Sure. I use a variety of tools depending on the company I’m working with. Almost always Slack, Gmail or Google product suites. For project management tools themselves, I’ve used Basecamp 3 a lot, Trello, and a kind of interesting mix of the two, it’s a tool called Breeze.pm. Those kinds of typical workflow tools, and a lot of Slack and Google and those programs.

Ben Aston: Yeah, cool. In some of the automations that you were talking about in your article, it seems like you’ve kind of set things up so that when people do certain things, or as certain things happen, then you get notifications and magic happens. Does it require your team to all get on the same page and work in the same way? Have do you managed to kind of coerce your team into making this work out for you?

Natalie Semczuk: Most of the time yes. Some of the hacks are controllable on my end. They’re for my benefit, things like notifications and the tools I use, like how I receive those, if they’re weekly digest or real time, things like that. The integrations between tools, say like GitHub or Slack, or Trello and Slack, require my team to follow a certain sort of process, just in that they’re using those tools, which I think is pretty easy to get the most wild west of teams into committing to a repository or something. It’s definitely beneficial to have those integrations set up regardless of the process that’s followed I think.

Ben Aston: Cool. And if people were to do just one automation, what’s the single automation that you find, that you thank yourself for every day, as you enjoy seeing it do some of its magic?

Natalie Semczuk: I think the best for me is, I use Slack as a chat tool with almost every team. So integrating the project management tool I’m using on a project into a Slack channel is so helpful because it’ll give me information, like if someone’s updating a task assigned to them, if they flag an issue and have a certain marker on that task or move the task to a completed column. That gives me immediate insight into what’s being done. I don’t need to log into another program to see, I don’t need to check my email. So I think that kind of integration is the easiest automation to have. That being said if you don’t use tools like that, I love sending digests of information to my e-mail, because it’s just having that one true place to look at a quick overview of everything going on without having to go into six different programs to check the status of something.

Ben Aston: Great stuff. Is there any times that your automations have catastrophically failed and you’ve ended up with a disaster because something happened didn’t happen that was supposed to?

Natalie Semczuk: Yes, I think it can go both ways where integrations like that fail for whatever reason. Something’s updated and I just don’t realize it until too late. Or the opposite, where the integration works so well, you’re being slammed with notifications, in that one place you put them, which definitely isn’t ideal.

Ben Aston: Yeah, cool. Let’s move onto number two. It’s “Use a RACI Matrix on every project you manage.” So for the uninitiated on RACI’s, tell us a bit about those and why you like them.

Natalie Semczuk: Yeah, I have to admit, I use them a little untraditional on my projects, but the basic idea is to give insight into all of the responsibilities, roles, ownerships on a project, and make it very clear which person on a project, or which team, is expected to interact in a certain way, on a project and make decisions. So a lot of people make these at kick off. I think it’s a really great way to be clear. For example, the project client is in charge of deciding what their team, what kind of content we’re moving forward with, but at the same time we need to have insight on our team, between specific departments, into that. So it’s basically designating those different responsibilities between the parties involves on a project.

Ben Aston: Cool, and I know in the article you put an example in there of a RACI. When it comes down to it, how do you get to that decision-making, or tell me about your decision making process where you get to decide who goes in what column. Who is consulted, who is the person that’s just informed, what does being informed mean? What does accountable mean? How do you get to that point of deciding, “Okay, you’re Mr. Responsible, and you’re just informed?”

Natalie Semczuk: I think it’s a mix depending on the project. So I will usually go with a precedent or process for the higher level portions of a project. Going between different phases or milestones, there’s usually a typical process in agencies where you know the client will be involved at a certain point. You know that design or development will be involved at a certain point. So picking out those high level people involved and going along with what you already know is the process. I think there’s a fine line, though, where you need to dictate it as a PM, if the project is somewhat complex or has many stakeholders. Or also get by in, if your team is more collaborative, and you all decide together, these are the people who are informed, these are the people who are responsible. And then of course you can always have overlap. It just is much more useful to designate specifically, which person fits in which place.

Ben Aston: Yeah, definitely. One of the things that I think is often challenging on a RACI is knowing how much detail to go into. To what extent do you break it down? Do you break it down by phases? Do you break it down by tasks? Are you breaking it down by deliverables? How do you go about making that decision and what kind of detail do you like to go into?

Natalie Semczuk: Small projects I definitely like to do it based on, I guess, phases, and large deliverable … On bigger projects, which is either more complex or longer term or more people. The word big can describe many things on that. I like to break it down more granularly, but I also like the idea of using a RACI Matrix for things that people don’t typically think about. Like what the content workflow or update workflow will look like after launch, because that really helps your client or your stakeholders understand the amount of work or the amount of people involved in committing to that and thinking it through. So really it gets everyone on the same page and really manages those expectations in general, to use a RACI Matrix on a project.

Ben Aston: Good stuff. So, let’s hit number three. “Say hi to your team and co-workers daily.” On the face of it, it sounds like at work, you’re not saying hi to them? But how do you work this, how do you see this working remotely versus in an office and you’ve mentioned it a few times. You spend a lot of your time using Slack as a tool. One of the things I’ve found is Slack is a brilliant tool, and I love it, but I also find that we can end up with teams who are working together on the same part, who are typing to each other, even though they’re sat right next to each other. How do you bridge that gap between the virtual communication, and the in=person communication and bring this to life?

Natalie Semczuk: Yeah, there’s definitely a balance to be struck. It’s difficult to say what amount of person-to-person interaction is best for a team, and obviously working remotely, that’s more of a forced interaction, if you’re getting onto a call or video call or something like that, you’re not seeing that every day. But I think it’s just so helpful to gain that rapport with people, and let them know that you know they’re still there. So I kind of like to switch it up. I will ping members of my team either individually to ask them a particular question or see if they have blocker or just ask how they are. Or I’ll … Well I don’t app mention the channel, I feel like that’s a bad practice. But in general, post to the channel. Like, you know, just mention to the project group as a whole, “Hey. How is everyone? How are you doing? Any issues?”

I just think it’s so great to have that interaction in a much more casual way, and not always have an end-goal in mind in obtaining information or obtaining a status or clarifying something, and it gets people to loosen up a little bit.

Ben Aston: Good stuff. So next up, number four is, “Learn to say no on a project. Gracefully but firmly.” Tell us a little bit more about that.”

Natalie Semczuk: Saying no is definitely something I struggled with as a younger PM. It’s hard to do when you’re generally people-facing and nice, but I see it as something to do to protect myself and protect my team and protect the project. I think it’s really important that we learn when the appropriate times to say no or to push back are, whether that’s scope change, which is obviously something we’re all familiar with, or protecting time on a project, clarifying things so there isn’t an immediate reaction with a client who’s asking for more., that is, Maybe it’s not the best choice but maybe they actually mean something else. Being able to push back and say no in some way, in whatever form, to requests that will cause stress or time issues or budget issues, is really important to learn and to also understand when those times come, what is the best way to handle it.

Ben Aston: So talk us through a scenario when you had to say no and how you go about saying no in a way that keeps everyone happy as much as you can.

Natalie Semczuk: I think a trick to this is that no isn’t always straight-up no. Very recently, this week actually, I was working with a team, where our Sprint … We’re working in Sprint, and our Sprint cadence has gotten thrown off, so we had to shift all of our demo meetings and retrospectives and planning, and it was actually a team member I had to say no to. He and I got into a discussion about whether the timing of a certain meeting mattered between two days. I was pushing to not have major meetings on Mondays. I think that’s a messy day to have meetings. Everyone’s getting back from the weekend, and needs to settle it, and he was adamant that Monday would be the best day.

I just had to say, “Listen. I understand this is a ten person team. You’re one person, and I don’t think this will negatively affect you. But I totally understand your concern. It’s just that this has to happen on Tuesday. I will reconsider if it doesn’t seem to work for the next few weeks, but in my opinion that’s the best judgment and we need to move forward with that so that we can continue on with our days.”

So it was a soft no, and I’ve considered it, and I know best for the team in this particular situation. But it was important to recognize that further discussion was not going to work for either of us.

Ben Aston: Yeah. Firm but fair.

Natalie Semczuk: Yes. I try.

Ben Aston: I guess yes, saying no to your team … Sometimes, as a Project Manager, we do have a mandate to be able to say to our team, “Hey, these are kind of the ground rules and the parameters that we are gonna work within.” In terms of saying no to a client, I know a typical scenario for when you might need to say no that you mentioned are things like when a client is trying to increase the scope, or when they’re trying to gold-plate something when they’re trying to bring forward the deadline, when they’re trying to cut costs in some way. What are the techniques that you might employ when tackling that with a client when you’re trying to maintain a relationship. You’re trying to keep the client, keep the project on track. How do you deal with those kinds of sensitivities?

Natalie Semczuk: I try really hard to redirect, and just understand where they’re coming from. I think I mentioned this too in the article, education goes a long way. So in the case where they’re moving a deadline up for example, I think it’s really important for me to explain not only the trade-offs of moving a deadline up, so for example, the cost might increase significantly, features might be significantly cut, quality might not be the same, and then also pointing out where that line is. So I’m obviously going to say no, I’ve identified I’m going to say no, explaining why that is. So, for example, “We cannot move the deadline up that far, because it’ll compromise the quality, and as a company, we work within a certain amount of quality and we don’t feel that this will fit that well.”

Or explaining, “With all of the things on our plate right now, we need to cut down functionality, but the amount we would need to cut down to reach that deadline, will actually make the website non-functional. So we can’t hit that.” And being fairly firm about that. I don’t like to leave a loophole, or a too big of an apology or something where it can be worked out, “Oh, if we just do this, we can hit that.” So being firm, being educational, but also really understanding the repercussions of that decision.

Ben Aston: Yeah. I think it’s important when we are saying no, to be really clear that we are saying no. I think one of the challenges is that we can have sometimes is that we try to tell the client no, but we end up introducing words like, “We don’t think we will be able to … Or we might not be able to hit the deadline or I’m not sure if we can include that.” And then when there’s not that clarify of language, or even when there’s not that follow-up afterwards saying, “Just to confirm, we will not be able to hit the deadline that you’ve requested.”

So I think that clear language around no is so important. Also that we give options as well. We, as much as possible, want to be empowering our clients to be able to make the right decision themselves, rather than forcing them in a corner and asking them feel like, “Oh hold on. I just lost control.” Clients want to know that they’re in control, so giving them choice, like, “You can go for Option A or Option B. Option B will take longer and it will cost more money, but the quality will be better or you’ll get what you want, but you’ve got some options here, I’m not just saying no. That’s an option for you.” Giving them the feeling that they’ve got some choice I think can really help sometimes.

Natalie Semczuk: Yeah I totally agree, that’s so great.

Ben Aston: So next up, yeah. “Treating your projects as learning opportunities.” What have you been learning recently?

Natalie Semczuk: I think I talked a little bit about learning more about development, but I’ve been on a few development heavy projects and it’s been great to see something I don’t fully understand and take the time to ask my team, when they have the chance, to better explain that to me. The benefit of that is, I understand it more from a project management perspective, and I can maybe share that with them if there’s any overlap that would be interesting to them to learn. I can also educate the client a little more when I’m telling them about these things, which I think is always important.

The other thing I really like, and I think this is why I’m drawn to project management is: I get to learn a lot about my client’s businesses and their thinking and their strategies and it’s clear on every project I’ve worked on, especially since I work on web development projects, that there’s so much teaching and learning to do about the web for our clients. Just understanding how they use websites, how they update websites, what their major issues are when they access a website. It’s kind of baked in user experience research. It’s always definitely a learning opportunity in those sense. I think projects are also a good time to try new techniques or new communication patterns. Obviously not to an extreme, but in a way to slightly tweak what we’ve done before and see if that makes a different too.

Ben Aston: Yeah, one of the things you talked about in your article is retrospectives, and using those as learning opportunities that you build from. Tell me about how you use retrospective with your team. I think one of the things that I’ve found that can sometimes happen is, yes, people will go through the process of having a retrospective, but how do you effectuate change as a result of a meeting?

Natalie Semczuk: Well I think even just the process of having a retrospective is so healthy for a team. I’ve definitely been on projects where there’s a ton of ranting and grumbling behind the scenes, and every time we’ve done that, it comes from a core issue on the project itself. Whether that’s the client, or the process, the project itself, how it was managed, how my team was working on it, all of that. There’s always something we learn from random ranting and grumbling. So bringing that into a retrospective where you can not only reflect on the things that were difficult, but you can also reflect on the things that did work, is so helpful to put it all out there. Because I don’t think that’s something that typically comes along, at least on the team side of things, naturally, on a project.

We don’t typically say, “Hey this process was great, it worked so well for me.” We when do find something not working, I think we tend to do that little grumbling or ranting or get that frustration pent up in your head. Getting it out there is helpful. I really like documenting the key points and takeaways form all of the things said, as we’re talking. So since I’m remote, I typically will screen share and take notes as we’re talking, and this can be done with a white board in person or something similar. I really like all agreeing on one or two things to improve moving forward, whether that’s on the same project team if we’re working together again, or just having that at an elevated level where we’re all aware of it. Whether something is officially done from a process of PM or company standpoint or not, it really helps to have that awareness into what that issue is and what we want to improve moving forward.

Ben Aston: Great stuff. Cool so next up, “Taking control of your notifications.” I think this is pretty self-explanatory but this is obviously important enough for you to think that it’s worth including. What are the kind of notifications that you find most helpful and least helpful when you’re kind of prioritizing, “Okay, do I mute this or not.”

Natalie Semczuk: Mm-hmm (affirmative). I think in general, any kind of unread notification or that red badge, I’m on a Mac, so I see those red badges a lot. Those really, for me, stress me out. I always want to clear them out, I want to deal with them, address them, read them, but if I read them I’ll forget about them if I’m not dealing with them right away. So I will mute almost anything that gives me an unread notification that is not directly related to my project or a direct message. So I always leave my direct message notifications on just because, since I’m working so closely with teams who are remote, I think it’s really important that they can get a hold of me privately. But yeah I’ll mute anything that is idle chatter, or that is from a bot, depending on the tool, sometimes you can automate that. Or I mean, sometimes you can change that preference.

I will also often apply filters and unread message filters in Gmail, so that I don’t always see immediately something that’s unread but a digest of what’s happened on Basecamp that day. Or if I know it’s not from a client, I don’t have to look at it and deal with it and delete it right away. So just knowing what my triggers to being reactive are and dealing with that has helped me a lot.

Ben Aston: Great stuff. Cool. The next one I think is a really interesting one. It’s “Educate as much as possible.” We talked earlier about the kind of scene education, but tell me a bit about the ways that you find personally you’re kind of learning and growing as a Digital Project Manager at the moment, that other people might be able to leverage.

Natalie Semczuk: Yeah, I think when we, so I know when I started and I know when I talk to people who are junior, always reinforce to be clear about what you don’t know. I think that’s actually one of the points in this article too, to be upfront about what you don’t know and what you need to check on with your team on. But I don’t think it’s always looking at as like a personal growth opportunity either. When I know I don’t understand something that my team is working on or talking about, obviously I’m not going to be an expert in everything. That’s why there’s a team, a project team. They’re the ones doing the work and they know how to do it and they’re experts.

If there’s something that I’m particularly curious about, or, for example, that trips me up all the time, I think I use development and DNS and hosting and server things as an example in the article, I’m typically the one on the client side describing what we need. What kind of information we need from the client and that for DMS changes, and also describing to them what the issue is if we do have that kind of issue. So understanding what that looks like on the back end more and what those terms mean and how that all works together was really hugely helpful for me because it game me context and a framework to talk about it with a client, and was directly relevant to a lot of conversations I was having.

Ben Aston: Cool. Any websites or blogs or things that you’re reading at the moment that you’re finding helpful?

Natalie Semczuk: I guess I honestly usually google things and well I love listening to podcasts outside of my particular area of focus. So, design or content strategy, podcast or something that I find interesting. There are a lot of front end or back end podcasts out there, and just tuning in once or twice when I have the time helps me feel more comfortable with the terminology and understand what’s going on a little more too.

Ben Aston: Yeah, no I think that is so important. As Digital Project Managers, as we’re trying to lead a project, we’re not just managing a project, we’re leading it. And in order to lead effectively, we need to know more than just about administering a project, and it’s so key that we begin to develop expertise, not to the extend that we can actually execute, although there’s nothing wrong with a cheeky bit of sketch changes every now and again. But it’s so important that we understand strategy, UX, design, Dev, QA and the kind of advancements that are going on in those different disciplines in order that we can ensure that our team applying them to our project so that we can sound knowledgeable in front of our clients. Also, it just gives us this ability to be able to lead our projects much more effectively when we’ve got a better idea about what people are doing or what they should be doing. So I think that’s great.

One of the other things, we’ll skip to number ten on your list, which is, “Always note the numbers.” Which I think is so important. Tell us about the numbers that are important to you on a project.

Natalie Semczuk: Yeah, of course. So I work with time and material based teams mostly, so pulling time reports is really important, not just to understand where the budget is going, or how many hours are being put into work. I guess maybe I’m just a bit nosy, but I like to read the descriptions on the time entries too, because I think it’ll often show where there might be a blocker or, not even an issue, but maybe more a point of learning or a point of collaboration I wasn’t aware of, and it’s nice to understand that from the trail left behind. Especially since I’m not in an office, again, I don’t always see how people interact.

So knowing how people are spending their time, and I do this without malicious intent, not to judge but more to understand what’s going on. Obviously to get budget based numbers too. I think it really gives you good insight into things: communication and work and things going on on a project that you might be able to help in and you might be able to learn from, and help facilitate in the future. So that’s really important to me, I regularly check in on the project management tools I’m using to see if other conversations are going on. A lot of times I’ll work with tools where the client is invited in, so I just take a brief look to see if other people are having a conversation, if I need to be involved, and then also to see how many tasks have been completed, or might be blocked or stuck if we’re working in a task-based manner.

I think understanding resourcing for projects, so how many hours people are putting in per week, or slotted to put in per week, when their vacations are coming up are important. So these are all kind of numbers based, but they all feed into the larger budget, timeline, velocity, numbers coming out of a project, and all of the work going in.

Ben Aston: Yeah. Cool. So, there was a comment on your post. Someone said that they’re recently switching to a PM role from an AM role at a marketing agency and there isn’t much structure around the roles. They were wondering if you had any recommendations on how best to report to an hours budget. Excel spreadsheets, tools, that you would recommend, how do you do the nuts and bolts of your reporting. What do you use for that?

Natalie Semczuk: Most of the teams I’ve work on use Harvest or time-tracking tools like that where the team put in their time spent every day or every project, and I can pull reports from that. So I can pull daily, monthly, weekly reports. I think the importance is understanding how your team is allocating their hours and how they’re tracking it, and then building a system from there. If I’m reporting to a client, there’s a nice feature in Harvest, but I think in other tools as well, where you can export to a CSV, or an Excel spreadsheet, or a Google Drive sheet, and I can kind of clean up the entries, and summarize it if they need a detailed view.

Otherwise, if it’s a report for a client or for my team, just pulling the numbers myself from wherever it’s being tracked, and reporting on that either verbally or in an email can be helpful.

Ben Aston: Yeah. And how do you reconcile those numbers then? So obviously, people are doing the work, they’re logging hours against it. How do you actually know whether or not you’re on track or not? How frequently do you need reconciliations against the estimate? How does that process work?

Natalie Semczuk: I tend to do that mostly weekly. If it’s a really, really busy week, I’ll check in multiple times a week with whatever tool is being used. I’ve also, I should mention, I’ve also worked on projects that are not, time is not tracked against it that granularly. It’s more people are blocked off to work that full day. In those cases, I will go and make sure, in the tool that we use to allocate people’s days, I’ll make sure that’s accurate for what people worked that week, based on what I hear from the PM report that week.

To reconcile hours in general, I’ll pull a report weekly or semi-weekly if it’s busy, and make sure all time is in, and just check that against the estimate, or whatever we’re working against, the budget, and make sure I’m also taking a look at what might be allocated towards internal time or education or learning, which isn’t that frequent but it comes up. So, just getting sort of a week-to-week look, and that’s typically how frequently I update my clients as well on their projects. So it gives me a good sense of how far along we are, and generally that doesn’t fluctuate too wildly if I’m only looking weekly.

Ben Aston: Yeah. Good stuff. Well, thanks so much Natalie for joining us. I think that’s been really helpful in just helping us understand a bit more about the way you work and some of these hacks that you’ve pulled together, so that we can all learn from them to. And just to say, if you’re listening to the podcast and you would like to contribute to the conversation, we’d love it if you could share your thoughts as comments on Natalie’s post on thedigitalprojectmanager.com, but we’ve also got a Slack team. So if you click on the community section on the Digital Project Manager site, you can sign up to join us on Slack, and continue the conversation there as well.

Thanks Natalie for joining us and we look forward to having another podcast again with you soon, so great to have you with us.

Natalie Semczuk: Thank you so much.