Lessons Learned & Tales Of A Remote Project Manager (with Natalie Semczuk from Talkanatalk)

Read The Transcript:

Ben Aston: Thanks for tuning in. I’m Ben Aston, and this is the Digital Project Manager podcast.
So today I’m joined by Natalie Semczuk. Natalie, thanks for coming on the show, this who actually for the first time, the digital project management podcast in history, Natalie is the first guest to reappear, so a big day today.
And so today we’re going to be talking about project failure. We’re going to be talking about Lessons Learned, and Natalie’s fantastic DPMish newsletter, and anywhere else that the wind takes us.
So, Natalie, we got to know you a bit last time. If you are wondering who Natalie is, let me read from her bio. I think it’s always embarrassing when people do this, so apologies. This is what someone, it may have been Natalie, but someone wrote this about Natalie. “Natalie is a consulting digital PM working remotely. Living in the southwest US, she works mainly on small to medium-sized agencies with in-house web departments, managing digital projects, and implementing processes that help design and development teams. And she also specializes in implementing project systems across remote teams.”
Natalie has written a load of articles on remote project management, so check those out if you’re a remote project manager. And she also runs the PM Reactions blog. She enjoys dystopian fiction, yoga, and drinking too much coffee. She’s also recently back from vacation, so it’s very special that we have her today.
Actually, southwestern US, it does sound a bit like, are you hiding from somebody?

Natalie:

No. I am in Arizona. I kind of moved around a lot the last few years, and it got kind of tiring updating bios and telling people, “Oh, I’m actually not in that state anymore. I moved like last week.” So I’ve been trying to be a little broader in my geographic location.

Ben Aston: Yeah, save you from updating that, so that’s good, cool.
And how is Arizona this time of year?

Natalie:

It’s beautiful. We just hit a milestone this week. We have no moreover 100-degree weather, so we are officially in fall.

Ben Aston: Icy, icy cold.
I was in Atlanta this week for, so in Vancouver, where I am now, it’s currently about 40 something. I’m trying to use American temperature. I would say it’s 8 degrees. But in Atlanta, it was 80 something, around 30 something degrees, and it was hot and so sweaty. It was crazy. And coming back to Vancouver, I’m now freezing.
But actually, I’m interested, as an Arizonian. Is that what someone from Arizona is called?

Natalie:

I think.

Ben Aston: So where do you go on holiday? Surely, that sounds like you’re in a nice part of the world. Where does someone from Arizona go on vacation?

Natalie:

I am in a nice area. I mean I’m like 3 hours from the Grand Canyon, which is pretty cool. For the most part, we all sort of find our way out of here in the summer, because it just gets so hot. I don’t remember the conversion, but in Fahrenheit, it’s about 120 in the summer, 115 most of the time, so people go out to the mountains, or just leave the state entirely, which I agree with all around really.

Ben Aston: That is 46 degrees C, for all of those of you in the rest of world who use Celsius. 46, that’s halfway towards boiling.
So tell me about that. I know you’re a remote project manager, and you have been doing that for a while now, but what’s the deal with that? Why did you choose remote project management? Or did it choose you?

Natalie:

Yeah, it was a little bit of both. I love it. I worked in offices full time in the places that I lived for a long time, and started freelancing on the side, and the only way that really worked was to freelance with companies that were remote. And for the most part, the first few contracts I had were remote-based, and I just found I really enjoyed that sort of, lifestyle I guess. So I can choose my schedule and choose what I do with my time a lot more freely, because I’m not really bound to an office, or commuting, or things like that. But also, I don’t know if people realize, remote project management is pretty awesome, because we can get our work done very easily. No one’s interrupting. But I also have the benefit of talking and communicating for a living, so I never feel lonely, really.

Ben Aston: That sounds pretty peachy.
So with all this efficiency that’s going on. And with all being able to manage your own time, what do you do in your spare time then? We didn’t really cover this last time. What does, apart from being a PM, what does a PM do in their spare time?

Natalie:

I definitely have a little bit of a problem with work-life balance sometimes. I think it’s the freelance part too. Whenever you’re not working, you think about what you could be doing with your time. But I do enjoy exploring the area. Like you were saying, I live in a really great part of the country, and Sedona is close by, the Grand Canyon, all these really awesome great mountains, and trails, and things like that, so I like to go out there, hike, off-road, explore and take photos. Have not ventured into camping yet, because there’s a lot of scary bugs out here, but I’ll get there eventually.

Ben Aston: You just need some fly-swatter, or spray, or a gun.

Natalie:

I guess I would fit in then.

Ben Aston: Cool.
And one thing I’ve been meaning to ask you is, whatever happened to your PM Reactions blog? It has listed, has it been now? Has it come and gone, and now it’s turned into DMPish? What’s the deal with that?

Natalie:

No, it’s still there. All the gifs and memes are there. Every-

Ben Aston: Last updated second of April.

Natalie:

I know.
I have a whole folder of gifs ready to go. I tag them based on emotion. I used to every so often load up like 50 at a time, and auto-post, but it’s been a little too long. I’m embarrassed now.

Ben Aston: Well, maybe something to include in your newsletter, just an idea.

Natalie:

I like the idea.

Ben Aston: So it’s been a couple of months since we last spoke. So, apart from going on vacation, what else is new? What have you been working on? Have you found any new, cool tools? What’s new?

Natalie:

I’ve been doing a couple of new things. I finished out a few projects this summer. Started a new one right after vacation with an agency in New York City, before that an agency in Montreal, and it’s been great. I’ve been working with a range of client projects, and between that and working with more structured agencies that all work in one location, but support remote work. I’m the only full time remoter. It’s been really nice to see their processes, and how they set things up, and contribute to those changes, so.
I haven’t used too many new tools recently. I did get very into TeamGantt and Gantt charts recently. Again, I used it for one project a long time ago. Stopped for a while. Got right back in and am relearning the ways of that. Trying to think of any other cool tools. I’ve been using MeisterTask, which is Trello-ish. I’m not sure how it is with a team, but with a very small team of freelancers, that’s been working pretty well.
I think that’s about it.

Ben Aston: Nice.
I’ve never heard the term, ‘I’m a remoter’ before. Is that what you call yourself in the bis?

Natalie:

Sometimes yes. I don’t know if it’s official though. I kind of just say that.

Ben Aston: And I’m interested in, for those, it might be an interesting thing just to touch on. So you work as a DPM, remotely. You’re working with agencies all over the place, in New York, in Montreal, other parts of the states. How do you get these remote PM gigs?

Natalie:

Oh, man. I think that’s probably one of the biggest questions for freelance in general. When I first started, I looked for people looking to hire their first PM, because they weren’t really sure … Typically, when you hire someone for the first time, like in the first role, you’re not really sure how much work you have to fill their plate, so that’s where I found my space. But in terms of remote PMing for agencies and larger companies like that, a lot of it has been word of mouth. You know, knowing one person who moves to another agency, who then knows someone looking. Or, just sort of being out there, speaking at conferences, writing articles, things like that.
I typically don’t initially communicate with a person who needs to work with me. It’s like another PM who needs a lot of help, and they’ve identified that, and they kind of want to make it work. Or it’s a business owner understanding they might need some space for their team to hire. So it’s kind of a mix.

Ben Aston: So welcome back to the Digital Project Management podcast for part two, after Natalie and I, well mainly me, suffered a tragic internet failure. So this is the beauty of life.
Natalie, thank you for telling us about how you get your remote project management gigs. I will have to listen to the podcast to find out what you said, but-

Natalie:

Hopefully, it’s good.

Ben Aston: Because I disappeared. But let’s talk about your article. And if you haven’t had a chance to read Natalie’s latest article on theDigitalProjectManager.com Go and check it out. We’ve called it, Why and How to document Lessons Learned. The brilliant thing about this, is that it’s not just all boring theory, but we’ve included, or Natalie has created some really handy Lessons Learned templates that you can download. And just to say, if you’re trying to download them and you’ve got an ad-blocker, you will need to turn it off because otherwise, it won’t work.
But don’t you just hate it when you find a template, and you think, “Oh yeah, that sounds good.” But you’ve got no idea how to use it. Well, the good thing is, rather than just being an empty template. We’ve given some PM inspo. And yes, that is a valid hashtag, I think, will be soon. Complete with some Lessons Learned, filled in, so you can get a head start in filling out the Lessons Learned template. So let’s talk about Lessons Learned for a second. Why is Lesson Learned even a thing, Natalie? Isn’t that just the same as a project retro? What’s the deal with Lessons Learned?

Natalie:

I know there is an official PMI framework around this. I’m not formally trained, and to me, I see it more as. Project retros are really awesome with your team at the end of a project, but in order to perpetuate change, and understand where things continually go wrong, or are done well, and how to apply that across multiple projects, especially if you’re at an agency long term, or working with the same people long term, it’s really important to track and understand that, and grow from your experiences.

Ben Aston: Cool. Yeah, I think that’s so true.
And why do you think it is? Do you find that on projects … It must be interesting for you actually working with different agencies, and different teams. Do you find that they’re consistently all making the same kinds of mistakes? Do you find yourself writing the same Lessons Learned each time, as you’re working with different agencies, or how does that work?

Natalie:

Yeah. In my experience, it’s always the same mistakes and the same pains. Everyone has these commonalities. I think you can see that when you go to any kind of conference in our industry. You see the different talks, and always talking about conquering this project issue, or that design process issue. So I definitely think that every agency has that typical same overarching mistake, or pain, or whatever in their processes. And it’s always interesting to see how different teams conquer that, or deal with it, if they haven’t quite figured out how to fix it. That’s been huge for me, and I like to be able to at least track for myself, what I learn and what I see, and how that might change my perspective when I go onto different projects with different companies.

Ben Aston: And so what do you find, like what’s your top three common problem areas you think that PMs are encountering?

Natalie:

I think there’s always issues around, estimating, project kickoff, like the project expectation area. It’s really hard. There’s been, I think probably books written about the topics of estimating, and it’s always hard to find a way to accurately estimate or build for projects, if you’re not doing up-front estimates. I think timeline and roadblocks that just aren’t anticipated are always an issue. So things like, if a client has to delay for a particular reason. Even with the most solid process in place, it’s really hard to plan for the unknowns in that way. So I’ve always seen similar pains around that.
Like, a client needs to delay for six weeks. We might have a process in terms of contractual obligations, or how we build that out, or on how we take a project back in, but there’s not a really great way of handling that on the capacity or resource side. And I guess the third thing, I think handling everyone’s expectations is always an issue. There are lots of really great ways to document and update people in meetings and things like that, but there’s always going to be some sort of expectation management, especially on more agile and collaborative teams. It’s harder, because you don’t always have that one true source of info, it’s harder to make sure all of those loops are closed and addressed appropriately.

Ben Aston: Yeah definitely. I think that’s great.
And just on, as a heads up for those who are listening to the podcast. I’m actually working at the moment, on an estimating mega-article, which that Natalie pointed out, was one of the things that we often struggle with. That, we’re going to launch in the next few weeks, so look out for that.
But for me, yeah. One of the most common problem areas I think, that I seem to find, is always around the ownership of requirements. On different teams, it works in different ways, but there’s always a bit of uncertainty over exactly who’s the person that owns the technical requirements. Does it start with the user experience architect? What role does the business analyst play? What role does the technical director play? What role does the PM play? Who’s actually defining exactly how this thing works and the requirements? Especially as we are doing increasingly technical projects. Not just owning those requirements, but managing them as they evolve throughout the process, I think is a problem that just seems to crop up again, and again. I think part of the reason is, is because how that ownership changes throughout a project is partly to do with how well the team is collaborating, and who you have on the team, and what kind of project it is, so it’s very difficult to make a singular process, that works for everything across all projects and all teams. But I don’t know if you’ve found that at all.

Natalie:

Yeah. Actually, I couldn’t have said it better myself. That’s always a huge struggle for me. It’s, you’re right, I think the root of it, is you can’t always make a process that works perfectly for every person, and every step in that way to collaborate together. So yeah, it’s a very real problem for me. I feel like I’m going through that right now.

Ben Aston: And what would you say, thinking about the most important lesson that you’ve learned in your career so far, any thoughts on what that is, or what that might be?

Natalie:

Yeah. It’s kind of like a global one, but never, ever, ever make assumptions. There have been so many times where I’ve held back what I think is a stupid question. Or, I might be in a meeting, and a decision was made, but I don’t quite understand it, and I might hold back asking to clarify that, but every time I’ve done that, I’ve always regretted it. Whether it’s come back to bite me or it’s something someone else asks and it sparks a massive discussion because everyone else wondered that too.
So I definitely try really hard never to assume other people know things, whether I’m communicating to them as a client or not, or to assume that I shouldn’t ask that question, or shouldn’t clarify something, and it makes it a lot easier to deal with because I’m working from a very even playing field if I just, assume nothing, ask everything, say everything, clarify whatever is needed. At least it’s out there and something to talk about, which has helped a lot.

Ben Aston: No, I think that’s great. And I think as more junior project managers, or someone who has less experience. They can be tempted to not ask what you think might be a stupid question because you don’t want to seem like you don’t know what you’re talking about. Yeah, you don’t want to appear stupid, but I think it’s such great advice to be the person who asks stupid questions and be comfortable with that. It’s probably not a stupid question, and in bringing up these questions, it can often spark things that other people might not have thought about. And obviously, you’re not going to learn unless you ask stupid questions as well, so asking questions and not making assumptions I think is really helpful.
I think for me, the biggest lesson that I learned. Early on in my career, we were working with a big consumer electronics brand. We had a very interesting client. He just refused to agree to costs. He’d always kind of work on the basis that, “Hey, let’s just have a gentleman’s agreement to figure it out fairly afterwords.” And of course, it never was fair. We got burnt a couple of times. Eventually, we actually fired the client, but we got burnt really, really badly. Because we thought, “Hey, we’re in panic mode. We just need to get this done. We need to hit this deadline. There’s a big media campaign that’s going live in about the line campaign. Let’s just do the work and figure out the costs afterward.”
In fact, this has happened a few times. It’s people that I’ve managed as well. Never agree to do the work before agreeing who’s going to pay for it, especially if the client thinks it’s your fault, and you think it’s the client’s fault. Make sure that you agree costs upfront. Otherwise, you’re going to be in big trouble. So there you go. There’s my Lessons Learned of the week.
Cool. But just to finish. Natalie, do you want to tell us a bit about DPMish? We mentioned it earlier, but tell us about this new newsletter that you’ve created.

Natalie:

Yeah. So it’s a weekly newsletter. It goes out every Friday morning, focus on project management. I tried to take a different look at project management. Since it’s a more personal newsletter, I try to share my experiences, or what’s relevant to me that week, and some cool links to read about. Maybe things that aren’t super related to project management, but might be interesting to all of us, since we touch so many different things in our projects. This week, I just launched a new feature with Patrice Embry of the PM Advice blog. We’re doing ask a project manager every few issues, and you can submit your questions, and she’ll answer them. It’s pretty awesome. I’m really excited about this week’s topic, it went out this morning, and a link to the newsletter will be up on DPMish.com soon.

Ben Aston: Excellent stuff, cool. Well, we are going to wrap it up there. Natalie, thank you so much for joining us on the second podcast that we’ve recorded, today, with you. And hopefully, this will all come together beautifully. But if you’d like to contribute to the conversation. If you’d like to download the Lessons Learned template, go to theDigitalProjectManager.com check it out there, and be sure to join our Slack team as well, where you can find all kinds of interesting conversations going on, especially I have to say, in the remote PM team, or slack channel that we have. Of all the channels that are going on, if you’re a remote PM, there are lots of people chatting all the time about what they’re wearing and whether or not they’re going for coffee. It’s always entertaining to follow the discussion, even if you’re not a remote PM. They’re always talking about interesting things. So check that out too, but until next time, thanks for listening.