Effective Project Management: How to Grow High-Value Partnerships

I'm calling myself a strategic technical leader these days, just because I feel like I've been in the industry for long enough. You know, I can do a lot of stuff. And I started out as a developer. Uh, you know, I felt really strongly that in order to lead, I got to know how what's involved, what do you got to do? And I love development so much. I stuck with it for, like, probably longer than I really needed to. Um, but, you know, I really got into more project management halfway through, and I think that had a lot to do with, um, doing the freelance consulting for quite some time. Um, and I found that a lot of my clients weren't necessarily needing a whole lot of technical help. They were really needing more strategic help, help making those decisions, get them to the next step, find the right resources. Make it happen. Right. So let's get started. I would say that this is kind of, um, going through the I do apologize one moment here. I'm just realizing now that I don't have the slideshow notes on a separate screen, and I want to put that up here.

>>:
There we go. So getting started. What I'm talking about here is really getting started with your project. So you know, when you're getting started with your project in your new business cycle, you apologize. Let me go back. This is not ideal. Okay. In your new business, um, cycle, you should have after that initial sales agreement or even in the middle of the sales agreement. Ideally, to be honest, some sort of conversation that's happening with the operations team, right? Let them know what's happening up front, what's going to happen, what's upcoming. Prepare your sales team as well. But really this is about having that sales sand off hand off after you have, um, signed that contract because you'd be amazed. You'd be amazed. I don't know if you've experienced this before and we can talk about it. How many times a project manager will receive a contract. Now the sheet, the actual thing that was signed, but not a whole lot of context around strategy that the client was looking for. You know, the whys, the what fours, the what next, you know, that sort of thing, and maybe even personality stuff about the client, you know, things like that, that, you know, you've won the client over having this, you know, particular relationship with them, but you might not have built that up with a project manager operations team quite yet.

So you should definitely have included in your sales handoff, I think just the terms and scope of the contract. But also, you know, this fast follow should be a sales intro with a client where the project manager is discussing an overview of that project timeline and or the steps discussed. So let's get into that a little bit more. And so, you know, this is kind of an example of an email that you might send to an existing client. And, you know, we're excited to see you come with on with us. We're wanting to see if you can get together with us, sort of standard email messaging here. But the the point is, is that at this point is when the project manager is really taking over, getting involved, and depending upon the nuances of it, you might have the sales team actually send this email. But more or less, this is the very first thing that has to happen with that operations team is to set up that that exist, that initial kick off workshop. And you might also think about including because you're scheduling with this email, you know, your actual kickoff workshop, um, an optional statement about inclusion and accessibility.

I think that that's definitely been more of a, of a question these days is does any of your members, stakeholders, people that are going to be on the call need to have, oh, I don't know, five minute break every 30 minutes? Or do they have any accessibility concerns that would need to be aware of to make sure that we're, you know, adhering to to that need as well? So there's that. Now, you know, I say I would say that at this point.

>>:
Let me see if I can do this again. There we go. So I'm curious to know, what do your initial communications after sales look like? Um, how many maybe were show of hands of project managers here in the room? Specifically, would you say that you run projects as a project manager? Any anyone? You just the one. Two. Sorta. Sorta. Okay. So what are those initial communications, you know, with the handoff look like for you guys? Is it an actual email? Is it a meeting? Is it, you know, how does that work? Do you do that sort of thing? Yeah. Similar.

>>:
Yeah. I mean typically emails where just, uh, a statement of next steps and confirming. Next steps. Things we discussed expectations, things like that. Okay. Okay. Similar for you as well. Yeah.

>>:
Usually before that happens there's a sales handoff where it goes from the sales to the project manager. Then once they feel educated enough then the project manager initiates the initial kickoff okay okay. Yeah. So I think that's kind of what this was designed to be to is, is you know, the PM is doing that after the initial sales handoff. Yeah. Um, so very similar. That's good to hear. Um, honestly, you know, I think that I'm not seeing it everywhere. And to see that it's happening here is awesome. So let's talk about that kicking off. And maybe this is not something that you would normally, um, you know, do as formally speaking. Uh, but during that kickoff meeting, you know, it's just you're going to meet with the business, you're going to get your primary people on both sides to get in the same room that's involving operations and any, you know, I would say probably the lead developer, lead designer leads on on the agency side, um, to really have the first sort of, you know, come to Jesus moment where, you know, okay, we've signed the contract, but this is what we really want.

This is what we really need. This is really where our focus is. And let's all get in alignment on that. You know, I think that it's good to know, though, that, um, that when you're doing this kickoff, you're just not going to know all the information that you think you're going to know out of the contract and even out of the sales handoff. And so having as many multiple touch points with the client as possible, especially during the early phases, is important. So what I'm getting at here is that when you get in that meeting with those clients, you want to make sure that you are covering all those topics. And those agenda items might include, uh, team member introductions and icebreaker activity. I found that to be very helpful as well. Right at the beginning, you might pick a fun sort of question versus like, what is your favorite hobby? That's kind of the standard one that everybody uses, but more like, what is your favorite movie or something like that and gets people talking, you know, breaking down those walls, what they're looking to get out of the project.

Like I was saying before, any potential challenges they might have, this is where you're going to get some nuances that you might not otherwise. Internal politics might come up. Opposing goals might trickle out between the stakeholders that are on the call that you didn't know about before. Now, as a facilitator, you still want to control that. You know, you don't want to have a fight happening on your kickoff call or something like that. But you might, you know, get some of that teased out during this initial communication. Client facing, uh, a success point that I would probably point out here is that it really just provides the client team members with the opportunity to develop new and possibly long term beneficial cross department relationships as well. So I've had a situation or two where, um, these stakeholders have never worked with each other before, and it's the first opportunity for them to work on a project together. And so you might be able to set the stage with them and really move that business relationship forward internally as well.

For them. Um, there might be optional discussion around meeting cadence, you know, that might or might not be appropriate during this kickoff call just to set up some expectations. I tend to do so myself. You know, I think that you can get a pretty good read on previous communications as to and the scope and milestone frequency velocity of the project. Um, to get an idea of what that meeting cadence might be with the client specifically we're talking and so that might be another topic to discuss. Okay, so I know this is all basic project management stuff so far. Bear with me on that. But I would say that next really the internal the internal is also equally important. You know, I'd say that, you know, a focus here on the internal. Let me get back to. Okay. Is to get all of your team members on your side, on your agency side, to get to know each other. First of all, again, you know, not everybody's going to work with everybody all the time. So you want to do your introductions. You want to do a client overview, really doing an onboarding for all your people.

Now this is not just the leads on the agency side. This is everybody. Everybody from all the development team, everybody from the design team. And yes, you may only have one one of each, maybe not one of all of those roles. You may have multi role people on your team, but it's important I think initially right at the beginning before you even get started with anything to get people familiar with each other just so that they know who to talk to and that they're friendly and open to be able to do so. So other things to cover timeline and scope, you know, general onboarding, like I was saying, to do with specifically project resources. You know, I think that a lot of times you'll find a project will come over to the team and they just won't have like simple stuff like, how do I get to the git repo or how do I get to the proper project board, or what's the client's web current website URL, you know, so gathering all that information together for them and having a meeting about it, I know that not everybody likes having multiple meetings all the time, but I think this is an important one and it will help to align that team on that as well.

Here you will, you know, need to discuss also the alignment on roles and meeting cadence roles, meaning, you know, I think it's not always clear, especially in the agency world where a certain person or certain team of developers, you know what role they're playing on that particular project, because you get a lot of senior, especially a lot of senior developers working at the same agency. And yes, there may be a differentiation between front end and back end, that sort of thing. But what they're doing on that particular project and how they best may help, you know, I think it's good to discuss it with the team on a call like this so that we're all clear on who's doing what and when and why. Um, not that they can't step out and make suggestions outside of that role or anything like that, but it's just more of a who do I go to for this? And who's the authority on that? And you know, who's going to be responsible for what. So also meeting cadence. But I would say that again meeting cadence is probably largely, you know, similarly um, you know, defined by the project scope and milestones and velocity that's required.

So you're going to, you know, do your meeting cadence based off of some of those factors. But, you know, depending upon your agency as well. And I'm not sure the sizes of your agencies. And we might share some of that here, um, at the next Q&A portion. But I would say that it does depend on what your agency sort of structure looks like as to what that cadence should be. And some agencies, I've found that the developers have five projects, you know, that they're working on at the same time. It might be ten projects that they're working on at the same time. Some of them might be support, some of them might be build, some mix of the things. And depending upon that team and how that structure is, it may guide, you know, how frequently throughout the week what part of the week you know, you might do some of the meetings towards the beginning of the week for one project, towards the end of the week for another project, that sort of thing. So you just want to decide on that. You want to decide on what that meeting cadence will be.

And like you were saying, defining next steps, identifying your resourcing needs. If you have any gaps that you might not have realized. And depending upon the size and complexity of this project, you know, if you have a large matrix situation going on, you might break this up into two separate ones, ones that's more scoped to what the leads need to know, and the separate one, or even separate ones for the individual teams that will be involved, where you might have more of that rah rah sort of situation going on. Awesome. So let's move on to the next here. You know, I would say that, um, after kickoff, it's easy to lose steam. I think I'm kind of getting some sleepy eyes in the audience. Losing steam right now, too. No, I would say that after kickoff, you know, it is easy to say, oh, I know everything now, and I'm going to have to wait for a month before I get to really be individually involved. Right. And so how do you keep that, you know, that relationship and that understanding going into the next?

You know, I think this is not only on the internal side, but specifically on the on the external side. It's important to keep that conversation going. And you might use some tools like RACI. Um, I'm not sure if everybody's seen a RACI chart before, but sounds like many of you have, you know, just in general to think, you know, how often what type of conversations that you should be having with which stakeholders this I think can be applied internally as well. You know, similarly, you're going to have certain individuals and leads involved in certain levels of, of complexity and or decision making. And so thinking about things in a RACI way might be, you know, an exercise to go through. That's a mural template if you wanted to grab one. And these slides will be available or are available up on the website as well, if you wanted to take it from there. Um, and, you know, just to, just to keep in mind, um, that that's still a pretty good exercise to go through. Uh, it's not absolutely necessary.

You know, I think that if you run it through quite a few projects, at a certain point, it just becomes natural to ask the right questions about the right things and set up the right things without actually having to have a chart. Um, but it might still be good to go through the exercise for others, because you're not always going to be on a clock. Somebody else might need to come in and have an idea of what is going on with your project. So not just having a list of contacts, but having a list of contacts and what they're responsible for. So there might be an integration project, and this particular individual is involved with that HubSpot integration that you have going on, whereas you have your primary stakeholder who's involved with the day to day, that sort of thing. All righty. I know we're not in the question and answer part here quite yet, but almost. I would say that there is another Next Steps email after the kickoff. It's important to mention you know that next step focus. So I'm really happy you said that.

That pinged with me a lot. That's a big selling point for me is the focus on next is really important. This is how you keep it going. It's not just about what happened, which is good and you should retro and things like that, but it's really about that. Focus on next asking the right questions, giving the right information, providing that status is also important on progress. But really the focus on next, I think just keeps the ball rolling in general. All righty. So this gets into now more like the differentiators, I guess you could say that I found to be really successful. Um. And I know I was going to say, we're going to have a Q&A and I didn't have a Q&A, so maybe we'll take a breather here for just a second. Any particular things that resonate with you about the kickoff portion or the keep it going the next that anybody has any stories that they're thinking in their head about right now? Nope. Nope. Okay. All right. I'll keep on going. Huh? So on discovery first, what I'm talking about here is that I think in a lot of projects you can really suffer from, like what I call the, well, what is commonly known as the cart before the horse syndrome.

You know, like, you just end up inadvertently subjecting clients to smoke and mirrors type stuff, and they're not really sure if it's going to be the way that they want it to be. And maybe the meeting frequency is a little high without a whole lot of output happening, you know, and they're like trying to see, you know, what the actual, um, uh, output is or what the result is of the money that they've handed you. Right. So to avoid this, it's imperative to have a set of clear criteria towards those project goals, you know, as part of your contracting, as part of your initial kickoff and milestones and time lining. But then it helps to bridge the gap between the research strategy and implementation portions of the project. I've also found, and we'll get into this a little bit, that it's very important to have demos at points that you didn't think that you should have to have a demo like. I think that there's a lot of times where design tends to have this habit of wanting to take all of these things and go and be creative and come back out on the other side and go to.

Here's the thing. And then you go and present it to the client. And they have questions. They're not sure about that. And it's a lot for them to digest and all of that. So you might even think about breaking up some of that with your discovery first approach. So with the discovery first approach, just to give you an idea here, what I'm talking about, if you're in a world without the discovery first approach, you'd initially do your sign off and proposal proposal and sign off. You'd get your design and POC going and then, uh oh, we have some stuff that we forgot about. So we have to go back before we even really deliver anything and ask for more money. And we go back to design and POC and maybe we can do a build at that point hopefully. Right. And hopefully we're not going to have more too many more of those after this initial uh oh experience that we had here. Now, there are some times when, you know, it's legitimate that after build or during build that you're going to find an out of scope situation.

And as you have that more well defined, you know, during your build process, it's easier to easier to sell a change order at that point. So I just wonder, has anybody experienced that before where they've built a flat rate something and it didn't quite go the way that you thought it would. Yeah. Yeah. Okay. And uh, you know, then it's just not a great position to be in partnership wise. You know, I think you kind of sour it from the beginning and you have to recover from that. So let's not do that. How about that? Let's try to do this instead. Let's go with our discovery first approach and with our discovery first approach. Let me get my notes up here. Again. What we're doing instead is a requirements and envisioning portion here. Um where. You are then taking that information and you're doing an iterative process. That's what you're doing. You're getting the information that you think you need and you're going to start building immediately. So we're talking about the POC and we're talking about framing this as this is discovery.

We are not doing implementation here. We're doing discovery. We are building a POC. We are iterating on that POC. And then once we get through this process of building, of iterating and then building, we can deploy and roll out. So this is really fast. Sort of like way to show you a lot is going on here. This repeat in the middle is the big part. That is a differentiator that what we're saying is we are going to do a discovery with a design or high level designs. I've had that before where it's like a very clearly defined high level designs. And then we do a second phase where it's more refined designs as part of implementation. Maybe, maybe, maybe it's a three phase project, but breaking it up like this makes it more palatable, more deliverable. The client can, at any point in any of those phases, get up, walk away. So it's actually a really, you know, attractive thing to a lot of clients. They don't have to promise $1 million. They can only they only have to promise so much. But you really honestly get a lot out of a phased approach because with your phased approach.

This is what you end up with. Situation where you might have multiple phases going on. Requirements. Phase. Envisioning. Phase. Build. Phase. Deployment phase. Rollout. Phase. You could have all of those. Now, it may not be that many. I mean, reality is you probably can only get your clients to do two phases. One is like your requirements envisioning POC phase, design, high level, that sort of thing. Second would be your implementation, deployment and launch. Right. But I would say that, you know, if you can think of your phased approach as giving them deliverables out of each phase, you're likely to end up with more dollars at the end. I'll be honest, and you're going to have a great partnership. You're going to have something that's going to last you for a long time. And this is because you've built up this knowledge, this support, this trust with those particular clients. I hope you fell down. I knew it would. And they are going to want to come back for more. And everybody wants to do more.

Well, I mean, you don't always want to do more with every client, right? Some of them are not news. But in a perfect world where you have built that client relationship, you're setting up for success. Now, every contract is a contract. You can also walk away if it's not working out. You know, early. You don't have to do the nightmare you get to choose to. And so I think, uh, maybe this is where my freelancing sort of expertise comes in. And I think it really does work well with agencies, um, when it's implemented. So on this phased approach, just to give you an idea, you have your deliverable here and on that deliverable, that phase you're sprinting through on that deliverable. So again, even in design phase, even in a strategy phase, even in a early phase, that you didn't think that you have a deliverable on, think of it like its own independent deliverable project that you are negotiating with the client throughout the throughout the phase. You're demoing to them throughout the throughout the phase to give them information on what's going on, make sure that you're still aligned on the same objectives, you know, and if and the more you know or the earlier you know, the less overhead you're going to have as well, the more room you're going to have to have little wins.

I would say in general, you know, where you can have a little things that will come up that you can fit in. We're doing that thing already anyway. Why not just do it now, get it over and done with? It will not be a sticking point later when they're saying, you know, I really didn't like the shape of that button, I want it to be this kind of button. Why didn't we get that button fixed five weeks ago? You don't want to have that conversation. You want to have the one where we're moving on. We're next stepping out of that conversation and getting on to next. All righty. Enough lecture. Let's ask a question again. So has anyone worked with a multiphase project like this before? Yeah. I'm going to talk with you later. You seem to have a lot of alignments with me. I mean. We're, you know, we're agile ish. I mean, there's a guy at our organization who I think is, you know, who I believe wants us to be more by the book agile. But, um, you know, also, I'm more on the client side of the, of the equation here.

Uh, but with our large, like, website code distribution initiative, it's very agile. You know, we have to manage at least two releases we don't really manage to suppress. Um, but, uh, but yeah, but then there's a smaller internal website application where we're following this model more. It's definitely phased. Um. And are you demoing frequently with your clients in those instances going to do it? Just do it. Yeah, yeah. No, I'm sorry, you were saying. No, no, no, that was it. Yeah. Anybody else have another story?

>>:
Actually, I feel like oftentimes my project team would prefer to, like, flesh out the discovery or do, like what you kind of mentioned with, like, a mike, like a little discovery phase, at least. Yeah, but it's hard from a client perspective. Like. Or from a sales perspective. Yeah. Um, because clients want to know what the end cost will be versus like. And I can see I've seen it happen too, where we don't really cover everything in the scope that ends up coming out in the discovery. What I found for sales for that. I don't know if this is your question or not, but I found that it's good to, you know, early on in your internal kickoffs and internal meetings before you, you know, really dig in to any sort of big things. Um, um, you know, I think this is almost really before contract sales, right? So we're talking talking to the director of operations, the project leads and getting them to really think about, from an estimation standpoint, what it's going to be to do a discovery that's your biggest, you know, sort of question there on your contract.

But really, again, also what do we think may be the entire thing will be and you can, you know, throw that out to the client. We think that it probably will be this, but we're not comfortable with contracting at that large amount until we have this initial with you. And I think they'll be like, well, why don't why are we going to go with you if you don't know how much it's going to cost? Right. Yeah. Um, so you just, you know, I think that you really just have to speak to the deliverables that are outside of that particular phase. You have to say, well, to be honest with you, you know, we don't know if we can. Not that you're going to say this exactly. But on our side, I think we don't know if we are going to be able to deliver all the things that they want to dream up within that particular budget that they're looking for. And so it's it's important for you to discover that that part of the process and just be strong with it. So from the client's perspective, what you're probably selling to them is saying, hey, we care about you.

We want to make sure that this is going to be right for you. We want to make sure that we're right for you. And so this is for your benefit to, um, you know, go through this process with us. We will target that big, large price that you're looking for. Um, and that might be budget. You know, it's understandable. They might have a certain number of dollars set aside for a particular year. And that's just their hard, hard line, right? Right. Yeah. And if that's the case, you know, still, you know, you kind of have to work with that with the, with your internals and whatever else and make it work. But it becomes a different kind of conversation. It's not, uh, how much is it going to take or how much can we do to get it done within that budget, as much as breaking it down into phases? It's easily like sort of estimated and understood internally to say, well, I know I might not know the everything, but I know that once we get through this part, which I know is going to cost this much, we're going to have a better idea of how we're going to or what we're going to be able to recommend to them at a strategy.

So it gives you this sort of leverage where, you know, in strategy, you can say, well, I know they asked for the world, but within their budget, this is what we recommend that will still get them to the to success goals or major success goals will still provide. That partnership will still have things because there's going to always be things. The thing that you've got to remember is that there will always be things right after the thing that they wanted you to build, that they're not going to have right away because of XYZ. And it probably isn't even your fault. It's probably because they have to make business decisions and you're going to help them make those business decisions, whether. You're not, you realize it whether or not you're actively involved in helping them make those business decisions. You are right. So go ahead. So I think it gets really down to the philosophical down to what is the proposal and what is the difference between a projection and an estimate. And because we've had proposals where we've made a proposal, we've gone out to them and then our team looks at it and they go off and work.

They don't sit there and spec everything out. They say, I was working off the numbers from the proposal or the numbers off. The proposals were grabbed out of the air. And you know, we're a peacock, right? We're like, hey, look at us, look at what we can do, right? Yeah. But you, after you get the client, you sit down and you just spec it out. You need to figure it out. And if we don't have enough hours and it's a fixed bid project, that's not the devs fault. That's the salespeople's fault. And you need to have a conversation at that point. You need to get through the project, and if they ask for something that's not in the scope, absolutely jump all over that. Whereas if you expect it, if your projection is better, you have more leeway. But if you if you don't have any leeway, you need to be really good about saying, don't have money, change order, don't have money, change order. And then you have the conversations with the sales team. Where do you get these numbers? And then you have the conversations.

Well, it'd be nice if we could have a deficit and do this. We don't have time to have a deficit and do it. Yeah. You make a great point. So yeah, as far as contracting goes, you know, I think that when there's a larger amount of risk of being able to do all the things, you got to be sure what the things are requirements are, and then you got to make sure that your team, um, is on board with that, whether it be you have the resourcing or need to get the resourcing, or if it's because you need cheaper resourcing or whatever the solution is that's separate really, but you still need to be in alignment, right? With like what? What is going to be involved? And does that align with the the price points that the proposal is sort of thing? And I'm not sure if you're dealing with RFPs so much, but um, I don't know. I kind of almost like art piece for that reason because I think it's a little, little more clear sometimes. No, not not okay. I'm sorry. Never mind. Like lots. No, I've had some government ones where it's like, we know that it's going to be more than this.

Yeah. And so it's like they know that the proposal, what it is, is really just the initial sort of research and discovery thing, you know, that sort of thing. And so many digital agencies are we're not responding to an RFP. We don't respond to RFP. I don't know. It's a good reason why they don't. Yeah, well, there's a lot of work, to be honest. There's a lot of paperwork involved with former case, so. Okay. All right. So. This is where my session ended. Last two times that I did this. That was it. But you're going to get more today. Um, this is more about like, the internals. And I think that this is equally important to really consider as well. I think that one thing that you run into a lot with the success of a project is, is so relevant, but the success of a project is making sure that you're taking care of your team. And it's not just your internal team, it's your external team as well. But I think it starts all internal. You know, you really have to get your team to be able to manage their own time, be able to manage their own workload.

And there's some tips and tricks that I have for that. If you're interested, I can go through this, but really it's all about avoiding that burnout because the last thing that you want is for your team to lose focus and not get things done. Now, part of that will be your cadence and ceremonies. And, you know, you really have to figure out that frequency and saturation of of your meetings, your touch points, your stand ups, your retros, your things that you're doing with your team. And then you also need to decide on your sprinting. This involves scrubbing estimation placement. Now, I don't know about you, but during sprinting, a lot of times I found that this part is not something that you think you have the budget for or the time for, but you have to. You have to do it. Somebody has to do it. And now if you have a technical project manager, you might be able to get it with it, with not having the whole team involved with this part. But you still should have them involved, because inevitably you're going to send something down the road and bullet right to them and they'll be like, what's this thing?

I don't even know what it is. What are you trying to get me to do? And then you have a problem. So you want to do that? I want to do your stand ups. You want to do your demos, and I'm talking internal demos. You want your team to demo to each other. Why not share? You know, design team to development team, development team to design team. Initial development team to non-initial development team integration team to non integration team. Share it. Show what you're doing. Celebrate. Who knows? You know what you might learn where you might improve your skill set internally with your teams as well. But demoing is important. It's not just about rah rah, it's about real serious stuff. Hey, wait, did you remember that part? I don't know what was that again? This is where it comes up. And then you want to do your retrospectives. This is another portion that I've had a hard time sometimes getting management to be on board with, spending time on retros. To be honest, teams want it. Just give it to them.

Why not? They're effective retros. You get to talk about all the things that went wrong, all the things that you would have liked to have better, all of the things that you suggest to make it better. And then you have action items. You can make it better. You can make your team passionate or re passionate. Had a difficult problem last sprint. Let's see if we can make it better this time. Whatever it is, it could be velocity could be a specific challenge that they had with technical stuff. Could be another team that they were having difficulty with getting a thing from might be blockers. But really, I think still, even with those retrospectives, that's why I like them so much, is it's that focus on next. You know, it's all about turning them into action items that you can really deliver with your team so that they can be focused on the work, on the creative part, on the fun stuff that everybody wants to be passionate about the project and move it forward. So this is kind of like, you know, give me a vacation plan.

This is part of that. What is your setup or what is your internal communication plan look like? Do you do what. Is there anything specific you want to mention there, or is that pretty in alignment? I just had a question. What is the the scrubbing of the placement? Oh, sure. Let's see if I can go back. Where did I go? Oh no, that's not back scrubbing estimation. So scrubbing specifically. Uh, yeah. Both those like estimate like estimation. I assume that's like the. Estimation of tasks. Yeah. But then the scrubbing of the placement are new terms for me. Sure. So what I mean by that, and it may not be an industry wide term, but scrubbing meaning like going through the initial triaging of the ticket, creating it, fleshing it out with acceptance criteria, having a technical approach, um, you know, just making sure that it has all the things in order to really start, okay. That sort of thing. Yeah. Gotcha. Make it actionable. Yeah.

>>:
So scrubbing is similar to backlog refinement. Yes. Yes. Okay. And is the placement the um assigning relative priorities. Yeah. Well and I think I'm talking more like placement in a sprint when I say placement.

>>:
Oh okay. Okay. But yes, it could be priorities. Prioritization. Sure, sure. And it depends upon how many sprints you're going to plan out and where that, you know, if you want to do the backlog thing and really heavily rely on just pulling from the top of the backlog into your next sprint, you know, there may be different ways of managing that for sure. But yeah, that's what I meant. No problem. Um, for retro, you talk you talked about like what didn't work and other things like that. And I just want to add on to that, that retrospective, retrospective meetings are also a time to talk about what did work and what you want to see to continue into the next iteration. What did work. Thank you. I didn't put it on the list. I rattled it off. Typically just. One of those words like, yeah, let's you see what failed, but also. What worked well, what. Works so that everyone can be like like because like in my team, um, very recently I've been siloed doing some like, very niche work, not working with anyone else.

Um, and someone called out a thing that worked really well for the entire team. I was removed, not bad. Just I ended up doing siloed work. I'm okay with that. Whatever. But, like, I had no clue that that thing was going on. And because they called it out as a positive thing, I'm like, I don't know what the hell that is, but I want in on this. But you're there at that retro and you got to hear about it, right? Sweet. Yeah. Now, what worked well is, is definitely an important part of that. What didn't work, what, you know, could have been better. What really worked well, you know, all those things. And then really I like to focus on what can you do about it apart. But that's for.

>>:
Me. I've had really good luck with retrospectives. Um, having a retrospective doc that's defined, like the template ready to go at the beginning of a project so that as something good comes up, you want to thank someone, you want to acknowledge that something happened or be like, oh, this really didn't happen. It's usually best to get those details down when it's fresh. And so having the doc and yeah, if someone shares something like, oh, this doesn't work or oh, this is great, I'd be like, hey, here's the link. Like, please go add your details in and then. As a project manager. Then later I have to go back and like maybe group some things or like do some refinement in the doc before having the kickoff call or the the retro call with people. Yeah, it's having. Having a place right to put that. Yeah. No, I've seen that. That works well. Um, I think it depends upon your team and where their where their head is at. Not all teams are, like, thinking that way. They think kind of stored up in their own head until the end.

They don't even know what it is until they're closer to the end of the sprint or after the demo. But yeah, making it available, why not? Right? So maybe at the beginning of the sprint, just make all your docs right away and. Make them available. Why not? Cool. Any other stories about this? Sweet. We'll go on. There is another portion here. Getting in the flow. This is more like, I think from a project manager perspective. This is a big part of my job is to just, you know, get in the flow of how this is all going to work. And managing time is a big portion of that. I can do the things, the things happen. There we go. Time management. So this is where, you know, you want to plan and focus your own time. Um, what I like to do is a lot of color coding. So on my calendaring, on my browser tabs, on my project lists, all color code like usually based on clients. I'll be like, what's this client's main color? And I will pick that for everything. And so that it just makes it easier to browse through the different things.

And when working on a specific task, um, you know, adding a key to the event, like what I was trying to say here is if you're in a JIRA space and some or other non JIRA project management software, you may have some integration that can take place between your project management. Software and a time tracking system.

>>:
Excuse me. And when you're working on that specific task. You might even calendar it. Put it on your calendar. Mark the JIRA key in there. It'll remind me at the end of the day. At the end of your week, when you after you have to turn in your time, or if you have an integration with a time management solution. And we'll just do it automatically for you. Maybe there's a few of those out there. Leave room for breaks. You know, I think that. A lot of people don't do this. I know I'm really bad at it getting up from my desk, going and eating something. Just getting my mind off of whatever. Schedule your breaks, make sure you do on your breaks. And I think if you show that to your team that you're doing that. Because you're sharing your screen and demoing to all of them all the time, right? Or at least as a project manager, you're sharing your screen a lot to your team. Um, it'll kind of facilitate that habit. I think you know the ideas about it and they might adopt some of that themselves.

Project organization. Under this here. You know, I think I'm just talking about how you are formatting your projects. So if you're using JIRA or something similar. Um, I think even asana has quite a few levels, but you know, you want to think about holistically, like how you're structuring everything into products and features under epics, using stories and tasks and bugs. Type tickets that you're utilizing, tagging something like needs discussion with the client or internal. It can help you to build those widgets and those things you know, to be able to list out during your next standup, or during your next retro, or during your next status meeting with the client. Um, just utilizing the tools that you have at hand in order to get to the next. I do apologize. It is the time of year. This temperature up and down thing anyway. Components. Another portion in JIRA specifically that I know I've been leveraging a lot more recently, is they have this component section that you can do some additional tagging or a type of tagging with as well.

I found it to be useful. Due dates. I don't know and I don't know why it did once. Browser tab I'm so sorry. Meant for it to not do that yet. There we go. Browser tab. I'm sorry. Uh, due dates. So not everybody uses due dates on tasks or tickets, but I found them to actually be very useful to some team members. Especially if you have a major milestone coming up. You want to set a due date on your task, so they know that they need to get this thing delivered so that we can get into QA, get into demo, you know, when is it not just when is it in the sprint? I mean, which sprint are they delivering it on? When in the sprint? Are they delivering it on? Because we may be trying to like aim for a QA session and demo at the end of the sprint or immediately following the sprint. And if we don't get that done, middle of the sprint. Might be having an issue. So but I would say don't do it every time. It's really only for those like hard deadlines. And then we have swim lanes. That you can use as well.

I found again this is Jared because that's where I live a lot. Sorry guys. If you don't all use JIRA. But having a board where you are or I'm sorry, multiple boards is what I was trying to say here. You know, a lot of times you just set up a board and that's what everybody uses, right? You have your backlog which has the list of things, but then you have your board and the swim lanes are the groupings. So I wish I had a screenshot for you. I don't. Um, the swim lanes like a per audience. I'm sorry, a per a per assignee or per epoch or per whatever. So you're going to have different audiences that are going to want to look at the board differently. So you might consider. I'm running out of voice. You might consider creating multiple boards with my point. If I can get through the one bullet point. Dashboarding may be useful to your internals and clients as well. Um, you know, I think it's just something to consider. Uh, it makes your life easier because you don't have to do all the things all the time.

Every time. You can just rely on widgets to generate this information for you. Release tracking I don't know if everybody uses release tracking all the time on every project, but why not just do it? It's a thing that's available a lot of times, and if you do it, then you can report on it. So, you know, I think you should do it if you can. Can you explain on that a little bit? Which one? Release tracking. Sure. Is that specifically having to do with projects that have code or can you use it for other. I think it could be like any sort of major feature set combination. You know, I think in JIRA, you could even say that it just means these deliverables that you are delivering as part of a design, it could be a design release. But yeah, I mean, I think usually we're thinking code releases. So, um, it's just that often up to the next. I'm sorry. When can. Sorry about. I'm asking to dumb it down. But what do you mean mean by that? Just tracking everything that was delivered in that release.

Yes. So from a code sort of perspective, it's probably good to track like how many things were actually included in a particular release. You know what that sort of release notes looks like, what that story is about, what those functionalities are. So you can translate that over to the client and whether or not it's like the very technical release notes that you're doing. I don't know if that's absolutely necessary for every client. They're not going to absorb that, understand it, care about it. But if you leverage like your project management tool to help with that, it kind of builds a more deliverable story. You know, more. This is the feature that we have implemented for you today. This is the thing you asked for. Here it is. Yeah, yeah. No. So I think it's important to do that as well. But from a sort of management standpoint, I think that if you don't do that, your status reporting is going to be more difficult because you're going to have to do it manually. Why don't just use the tool to do it?

That's kind of my point there. Uh. Another thing on that side project managed organization. One more point and I'll move on is the overview page on something like a wiki or a or a confluence or a, you know, your docs wherever your docs live for the project. Uh, docs, pages, I guess you'd say, is just simply having that overview page that gives a high level item not on this project or I'm new to this project. I need to know where all the things are. So those project lists and links to things should probably live in one place. And that would should be one of the very first things that you do. But it's good to template that out. Why not? Why not just do that for all your projects have the same sort of layout. Um, you know, provide that information, including contacts, contract, uh, what the strategic initiatives are for the client moving forward, things that you want to keep in mind when you're doing your previous phase, maybe some discovery. And let's say you're in a maintenance agreement with the client and you want to look forward.

And so you're going to want to prepare an audit before that next thing happens. Right okay. Well, the same page, their browser tab organization. I think I mentioned that a little bit to do with grouping, labeling, color coding. There is a save for later feature, by the way, on Google Chrome. I don't know if you know about that, but that's pretty cool. New thing performance even there's like memory saver stuff across a lot of the browsers. So you can turn that on if it isn't already automatic. I believe it is on Chrome but isn't on edge if anybody uses that anymore, I don't know. There's also a tab unloading on Firefox. So that's that's one of those things. Integration specifically. Just wanted to make note of some integrations that might be helpful to you. Email the slack. Email the Jira slack to Jira, Jira time tracking with tempo. This is where I was talking about time tracking integration before. I've used tempo before. It's beautiful, I love it, and it has a lot that you can add, like you can have a little and a lot sort of thing.

That's how they do their stuff. Um, so you don't have to pay for the everything, but if you do more, you get a lot of really nice reporting and really nice strategic planning stuff that you can do as well. I am not employed by tempo. Don't, don't, don't think that I am, but I have loved that particular tool. And if you can get an integration going, my point is, if you can get an integration going between your project management software and your time tracking software, even if it's custom home made, in-house time tracking, whatever attached to your budgeting whatever or your contracting whatever, uh, APIs are a thing, you know, we can we can build these things and make these happen. And integrations happen between your project management system and your time tracking. I was going to. Ask you about that. Yes, but time management in particular, because, you know, in the past, some of my internal teams, you know, we've been doing Fibonacci sizing and shirt sizing and all that, but with our with some of our agencies, my boss's boss is kind of cracked down, like it seemed like they were building us for eight hours, eight hours, eight hours, regardless of if we were in a horrible time crunch on the project or if it was easy sailing.

So he wants to see hours from our consultants. So usually our you kind of utilizing your project management software to collect hours as well. Or do you typically. Use it if I can. Yeah, absolutely. Why not do it one place one time? Sure. Yeah. I would prefer that if it's available. I mean, sometimes it's not because the integration doesn't exist or, you know, native integration doesn't exist or whatever the case may be. But but yeah, I would say that, you know, if it's if it's available, it's ideal. It's I don't know how many times I've had where developers on a project or resources, whatever, um, aren't getting their time in on the time tracking tool because they're focused on the stuff on the project management tool, and they're just executing, and they don't think about the time tracking as much. And the business you need to know. You need to know what the spend is. You need to be able to have that conversation with your client about like how much money is left and whatever. And so, yeah, if you make it easy for people to enter their time, I naturally they're you're going to have more accurate information and then you're going to.

Have it on a post-it they have on a post-it. Well then then please use the project management tool. Um, there's a whole nother session that I could probably give on how to provide good content on your project management tasks, uh, as a developer, but I'm not going to get into that today. We are at time. Over time, I have talked so much. Uh, the only thing else that I was going to mention here was, uh, let's see. Girh meeting notes on calendar. Uh, there's a feature for that that you can do with Outlook and Google Calendar. There's a reclaim. I, I don't know if you've heard of something like that. Jira. Uh, Google calendar also works with asana, Todoist, Clickup and linear. It's an awesome tool that helps you there. Status automation similar with reclaim, I Don't Interrupt app is also another alternative for status automation, so you can make it so that when you have your calendar set aside and blocked off with a meeting time non meeting time project time, it shows up on your slack and says, hey everybody, I'm working on stuff.

Stop. Stop bugging me right now. Uh, respond to remind. This is just a tactic. And I believe this is my last and last thing to talk about. Um, but I'm not going to go in the whole thing. But if everybody's heard of Inbox Zero, I think at this point. Right. So the whole idea of just, you know, make sure that you are deciding right there. And then when you get a message, do I need to do it now or do I need to do it later? And if you need to do it later, set a thing. There's reminder stuff everywhere. Slack has it, outlook has it. Google has it. Just set a reminder. Do it. That's fine. The whole point is to set yourself up, to have this focus time, this flow time that you are being able to get things done at the right time, still be able to attend all your calls, still be able to communicate with your team, and maybe move into a world where we're, you know, consolidating our meeting time to a certain portion of the day. And we're only doing these projects on this side of the week, and that those projects on the other side of the week, but really all about like having that focus and flow moments more often.

So that's it. On integrations, status automation. I'm sorry I said responded to remind any other tips and tools. I think we already mentioned a few, so we're good there. Okay. Uh, please provide your feedback. Thank you for taking the extra couple minutes with me. I have on my session here today. I have a feeling I might get some feedback on those last couple slides. They were very long and not much graphics going on, so I appreciate that. Um, also, contribution day tomorrow, 10 a.m. to 4 p.m.. Please come back. Matthew Radcliff will be doing the new contributor training at 9 a.m.. And thank you. I don't think that I have anything else for you today. Uh, did you have any other questions for me. Before we close up? Thank you so much for attending. Thank you. I hope you enjoyed. You got something from it. You have a good rest of your day.