Why project management system migrations fail (and yours might too)

Foreign.

Hello, everyone, and welcome to the Zen Pilot live show. So good to have you with us here today, Mike. I am Kuba Gretzar, your content marketing manager, your host here at Zenpilot, and with me today is Derek Harvey, our director of client strategy and the local coffee enthusiast at Zenpilot. Derek, how are you doing today?

I'm doing excellent, Kuba. I don't know if I've ever heard you pronounce your last name before. That was. That was special. Thanks for doing that. I appreciate.

Appreciate that special challenge. Repeat after me. Everybody watching.

Do you roll the ritesar?

Yeah, yeah, that's like that. That's in the top five that I heard.

Okay.

Memory. So congrats on that, Derek.

Appreciate that.

All right, watchers and listeners, we're off to a great start here. First of all, technical stuff. Let us know that you can hear us and let us know that you can see us, okay? Because this is getting recorded, if you're curious. The recording is going to live at the exact same location as where you're watching live for easy access. If you need to access this later on. Of course, if you have questions about our topic today, Project Management System migrations, then you can ask these live here. And you know you'll get your answers. So leave us a comment, let us know if you can hear us and if you can see us. Meanwhile, Derek, first question for you that I wanted to ask is, who do you hope will be tuning in today? Like, what kind of person and what kind of situation will find this helpful? Like, who are we here to help today?

Yeah, well, I mean, some of it's in the name, right? If you're a project manager, really of any sort, but specifically folks that are a part of teams, like marketing agencies or professional services firms in some form or fashion, if you're a team leader, if you're an agency owner, business operator, and you have either attempted a PM migration, you're about to attempt one, you're in the middle of one, or you just did one and are wondering, did I just make a huge mistake, or is this the best thing I've ever done? Like, if you're in one of those camps somewhere along that stream, you. You're in the right place.

Okay. Yeah. That's awesome. And I wanted to ask, actually, our watchers and listeners here, like, this is the type of situation that we will be addressing here today. We'll be talking about these migrations. We'll be talking about kind of the common pitfalls that you might fall into when you're doing a project management system migration. I mean, I've lived it. I've done a migration to ClickUp myself and I have made some mistakes in the past that I do regret. I made a post about it on LinkedIn. If I could send you back in time to 2018 when I was first migrating to ClickUp, that would have made things so much easier. But anyway, watchers and listeners, I've got a question for you. Where are you in this project management migration journey? What tool are you on in terms of project management? Let's start with the basics and what would you like to get out of this session today? We've got Derek here for an hour to answer your questions. So the more you can steer us towards what kind of value you would like to get out of this, what kind of situations you would like us like, specific situations you would like us to address, the better we'll be able to help you. So definitely drop that for us in the comments so we'll know what you're interested in here today. All right, so while we wait for that to roll in in the comments, I think we're already far enough that I can ask you, because the way I like to start these is, you know, before we talk background, before you maybe say two words about, you know, your role at Zenpilot, what you do day to day, I wanted to ask you the traditional question that I always ask during the Zenpilot live show. Are you ready for it?

I'm ready. Hit me.

Okay. So Derek, what is your number one tip for agency operators?

Number one. I mean, there's so many tips that one could give in this situation. But I think the, probably the biggest thing that floated to the top for me because like you, Kuba, I was also a part of actually several PM migrations. And I think that probably the number one thing I would share is think about who, not how. And you've probably heard that concept right there. I think there's even a book about it. But like, don't be, don't think so much about how to do xyz. Especially if you're in a, in an agency operator seat, you're in the exec level or you're the founder, you're the owner and doing them yourselves. But at some point that only gets you so far. And then you need to shift from how do I do this? Into who's going to help me do this. And that might mean you hire somebody, it might mean you recruit people on your team to help you accomplish the goal that you're after. Right, but. And it's just leading with questions, really. Tell me more about that. What do you think the solutions are? And then if you do have a final pitch, if you will, like, okay, well, I've been contemplating some sort of, you know, project management tool migration. Do you think that would be a helpful solution? Is that something you could get on board with and we could keep role playing if you want, but. But that would be kind of how I would, I would, you know, I would go down that route.

Okay. Yeah, I was bad at the roleplay because I didn't even actually say anything. I get your concept for sure. And I actually wanted to ask you to fill in that vision a little bit more because I feel like if we're going to talk about these project management migrations, then it would be useful to talk about kind of the origin story behind them. Right. So we're about to talk about, you know, how these migrations can go wrong, you know, the pitfalls along the way. Can you first fill in, like, within that conversation, what is the project management lead likely to say? What are the kind of symptoms that are happening that they would want to, you know, ultimately, perhaps the decision will be made to address them through a project management migration. But how does it look on the surface?

Yeah, yeah. It's usually a few, a handful of the same things. And this is what I hear, you know, almost every day it's the same handful of issues. It's. We lack visibility. Right. Broadly speaking. But to get even more more specific, we lack visibility around statuses of projects. We don't know if we're going to hit things on time. We have, we have due dates, but they're more suggestions. So we don't know if we're actually going to hit things on time. So client delays are an issue or work delays are an issue. We don't have visibility into the team's workload. We don't actually know if we can take on new work and if it's going to drown the team or not. Or we're solely relying on feedback from the team to tell us if they're overwhelmed, which may or may not be true. We don't want to diminish what, what people communicate. But. But it could also be true that someone feels overwhelmed, but really there's. They could just be bad at time management. Right. That could be one thing. Or they could actually be overwhelmed. But you would have zero idea. Right. I hear that all the time. So lack of visibility around team workload capacity. Those are the two biggest. I lack visibility around, you know, profitability and utilization. Utilization kind of times to ties back to the workload management side. But even of the work they're doing, is it towards the most profitable activities for the business? Are they spending their time on the, on the areas I need them to spend time on. So it's another layer even beneath the workload management side. And then profitability, are we actually profitable on the things we're executing on of promises made on the sales side, we're keeping those promises, but are we keeping them in such a way that it's beneficial to the client and profitable to our business? Those are some major ones around visibility. Now we could get more tactical around things like individual team member pain points. People say like I don't know what to work on each day, I don't know what the priority is, or I'm spending a ton of time in meetings trying to get to the priority. Right. So we're wasting time in meetings just prioritizing, not making decisions, which is really what meetings should be for, making decisions. If it's an update like shoot me an email, post it in your PM tool. Right. There's other, other areas to get updated when it comes to meetings. We want to be making decisions in meetings. That's a side note. But we're spending all this time in meetings trying to figure out what's important. Right. So those are, those are a handful of things. All the other tangential pain points circle around those key areas, but those are some big ones.

Okay, great. I love the point you made about meetings. I feel like that's going to resonate with a lot of people or even more so the point of I don't know what to work on each day, I don't know what the priority is. Like I remember situations where, you know, it's a five day work week, but I feel like we spent, I've lived it. We spent all of Monday trying to just figure out what's the number one thing to work on this week, you know, and that's a whole day done. You know, by the time you sync up all of the themes on different levels, sync up with the team, kind of the executives above you, your team kind of communicated down. That's the whole day shot. I've lived it. So I feel like if that's something that any of the watchers are facing right now, then yes, definitely having the right project management system can actually save you from these meetings and that's worth exploring and we're going to do that right now. So let's talk about These project management migrations. I think for the starting point, let's perhaps kind of define what kind of situation we're talking about here. Does the migration have to be from one tool to another? How would we first kind of define this process? The trigger gets pulled on it. So what kind of change does that mean? And what does it look like kind of at the beginning? I'm curious what it looks like at the beginning in the sense of we think it's going to go this way and then perhaps it goes differently than people initially expect. Can you first define the situation of what these migrations typically look like at the beginning?

Yeah. Fantastic points there. Two things you mentioned. One is defining, which is a critical component of any transition at all. Anytime you're going to do change management of any kind of, you need to define some things, you need to define some parameters, you need to define what the outcome is. What are you actually aiming at? Because sometimes.

Oh, that's awesome. Yeah, I've never been, never been to the U.S. but hey, maybe one day I'll see Kevin's comment and I'll be able to say that I actually have visited. Anyway, so let's dive into kind of the main. Kind of dive deeper into the main topic here and let's kind of start telling the story of this migration. So where are we? We were talking about kind of the end goals, and now let's dive deeper into, like, how these migration projects typically start. We're here to talk about how these migrations fail. So, like, what are the first steps that are usually done and what are the first missteps that usually happen in this process?

Yeah, well, I mean, there's what's typically done and what should be done. Right, but we're talking about what's typically done. Yeah, what's typically done is a team experiences some pain, and I'd say it usually comes with growth of some sort. Not always, but usually teams are growing and they're starting to feel the limits of. Of their capacity or the limits of what's been built to date. Right. So what's very common is they go, well, it's the tool. We got to change the tool. Right. And this can be to tie it even to, like, personal behavior. Not that I'm a therapist by any means, but thinking about the levels of change, the first thing, and I'm the worst at this, is when I start to feel stressed or anxious, the first thing I want to change. Can you. Do you have any idea what it is that I go to change first? If I feel Stressed or anxious, like what do I go to control?

Change the environment, the situation.

Change the environment.

Boom.

You nailed it. You change the environment. Extremely common, right? We go towards, I'm stressed, I'm anxious, I need to exert some level of control. What's the most obvious thing I can control what is directly around me. Okay. So maybe I get to cleaning, maybe I start putting things away, right? So in professional services teams, teams that are using PM tools, like, that's one of those, like, well, this is my environment and I can change this right now and it'll help me feel accomplished. But it actually doesn't do anything. It creates more friction and frustration in the long term, especially if you don't define the end goal. What are the outcomes you want, especially if you don't standardize your workflows and processes. Right. So normally it's a matter, it's a, it's a, we're growing, we're experiencing those pains. Let's change something and hope it works, right? So it's a little bit shot in the dark, right? That shotgun approach. Let's just try to change some things and hope it works. But they never address the core, the core issues, right? So that's how they typically start. And the, one of the key problems here is assuming that the system itself, the tool itself will solve the problems. Right? It's kind of like, this is a super simple analogy, but it's kind of like you've got a, you've got a nail you got to drive into your wall. I'm literally looking at a nail on my wall right now. That's a picture should be there. It's not, it's like, you know, you got a nail in your wall and, and you need to drive it in with a hammer. So you go buy a hammer. Assuming that that fixes the problem. No, you just have a hammer now that you actually have to use the hammer and you have to use it correctly and you have to, you know, there's parameters to be done. Analogy breaks down at some point. But assuming the tool.

But if you never learned, if you never learned how to properly use a hammer, then it doesn't matter what kind of hammer you've got. Trying to kind of follow that thread, right?

Exactly. Yeah. You could have buy a $50 hammer or a two dollar hammer. It doesn't matter if you don't know how to use a hammer.

Exactly. Yeah. Yeah, I like that. Nicole, I see your question. Let me get to that in just a moment here, because I wanted to kind of tack onto what you said. Just a moment here, Derek. So, like, if this is the first misstep, let's maybe do one to one. Like, the first misstep is like thinking the tool is the problem. Let's talk about the flip side of this then. Okay. If this is the first mistake, what is the actual first step? What should you do instead?

Yes, great question. Yeah. And it's come up a lot, but it's to define. Define the outcome. Like, define your ultimate objective. And really, actually, you know what? Before that, I would say maybe it's not sequential, actually. You need to know what the real pain points are and dig into that and spend time digging into that. What actually hurts right now and why? I think that in parallel with the. What's the ultimate objective, what's the end goal we're aiming for? Like, both of those pieces are important. We've got to define what we're aiming at. Aiming at. And we have to define what's keeping us from getting there.

Right.

So both of those are two crucial pieces, and it has to be done at the beginning. If you fumble your way through that, you're going to waste time, you're going to waste energy, you're going to waste money. So you've got to define what's the end goal, what's the objective, and what's keeping us from getting there? What are the pain points and frustrations and obstacles, Tension in our team right now.

So I feel like that's pretty clear. And, you know, if you were to move kind of forward on that timeline with those two things locked down, what's the next thing that happens?

Yeah. So once you begin to. Once you understand, here's our pain points. Once you understand this is where we want to go, this is what we want to gain and get visibility into. The next step is not to go buy a new tool. Right. Which is what most people want to do. All right, we figure out where we want to go. Let's go. Let's go buy a new tool. Let's get this, you know, fancy, shiny new thing, which I get it. Buying new stuff. You get some endorphins, you get some dopamine, hit. It's wonderful. Right? But before we go do that, we've got to figure out, okay, if. If there's where we're going, and here's where we are. Before you map any journey, you've got to actually map the journey. You've got to create the map. You got to know how long is it going to take us. You got to know how many Miles away, is it? Where am I stopping for gas? Where am I having lunch? Where am I going to let the dog out to go pee? We got to figure out the journey before we start. And that comes. Yes, you're defining your objectives. Yes, you define your pain points. But then we got to figure out what is it that actually. What do we actually need? Because if you jump straight to tool features, you can miss some very important steps in the process. Because every tool wants you to buy their tool, so they're only going to highlight what they're really good at, right?

Yeah.

But you got to figure out what's most important to you, and that's going to come from your objective. Once you get your objective, then it's mapping. All right, how do we actually obtain what's missing in order for us to achieve that objective? So tactically speaking, this typically looks like we've already hit on this already. So apologies if this is feels repetitive. We've got to get clearly defined processes. We've got to standardize what we do because onboarding new employees takes too long. We've got too much information locked into individual team members heads, so that if they leave or they get poached, we're screwed because they have all our knowledge and they didn't document any of it. Right. So we got to document what we do, how we do it. We've got to figure out what's the information. We need to extrapolate at the end of a client project for each client, you know, things, things like that, those more tactical pieces come into play. But again, I would not, I wouldn't limit yourself to a tool. And just think if you're just brainstorming and dreaming, like, what, what would this, what could this look like? We got to create a map. We got to design a system that would be the next leg of the journey.

Yeah. If you never think about what you're ultimately trying to achieve, then you won't know what you're even looking for in a tool. Although the things that you're hinting at here, visibility, the ability to display certain data or information about your tasks. I think a lot of agencies ultimately find that, for example, a tool like ClickUp has the flexibility to be able to create those views or to filter the data with like, great granularity. And, you know, ultimately they end up going that route with ClickUp or teamwork.com, those are the two that we found work best for. For the agency context.

Yeah.

Now I think we've got a bit of a backlog of Questions here. So we're going to take a bit of a break from the main topic here to address the questions that are coming in. They are related. So. And I want to know your answers to these and I want more questions to come in because you've got the office hour with Derek here now, only half an hour left, so let's focus on those. Nicole, thank you for your patience. Here's your question and let's try to answer it. So jumping a little bit further in the process and getting quite detailed in it, but hey, let's tackle it. How do you cap the number of processes to document and templatize in an initial OPS transformation or ClickUp implementation project? Very curious about your answer here.

Yeah, good question. It's true that that list could be endless. And so you have to at some point reach a marker where you go, this is enough for now. And our approach to this is to define what you need to launch. What do you need in a system to service all of your current clients? Right now that's your needed for launch list and that would be the cap. Anything above that is bonus. Anything above that is like nice to have or want to have, but we don't need to have it to service our current set of clients. So that's the parameter there. What do we need to launch?

Okay, and how do you decide what's needed for launch? Is it the services that you're currently offering to clients or is it broader? Is it like anything that you could potentially offer at this point to clients, but it's not maybe in flight right now? Where do you set that line?

Actually, yeah, the focus is on your current set of clients. Like the work you're doing right now as a team or even in the last three months. You kind of look back at your last few invoices, contracts, scopes of work. Define from there what is it we are actively working on and that's needed for? Not like what could we do? Not what do we want to do? Not. We're unleashing this service in six months. If it's next month, you might consider standardizing that in that initial phase. But if it's further down the line, you want to punt that and focus on the work you're doing now.

Okay, and one more piece I'm curious about here. What would you say about internal processes? Are these must have for launch or is that something that you could potentially push for later?

Yeah, that's a team by team decision there on whether or not they want to include those as needed for launching because your client work is typically takes priority. Right. This is, this is how you're running the businesses from the revenue your clients are paying you. Right. So it's important to get those things right first. But if you've got some core processes, especially if they've been painful, like if you're a larger team and you've got multiple people that could do a single process and it's an internally related ops type process, then that could be a use case where you'd want to throw that on the needed for launch list. But oftentimes, you know, for smaller teams, it's one person doing a lot of those things and the loss there is of course, if you lose that person for whatever reason, then all that knowledge is locked inside their head. But normally those things are, those are items that can be delayed or pushed to, you know, after a launch and a migration to a new tool or a re platforming. So yeah, it's case by case really depends on your team.

Yeah, gotcha. I like how that connects to the point that you mentioned earlier. It's like if you know your pain points and you know that internal processes are one of your major pain points, then that's where you go. Although I would say like my gut feeling tells me like if I were running an agency, I would say the type of work where I don't want to drop any balls or I don't want to have any T's on crossed or I's on dotted, that's the client work. Because that affects NPS cores, that affects word of mouth, et cetera. Like, that feels extremely important. Thank you for the very smart question, Nicole. Great question, all of y'.

All.

Keep them coming. And we've got another one from Andrew. I want to bring it up and also kind of connect it with the main topic. So Andrew's question. Hi Andrew, nice to see you again because I think I saw you last time last week on our ClickUp HubSpot integration webinar. So the question, I'm going to read it first and then I'm going to add a little bit on top of it. The question is, can you elaborate more on the importance of the ClickUp champion role that our ZenPilot guide recommends and do you have any advice or personal experience for that role? So first I would like you to kind of share the context of like we're talking about how project management migrations fail. So why is this one of the missteps? Why is it one of the missteps to not have a clip? ClickUp Champion Teamwork champion or just a champion for your new tool? Why is that so important?

Yeah, yeah, fantastic question. Because in my opinion, one of the reasons, not the reason, but one of the reasons that PE migrations fail is that no one is held accountable to any standards or expectations set. So if you change tools, again, assuming the tool is the issue, we'll just get a new tool and everything will be great. But you don't define processes, you don't set expectations, and you don't hold the team accountable to whatever standards or expectations that should have been set, then everything falls apart and then you're back where you were, you know, in six months time, if that. So the. The importance of someone, and you can call them what you want. ClickUp Champion, agency operator, like business ops manager, whoever, whoever is going to be the person to help hold the team accountable to the standards and expectations and necessary, not desired, absolutely necessary to keep a system running smoothly and efficiently. Right. You absolutely need. You need that person. You got to have accountability. So my personal experience, Andrew, I. So I'm the only person on Zenpilot. I think this is true still. I'm the only person in Zenpilot's team who is a former client. So I've been in that seat in that agency operator, director of Project management seat as a former client who served as the ClickUp champion. And at that point we had transitioned from Asana to Basecamp and then Basecamp we were moving to ClickUp. And part of the value that Zenpilot helped me unlock was not just a new tool that had more features. They helped us define our processes, kind of get our operational house in order. Help me decide, here's how you should operate and function. Not just make suggestion suggestions, but actually be quite opinionated and prescriptive about if you want these outcomes, then you must do this. And one of those things was you have to have someone internally who can spot problem areas and issues and raise those flags to the executive team. So when we did that, our experience, for one, we doubled in size. From that point, we were about 25 people. I think we doubled in size and then got acquired by another much larger agency. So the benefits was massive. Because when my boss, the agency owner, came to me and said, hey, what's our team's capacity? I had an answer. Are we hitting our work? Are we hitting our deadlines? Are we not hitting our deadlines? I had an answer. What's our profitability look like? I had an answer. Like, I didn't have any of those answers before, but now I did because we had a well oiled machine and I was sitting in that seat holding the team accountable. Now it's uncomfortable. Okay. Especially for people that like, don't like, you know, don't like accountability. Don't like someone when it feels like you're, you're, you're leaning over their shoulder, breathing down their neck. And this is where you want to communicate why you have a role like this. Because it's not to micromanage. This is super crucial. It is not to micromanage. That is the last thing we want to do is micromanage. And that's some feedback and things we've heard before is like, ah, this feels micromanaging. Well, if you want, and this is where we want to tie things back to the objective. What's your ultimate end goal? If you want visibility into profitability, into utilization, into all of these things we've already hit on. You have to hold the team accountable. You have to. Especially as you grow, like the more people you have on the team, you have more and more people who have different ways of doing things. And we've got to get everybody on the boat rowing the same direction and understanding the same directions and standards and expectations. So I'll pause there. I can keep going on that one. But a lot of important.

Yeah, I hope that helps with the question, Andrew. I would throw in kind of the way I feel the ClickUp Champion role. I mean, I had that role without knowing I had it and then I stopped performing that role within my own migration a few years ago. I did not know about Zenpilot at the time and I felt like that's when things started to fall apart, that there wasn't this one person that actually looked into the system every day, checked compliance and then let people know about compliance. So on an emotional level, I'm going to say it like this. We've got a ClickUp Champion on our team. Hi, Gene. If you're watching this and Jean reaches out to us and the way this feels like you get a little message, a little nudge, hey, you've got this many overdue tasks in the system right now. And Gene is very positive about this. It's like, I believe in you, I believe you can clean this up. And I'll tell you, the initial reaction is like, oh, I know, I know, I've got that. You know, but at the end of the day, I was always thankful for Gene. I'm always thankful for our ClickUp Champion because I know that this is the exact pivotal moment when standards start to slip, when Data starts to become unreliable and when actually you start losing efficiency and your migration is on, is getting on the path to failure actually. So that is so crucial that there's somebody who gives you this gentle nudge, makes sure people are compliant because I mean, it's like you remember about the pain points and about the goals at the beginning of the process, you know, they feel so important. And then you're six months in, you know, you need somebody who kind of rights the ship course corrects every time. And the ClickUp champion is so crucial for that. So Andrew, happy to hear a follow up for that. And we can dig more into this in just a moment, but we've got more questions coming in. This is really turning into office hours with Derek, which I love. Keep them coming, especially since so far every question is from a different person. So we're helping a lot of people today. Olivia is here with a question that goes like this. As a current ClickUp user, we are struggling with creating management dashboards that will dial into an individual's tasks and priorities. Any suggestions? And first of all, let me ask if you need extra clarification here, Derek, we can ask for that. But you know, what would you say?

Yeah, well, without seeing your exact situation and you know, having a full on conversation about it, I would say, you know, in ClickUp you're. In ClickUp, everything starts with the hierarchy and that structure, space, folder, list, how that is set up is crucial. Everything flows downstream from that. So if you do not have a consistent structure where it's clear where all your client work lives, it's clear where all your internal operations work lives, things like that. There's not a clear structure. That's number one, you got to start there. Then you've got to define how you're going to organize and group the work and how you're going to assign the work.

Okay.

So we have a very specific and opinionated and prescriptive methodology for which we would tell you to organize your work. And the reason for that is because it unlocks what you're trying to do right now. It unlocks the management side of being able to get insight into things like what's a person's workload, what's their actual priorities? Right. And so our approach is you've got to assign, without trying to get, without getting into too many details here is you've got to assign individual tasks to individual people that have due dates and time estimates. Okay. If you have those three parameters there, like just start there. Single tasks assigned to single people. Okay? Individual People on the team that have clear due dates and time estimates. Gosh, this thing always gives me a thumbs up system setting. I don't know how I haven't turned off yet. If you have those three parameters on your tasks, that alone actually will unlock a lot of information for you. You'll get better visibility into workload. You'll get better visibility into how many tasks does a person have on their plate and. And help you prioritize the priorities. One, that would be one I'd want to dig more into to help and figure out. Like how do you define priority? How do you define when what is a priority and when something's not a priority? So, you know, without getting too granular, that would be where I would start. Make sure you got a clear structure. Get assignees, due dates and time, time estimates on all your tasks. Start there.

Yeah, I mean, the way this manifests in the Zenpilot system is that it all lives in the my tasks view. And one thing that I learned kind of since joining Zenpilot and diving into this system and now creating content about it, is that when you go granular enough, when you're specific enough, the timeline expresses the priorities ideally within the system. When you log into ClickUp, you have a list of typically subtasks, maybe with some parent tasks thrown in there. And kind of the ideal situation is, and the vision is what you want to achieve is that an individual contributor has these subtasks. They're estimated for an amount of hours that's less than eight hours or exactly eight hours, although exactly is probably a little dicey. And then you check these all off as done at the end of the day and that is your day. And it's of course it's important to like whatever is on the list for that day should be the most important thing for you to be working on today. And just in general. Right. But like once you get granular enough when it's one person, one task that can be done in one sitting, then kind of that becomes your list of priorities. Then you don't have to use for example, the priority flags and ClickUp so much because if something is less important, then it's not a task for today, it's a task for next week. And the timeline then becomes kind of expresses what should be worked on first and what should be worked on second, literally within the chronological order. I hope that kind of extra piece helps here, Olivia. Actually, I would love to spend just a minute or two more on this. Does that track with the way you prioritize? Derek Is there some additional piece here? When there's competing priorities, there's a decision making kind of process that you follow or encourage clients to follow.

Yeah, yeah. I mean, you hit some great points there, Kuba. That we prioritize and our prescription of prioritization is due date. And due dates are not suggestions. Due dates are promises, due dates are commitments. And so we want to take due dates seriously. That if something's due on a day, that's the day you do it and you do the work, you do the task. And we're going to, functionally, we're going to make sure that we create an environment in such a way that that's possible. Okay, so that should be said too. We structure our work in such a way that when a due date comes due, you can actually do it that day. So, you know, having those two parameters in place is crucial. But whatever. Nearly every agency we work with, they say, well, what about ad hoc work? What about client fires? What about emergencies? What about. Right, all those things? Well, if you know they're going to happen, then make sure you structure your daily capacity with that in mind. So rather than if, let's say someone does have an eight hour capacity for a given day, don't schedule them for eight hours worth of work for the day. If you need people to be flexible enough every single day to deal with last minute items, fires, client issues, whatever, then just block out that time. Or may not blocks the wrong word, but don't over schedule someone when you know you need people's availability to have one to two hours a day to deal with those fires.

Yeah, and the worst thing that's going to happen is if it turns out there isn't any fire that can always finish their tasks for that given day and maybe pull in something extra from the list for tomorrow. I mean, it's a win win. It feels great as an individual contributor to do that so you know, you can give them that extra win. All right. And I hope that answers the question, Olivia, keep them coming in. Right now I don't see any additional ones coming in, but we're also kind of rapidly approaching the end of our time here. So definitely, if you have additional ones, sorry, drop them in in the meantime. Well, there's a lot of things that we wanted to cover here and we're not going to be able to get through that kind of through my whole list of questions here. But if I were to pick one, I think this is one that is a little bit tricky for people is oftentimes what happens is the initial migration goes well enough and there's enough buy in. There's this big moment of migration, there's this moment of we're on the new system now and then things fall off over time. So I wanted to ask you about what would your advice be to avoid this pitfall of the issues that you were dealing with before the migration start just popping up again in terms of making the change stick and making sure that it continues to be a positive change and that your project management gets better and better instead of slowly deteriorating. Other than a crucial piece is probably the ClickUp champion here. Other than that, what is the key things to keep in mind here?

Yeah, other than the ClickUp champion, which would be probably the one I would harp on the most. Because maintenance is the key and this is system maintenance, this is individual maintenance. Like everybody has to understand their role within the system, the system of the team and the system of the tool, right? And so we've got to be able to clearly communicate the standards and expectations and then we have to enforce it. Okay? So accountability and maintenance is absolutely, is absolutely crucial. The other piece I would say that would be a major contributor in my mind is getting kind of total buy in from the team that we're going to continue to improve and iterate the way we do what we do.

Okay?

So again, putting the accountability piece aside, which is absolutely critical if you can get the team to buy into, hey, we're not just, again, we're not just trying to micromanage. We're not just trying to have processes for process's sake. Because nobody actually wants that. Nobody wants clear process. Unless you're like super type A and like that's just your world, right? It's like, I just want to be organized. There are plenty of people who don't really care to be organized, but they do care about what the actual end goal and outcome is, right? If we can connect to that, why and we can dig into and get buy in from the team that, hey, here's why, why we're doing this. Here's why we want to maintain a system like this, like ClickUp, like teamwork, like fill in the blank. It's because we want to be the best at what we do. And to be the best at what we do, we need to be as efficient as possible, which is going to help us be as profitable as possible, which is going to help us continue to give pay raises, hire top talent and get really, really good clients. Right? We've got to connect everything back to the why. Because we can't just show up and say, hey, we're changing tools, everybody, so you better start mapping processes and stuff. It's going to happen in two weeks, right? You're going to absolutely murder team morale doing that. Don't do that. If you're going to do any sort of migration, you've got to get by and you've got to connect to the why. Here's what the ultimate outcome is. And yes, it's going to take buy in, yes, it's going to take maintenance, but this is why it's important.

Yeah, that is so huge what you just said here, like connecting this to higher level goals. If we want to be the best at what we do with people's ambitions, I feel like that we haven't talked about that a lot on the Zen pilot live show before and I feel like it's a crucial piece of the puzzle here. Alrighty. I had one more question teed up, but I feel like I can see that we've got another one from Nicole. Let me just give it a quick look. Okay. Getting really, really kind of into the nitty gritty here, but okay. This is a live show and we want to help you first and foremost, why not pull it up and why not have this probably be the last question for today because it's a pretty meaty one and we'll start saying our goodbyes. So Nicole is asking, in reference to a single source of truth, which is extremely important, do you recommend SOPs written for each parent task or deliverable in a single document or for each subtask or action step to have its own documentation? The answer is neither. Right, or.

The answer is both. Because. Right, yeah, the answer is both. It's. It's not an either or. It would be. So think about it like that part of this depends on where your documentation lives, Right. So if you're in a tool like ClickUp, it can live all in ClickUp. Absolutely. But if you use Google Docs or you use again, notion, or you use some other tool to house your process documentation, you know, guru cards, for example, then you want to be able to do you want to be able to link. Ideally you're linking to the same source, but that it targets the specific step you're going for. So I really hate the answer, but the answer is both. And it also is. It depends because, you know, depending on. Well, let me try to give you an example. So at my last agency we did email marketing for e commerce businesses and for each step in the process we had things like develop the strategy Write the copy, design the email qa. Right. So each of those subtasks, each of those action steps had their own documentation. Okay. So copywriters could link out to here's how to write an email. And, and this is critical. Not just like here's how to write copy, but here's how to write an email within this framework, within this format of documentation. So that's very specific to a copywriter. I don't really care to see that. As a project manager, I didn't, I didn't need to see that unless I was the one doing the proofing and qa. Then it was. But those are the kinds of, that's kind of the parameter I would, I would probably set is like, what's the level of visibility you need from other people in the organization? And let that help determine its level of visibility in the parent task hierarchy. Parent task subtask hierarchy, leave it at the subtask. If it's like this is only relevant for this person, nobody else in this chain would ever need to reference this or see this, then you could have, it could have its own documentation. Anything at the parent task level. You need to think about does everybody in this chain or does the bulk of people in this subtask chain, this action step ladder, do all these people need to see what's on this documentation, even if it's just in part? Then I would make sure that documentation lives at the parent task level and that could be inside the task description in the parent task, or linked out to a Google Doc, a notion page or whatever.

Yeah, yeah, exactly. One thing that I also picked up on my zenpilot learning journey is that you have to think about two different kinds of situations. One where you've got somebody who might be doing something for the very first time. I mean, you're talking SOPs here. So that's kind of cl. Closer to that case where the documentation needs to be quite detailed. But maybe like Derek mentioned, that lives externally, for example, in Guru. And there it goes step by step with loom videos, et cetera. And if something changes there, then kind of Guru keeps prompting you to validate the information, keep it up to date. On the other hand though, you've got the people who have done something dozens of times, but maybe it's been two months since they last sent an email campaign or something. And then the ClickUp checklist feature actually comes in handy for the person who's done it before, but needs to just do quick QA on did I not miss any steps. Is there something kind of those details that can escape you in the heat of the moment when you're working on something. The checklist is great. I mean, I use this all the time for live streams, even where. Don't forget to send Derek the link for the Streamyard event. That was something that I found on my list this morning. I was like, yeah, I mean, I've done it before, but I always forget about this. I'm super grateful for my checklist, so I would throw that in as an additional piece and. Oh, dear. Oh, gosh. That leaves us with like five minutes on the clock for this session. Thank you so much, everyone, for the questions. This has been awesome in that respect. This session has been great in that respect. Now, I've got a final question for you, Derek. Is there anything else that you would like to add here in terms of project management migrations? You know, the work that you do, what you see, you know, the missteps that you see that I kind of failed to ask about, that you wanted to add in, you know, that you wanted to leave our audience here with. So that their project management migration is more likely to succeed.

Yeah, I would say. And we've been on a lot and we could keep talking about this for literally hours, but I would say I feel like we hit the highlights. We hit the highlights of. Number one, don't assume the tool is the problem, because I would say it might not be. And it's prob. It's actually probable that it's not. We want to use tools to like their, their, their, their to their limits. Like we want to use them to the best of their ability, but at some point, yeah, some systems break down. Right. Like, I personally would never suggest, and I love this tool, actually, but I would never suggest teams use Basecamp. It's too boxed in. Like, it's got a very prescribed way of doing work. But as an agency, there's all kinds of things that we can't unlock out of a tool like Basecamp. And I speak from experience because we use Basecamp. Right. Don't assume the tool is the problem number two. Really understand your why. What are you actually trying to achieve? Well, what do you think a PM migration will solve? And start there. Don't assume the PM tool change will solve it, but actually start with what are we actually trying to solve? And literally explore every other possible way. And as you're doing that, you want to do a cost benefit analysis here. Like, what's the. What's the. What's this going to cost me to make a change? Like this. And is the benefit enough to make that change? And if you do decide, after you go all through this and you decide, you know what, yeah, we need to do a platform change, or maybe you're on a platform, ie, like ClickUp, and you decide we're just using ClickUp all wrong. We, we need to, you know, re platform on the platform itself. We need to rearrange and rework everything and we need, and we need help doing it then by, by all means, like, this is what zenpilot does. Like, we're experts at this. And I like to use the analogy of like, if you're gonna go climb Mount Everest, are you going to go do that by yourself? Probably not. If you're going to make the investment to go try to summit the tallest mountain in the world, you're probably going to hire some help, you're probably going to hire a guide, you're going to spend months training, you're going to get all the expertise you can so that you can make that summit successful and you can actually stand on the mountaintop and go, oh my gosh, I'm so glad I did all that work beforehand so that I could be standing here with this, you know, iconic moment. Right. If you're going to do a PM migration of any sort, I would suggest you do the same, whether that's Zen Pilot, whether that's somebody else, like get some outside help. Because I promise you, you don't know what you don't know. And don't be so overconfident to think we'll just figure it out on the way, because I promise you, you're going to spend the time, energy and money over a much longer period of time if you try to go figure it out yourself rather than hiring an expert and letting, letting people help you. So even if it's a coach, you know, hire a coach to help help you work through some of this or hire a consultant or hire somebody to help you achieve it. Ideally you're hiring Zen Pilot, but, you know, that's another conversation.

Yeah, exactly. This goes back to the subject of accountability, actually. You know, you've got somebody accountable internally for the change and that's needed. And you know, we recommend that very strongly. But it always pays off to have somebody, you know, that you hire. And it's like their whole, whole goal, their whole life is to make this project management migration succeed for you. So that, I feel is quite key here to keep that in mind. And hey, if you want to get in touch with us, just go to zenpilot.com call just zenpilot.com is a great place to be if you haven't visited yet. We've got a lot of in depth guides on how to do the project management migration, even yourself within ClickUp or within Teamwork. There's like full 40 plus page ebooks that we've got available for download for free if you want to check that out. All right, as you can see, Derek, I'm getting into kind of the CTAs here because that is part of my job. Well, first of all, thank you all watchers and listeners for joining. So here's a few suggestions on what more you could do to increase your chances of your project management migration succeeding and to make your agency more efficient. Right. I wanted to add one last piece in. You mentioned cost benefit analysis. On a previous livestream I heard something really cool. I think it was from Kevin, our account executive, where if you think about it, if you're not confidently able to answer the question do we have capacity to take on additional clients? Then if you become able to answer that and you see that you actually have and you didn't know about it, you have an extra slot for a client or two, then the ROI just pops up right there. When you realize that you can actually take on new clients, that is revenue coming in and a transformation with Zenpilot or whoever else just becomes an easy proposition there. But hey, if you want to talk about the details of that for your situation, zenpilot.com call. In the meantime, if you like this, we're streaming tomorrow as well. Check out ZenPilot on LinkedIn. Okay. Everything that we're doing is there and we try to keep it up to date as much as possible. So under events you'll find that we are streaming tomorrow with Andrew Dimsky, Zenpilot co founder and legendary excellent person. We'll be talking about tracking profitability and utilization in ClickUp. We got some advanced questions here today. If you're interested in dashboards, if you're interested in like ClickUp source data and being able to actually answer some of those visibility questions in detail. We'll be doing a live demo with Andrew of a solution we've built on top of ClickUp that will allow you to see that for your agency. Stuff that ClickUp historically hasn't been great at. We've managed to find a way to to actually surface that data. It all builds on top of what Derek said here, that you actually need to have the right habits, you need to use the tool properly to have that data. But Anyway, it'll all be on the live demo tomorrow. And one last plug if you want to stay in touch with Zenpilot, if you want to get emails from me about what we're up to with our best content and some non Zenpilot content that I find around the web that's useful for agency operators. On Zenpilot.com, you can find under the resources dropdown. First Class Operations is the newsletter that I send out every two weeks or so and you'll get updates from me about what we're up to and our best content right into your inbox. Also with some general life stories and learnings from me. I talk about my grandma there sometimes and what she taught me about business and life. Anyway, so that's the recommendation for you. Thank you everyone so much again for joining us here today. Watchers and listeners. And Derek, thank you so so much for sharing your knowledge here today. This flew by so fast. This was awesome and we should definitely do it again.

I agree. Thanks Kuba. Appreciate your time man.

Yeah, thank you Derek. Thank you everyone. I'm going to hit the end stream button everybody. Have a nice day. Bye bye.