Your Project Kickoff Strategy is Costing You Time and Money

Welcome to Building Better Developers, the Developer podcast, where we work on getting better step by step professionally and personally. Let's get started. Well, hello and welcome back. We are continuing our season where we are building better developers, we're developing our podcast, and this time we're doing it with AI. One of those old things, we have little stars, something like that, you know, like that little thing up like a logo up on the top of a little superscript because it's really actually it's not even close to the same thing we did two seasons ago, which is actually reusing the title, the topic, and then we're saying AI, what would you do? And then we're talking about that. And we've actually had some really good conversations. So I want you to just like, you know, buckle up because this should be a fun one as well. This time we're going to talk about mastering the project kickoff, setting the stage for success. Actually, I think going to be a fun little topic. We'll see if AI fails me or not. I am not going to fail to tell you who I am. A little introduction here. My name is Rob Brodhan. I am one of the founders of Developineur, also the founder of RB Consulting, where we are your buddy in technology. Basically, we sit down with you, we walk through what does your business do? What are your needs? What is it that makes your business your business? And then we craft a recipe for success for you. This is essentially an IT assessment. We look at what we can do through integration, innovation, simplification, automation, too many shuns out there. But we don't shun the work itself. We help you build a roadmap and either implement it or you can do that yourself as well. It includes things like if you want to build a team, whatever it is. Some people refer to it as like fractional CIO services and stuff like that. But really, it's about helping you leverage technology better and reduce that technology sprawl, get rid of that technology junk drawer that you have and instead turn it into that like front dining room that everybody wants to see as they walk by your house. Somebody everybody wants to see in the front of their house is Michael and he's going to introduce himself. But first, I need to do good thing, bad thing because I almost forgot that. Good thing, bad thing. This has been one of the, let's say I am in a road warrior mode the last few weeks. And the good thing is that I'm able to do this. I'm able to like sit down almost at the drop of a hat, rip out a web laptop or something along those lines. Maybe it's a phone or tablet or something and I can get stuff done. I can write code. I can crank out emails. I can market. I can network. I can do a lot of stuff. That's a good thing. Bad thing is, is that there is like a, there's a rhythm that we get into in whatever our normal place is to work. And if we're constantly shifting that it can be hard to do so. And if you're somebody like me that loves to have that like heads down, focused, talked about it, the Pomodoro technique and stuff like that, those kinds of things, that's focused time to get stuff done. It can be very challenging, we'll say. So that's a bad thing is I've been running around a lot. I've been very happy with what I've done. I've also learned some tools that I need to make sure that I'm an upgrade or that I gather as part of my road warrior-ness. But in my, you know, my digital no madness that I'm going on to. But that's my good and my bad. Now I will go back to after I faked you out earlier, we're actually going to go over to Michael. Introduce yourself, my friend. Hey everyone, my name is Michael Mollage. I'm one of the co-founders of DeveloperNURB, Building Better Developers. I'm also the owner of Envision QA. We help startups and growing companies improve their software quality through services like test planning, automation and release support. Why do companies work with us? Because buggy code software costs time, money and customer trust. We make sure products are reliable before launch, helping teams move faster and avoid costly mistakes. If you're building something great and want it to run smoothly from day one, visit EnvisionQA.com and reach out and give us a call. Good thing, bad thing. Well, good thing there is so many good movies coming out or movies coming out. I want to say good because I haven't seen them yet. I want to see along with some great video games that are coming out and I have no time for any of them. That's the bad thing. I have so much work to do. So many things get done because the rain still comes and goes, which unfortunately makes the artwork longer because if you get rain four days a week in the middle of summer when usually can mow the lawn once a month, you now have to mow it twice a week. But one good one additional good thing with that, my wife's tomatoes have been producing about 20 to 30 tomatoes a week at the moment. We are canning, canning, canning, but like she decided to plant heirloom tomatoes this year. It's freaking huge. It's they started out small and we're like, man, we need to plant more. We overplant it. We have so many tomatoes just popping out. But I have to say after the last few years, kudos to my wife. We finally figured out what we need to do to the soil to get it right before she did this because last year every single tomato had bottom rot, which I guess is a lack of nutrients in the soil. So we had all these wonderful, beautiful tomato plants and zero tomatoes. And that is your farming minute from develop a newer where we build better tomatoes. I just want to say like this is a little bit of a sidetrack before we get into this topic is that being someone who is just recently downsized, there is a good and bad to that is that there are those moments where I'm like, ah, it'd be so cool to be out and have my little garden and be able to work in all these little things. I blame my wife because she got me hooked on hydroponic stuff a couple of years ago. And the next thing you know, I was like, I should plant stuff. Suddenly I'm out in my yard. I'm like that old guy working in his garden. Not very well all the time. But now it is nice. It's a good thing is that I don't have to deal with the house. But sometimes I wouldn't mind like, you know, putzing around in the yard and having a little garden and stuff like that. Moving on, we're going to talk about AI actually more important. We're going to talk about mastering the project kickoff. What does AI said? Well, once again, because it must have hurt us, it starts with great episode idea. It's gotten back into the like over the top positive AI answers again. This one's again, giving me one that's a little more like we got in the last episode, which really it's like an act one act two act three, not really covering the topics, which is interesting because I've got to figure out what I did because whatever I did before, I was pretty consistent the prior whatever it is, dozen episodes in the how I phrased what we were doing and who we are. And I would just I'll throw that out as like a little bonus to everybody is that when you are talking with an AI, when you are having a conversation with an AI, how you phrase stuff and the background that you give is incredibly valuable. If you want to learn more, one of the things I highly recommend is work with one of the APIs because there's always going to be a setup essentially of who the AI needs to present itself as and having those settings and figuring out those prompts and how they should be done will really help you when you're just sitting on a, you know, for like a better term, a command line version of a chat agent or an AI agent. Moving on episode focus. Equip developers, tech leads and PMs with the mindset, tools and rituals to launch projects intentionally, not just start writing code. Oh my gosh, that's like that is step one of building better developers. You need to do something besides dive into code. Cold open. I love this cold open. Let's see how it goes this time. One to two minutes. Imagine this. You start coding on day one. Tickets are flying two weeks later. No one agrees on the goal. Wow. That has never happened before. That happens every stinking project. It is amazing how often including the customer. This is why every project proposal I talk about, I start with the first thing we're going to do is we're going to sit down and figure out what the heck we're building. I have been in way too many projects where we all sit down and we're sort of like, yeah, this is what we're going to do in a little 30, you know, 30 minute or 30 second discussion. And the next thing you know, we're going in completely different directions and we really can't even agree on the why. We don't even know what problem we're solving anymore. So definitely let's make sure that we, as Michael showed, for those of you watching the YouTube channel, document this stuff, like write these things down. Let's make sure we all agree exactly on what we're doing. Use a quick anecdote of a project that lacked a proper kickoff and spiraled into chaos. I'm not even going to bother with that because it's like almost every single project. And the sooner you wrangle that stuff back together, the less chaos you're going to spiral into. So let's dive right into why kickoffs matter. This already, I'm like pumped up about this one. Kickoff isn't a formality. It's your project foundation. Misaligned expectations equals missed deadlines, wasted budget and burnout. Set the tone for team culture, communication norms, scope clarity, quote worthy line, start slow to go fast. I am going to call out everybody that thinks that agile methodology means that you don't spend time in design, requirements gathering, documentation, and some of these other things. Go back and look at the manifesto itself. Go look at the agile manifesto and you will see that there are all of these things are critical. However, there are some things sometimes that are more important, but that doesn't mean that those things go away. I got into the habit of a kickoff with the company I worked with years and years and years ago. They always did a project kickoff. There was always an internal kickoff and then a with the customer kickoff because this was also a boutique consulting company, very similar to RB Consulting. And I always loved it then. That was part of what attracted me to working with them. And I've loved it ever since is you need to have a good product. And I've loved it ever since is you need to have a point where you sit down and this is not where you sell the project or get sign off on it. This is where you say, okay, we're going to do this project. This is the starting point. And at that starting point, you need to make sure that you are actually walking through where we at and where are we going to go, whether it's A to B or A to Z. What is A and what is that last point? You don't have to get all the details, but the most basic stuff is where are we and where do we plan on going? Sometimes that where we plan on going will change, but we need to have at the start, what it's literally like if I'm going to start a journey of a thousand miles, which directions do I face first to take that first step? And there are a lot of things that are involved in a good kickoff. Introduce the team. Oh my gosh. Make sure that people know who everybody is, whether it's the customer, the team itself, even if they never talk again, the fact that they know those people exist is very useful to success for a project. Make sure you swap whatever it is, business cards and contact information. So the people that need to communicate with each other can communicate with each other, have a talk about things like where is your document repository is going to be, where is it that I'm going to be able to find the requirements, the current requirements for this project? Where am I going to find design material? Where, what are we going to do for code repositories? What are we going to do? Who is the customer and what are we going to do to get stuff to them? What kind of like a rhythm are we going to have? Is this, what is the SDLC approach that we're going to take? There's all these things we take for granted. And particularly if this is the first time that we're working with our customer, let's have a kickoff where we lay out these ground rules. And basically say, this is the rules we're going to work for and work with. And this is how we're going to proceed. Because sometimes that alone will turn up problems and we'll very quickly be able to say, oh my gosh, this customer, this is what happens to many times. This customer doesn't actually understand the data that they work with to a level that they're going to be able to provide the mappings and the functions around the data for the integration that we're going to build. That's just a random example. But I will like, I will call out NetSuite, Salesforce, every big CRM and ERP solution. And it's not those tools fault. It is the customer. A lot of times it is not ready to take that step and nobody sits them down and says, you need to understand your business and how it works and what is critical and how to communicate that to the implementers before we move forward. Because a lot of times there's stuff that lives in somebody's head or sitting in somebody's drawer, somewhere in a desk in an office, you know, the other side of the country and that stuff ends up being critical to the success. I know I'm being a little vague. I don't want to call people out too much, but I just want to say that kickoffs matter and make sure that as part of that, you line out the outline. What is it that we need for success? Which includes where do we need to go to be successful? A little bit of a sandbox, a soap box. Sorry about that. I'm going to set that aside. I'm going to let Michael get on his soap box and talk about what he thinks about this. I'm just going to add a little bit to it because you kind of went pretty in depth on this one and time wise, we probably should be getting to the next topic pretty quickly. But with this one, you're absolutely right though. The project kickoff, sitting everyone down internally and externally, more times than not, the customer really doesn't know what they want. So really establishing the why, what is it that you're building? What is it that they need needs to be established right up front? That's why when we do our intros, we talk about doing assessments. Assessments are a great way to figure out what they have and what they need. And then you can refine that into a proposal for something to build them or what you can have them customize what they have for something that will improve their business or their overall workflow within their organization. What I have seen lacking is when you do get to the internal, you're like you may have the documentations, but if you don't really sit down and bring everyone on board, it can be timely and costly to do it upfront. But you have to kind of get everyone on the same page, maybe not do a full brainstorm session, but least walk through the project at a high level, make sure everyone's on the same page and yes, open it up for questions. Don't make it a total silo, but do keep it restricted because that initial kickoff is not where you're going to be doing all the brainstorming and things of that nature. You will be doing that over the course of time through your sprints and hopefully through your roadmap. We covered a lot of stuff right there. And so I'm going to actually dive right through the second section because I think it's very valuable. This is some of the things this is essentially says the anatomy of a great kickoff and we've touched on a lot of this. So I do want to like fly through these and then because I monopolize too much time, I'm going to throw this to Michael for the next one. So heads up, you're going to be on the hot seat. Now, we have a great kickoff. Walk listeners through a bulletproof structure. Before I go into any further, I want to say that this if you are putting proposals out to customers or potential customers prospects, these things are awesome to cover in your proposal. It's amazing how often addressing some of these things and talk about things in a proposal will improve your chances for success, including I've had multiple customers, actual customers that I, you know, I won the proposal that said that that was one of the things that helped me win it. Of course, if you're proposing against me, please do not do this. But otherwise, feel free. Purpose, define the problem, the project, solve. This is the why. Establish project, establish project goals. OK, are smart format, PK eyes, whatever it happens to be. What is it that essentially is like, OK, what is it that we can say we can go verify that we actually solve the problem? People. This goes back to what I said. Who's involved? Who's accountable? Oh, who owns certain decisions? Who are the decision makers is key to the kickoff in a project. Clarify roles, developer, project manager, designer, stakeholders, set collaboration rules, slack, standups, async updates, stuff like that. Roles are critical, especially when you have people that cross roles or you have small teams where people have multiple roles. Make sure you're clear on those process. Agile, Kanban, water, scrum fall, deployment, frequency, brand strategy, review your flow, deadlines, demo rhythm, ask what can go wrong, discuss past similar projects and what to repeat or avoid. It's almost a retrospective and a review in itself just to do your kickoff. For those of you to understand the agile side, if you don't check out our agile stuff for what those rituals are like. Playbook docs, centralize your documentation. Do we use confluence? We use notion read me's dropbox, whatever. Record the kickoff meeting. I will add to this record meetings all the time. Just record everything. It's so easy to do. We have done it. Yes, I've got gig and gig and gigabytes of stuff that I will never look at again, but some of it we do need. So record all the meetings just in case. And now we're going to go to act three. Michael, get ready. You're about to. With the recording stuff, especially nowadays with the AI tools that a lot of them have built in like zoom, you will get pretty decent transcripts. At least keep the transcripts because they are searchable through your system. So you can just have all your meeting notes or transcripts out there. And heck, you can even have AI create meeting notes from your transcripts. But if you're like, Hey, we talked about this. Go search your folder directory of all your transcripts. You can find the meeting and if you can't figure out what it is, open up the video and then jump to that section. And it's like, ah, yeah, now I remember. So that is that is an incredibly good suggestion is so much faster search for text and find like that. Like where did we talk about X use those transcription notes are very valuable. That kind of stuff. All right. So red flags of a bad kickoff, no written goals or timeline, unclear responsibility. Wait, who owns testing stakeholders missing in the room? We'll figure it out as we go. Mini rant opportunity. This I don't know if I want to give you this code doesn't solve confusion. People do. All right. I'm going to toss this right to you thoughts. And where do you want to go with red flags of a bad kickoff? Oh, let's see. Uh, I can almost picture one right off the bat. So if you have a small team, a large project and a very small budget. You are going to red flag is right there because chances are you're automatically going to be going in with the mindset of how can I cut costs and still deliver. And if you do that right off the bat, you're going to be, well, we'll figure that out later. Or you'll kind of go the easy route. What is the lowest hanging fruit that we can pull right now to get started, to kind of get a small MVP or at least something visible for the customer to see, to start getting feedback. The other red flag that comes from that is if you did not define the requirements, the why from the customer beforehand, you could be immediately running down rapid trails of no, that's not what I want. Or, oh, this button is right. Or you could get way too confused and lost in things that mean nothing, that are not the MVP. It just enrolls defining roles because especially on smaller teams, testing is important. And if you are both the developer and a tester, getting people to understand where you're coming from, depending upon what hat you wear is very critical because you could be asking questions one day as a developer and it's very open, less critical. But the next day you turn around, you're testing, you have to come in more critical. You have to be asking more deep. You ask different questions and it can offset other people on your team that are used to being in one role or their developers. They used to developer speak, coming at them with tester speak. You get more defensive. You run into this in almost any organization and company. So bear in mind, if you are wearing those hats and you see some confusion or miscommunication going on as you're going through the project from the beginning, you need to stop, reset and redefine those roles. Otherwise it's going to be complete chaos by the time you get to the end. That's all of that is a hundred percent. Yeah, that's kind of those are things that you need to be worried about and the, it, how it can go wrong. Basically, I want to, I want to focus on the, we'll figure it out as we go. This is very much an agile approach because there is a level of, we're going to figure it out as we go. That's part of what agile does is it says, I'm going to take, I'm going to put a couple of stakes in the ground, but then there's other things that I don't have to worry about. It's, it's not that we're going to figure it out as we go as much of it's more of an 80 20 rule. It's a, these are the things that are critical and then we're going to get mostly there and we're not going to finish them out until we're sure we really need to finish them out. More importantly, I have found more and more and more that the idea of an MVP should be part of every single project because too often you get further down the road and suddenly budget becomes an issue. Time becomes an issue. Uh, capability becomes an issue, whatever it is. And suddenly you find yourself changing gears, fighting fires and converting everything into an MVP mode. Everybody loves a big project when you start because we've got all of this. Like we've got all of this runway thinking about a plane on the runway. It's awesome when you start and you've got a 10,000 foot runway, but when you've been lollygagging, now you've got a hundred feet left and you're only going one mile an hour and you've got to get to a hundred miles an hour to lift that sucker off the ground before it goes off the runway. It is panic time. We do not want to get there. So I highly, this is through literally now decades of experience with this in commercial development, internal development, scripts and utilities, you name it, whatever the product is. I would highly recommend always, always, always. I'm thinking I should write a book just on this. Always, always, always have an MVP. Have a, this is our minimal goal. And that should be part of your why. That should be the thing that you can measure every single choice and decision against and say, does this contribute to our MVP? Now that doesn't mean that you're going to stop at an MVP, but that does mean that you need to at some point in your project achieve or succeed what an MVP does that is really going to help you particularly early on it's going to help you figure out where do you spend those resources and agile projects are as bad as anything else about this, where we will sometimes start out and we don't feel the pressure of time and resources enough and we spend too much stinking time building a green versus a blue button as opposed to solving an actual problem. And I know this sounds a little judgmental and I am judging myself too. Cause I have been there. I have, I, I have been in those situations where I'm like, I've got a whole week I can spend chasing down random CSS, cool stuff that I can do. And I get to the end of that week and realize that I really didn't provide value. So I would bonus tip recommend to you always have an MVP and then use that as sort of like your, your guiding light. It's like, we've got to get at least to here in order to be successful. I'm going to throw it back to you before I dive into the next one. Yeah. So if you're struggling to understand what an MVP is or how your project that you're working on, what is an MVP for your project, flip it on its head. Write user stories for your MVP, turn those user stories into tests. And if your code does not complete a test in your test suite, you're not working on the MVP. That's not a bad way that we'll call that test driven development. We quoted it here. That's trust me, we're the ones that invented that. Um, honestly, that's ex there's almost exactly what it is and saying, what does this need to do? Build the tests that say, okay, if that means if it does this, then it means that this test will succeed and then you build the application out to that. So that is literally test driven development. And it is, if you're struggling with MVP, as Michael said, that is a great way to do it is you do, you start with the user stories is it's, it really is it's focused on the Y focus on the problem you're solving and then break that down. And it's like, okay, to solve this problem, what do I need to do? And that starts to become your test. And the next thing you know, you're like, this is what we are implementing towards. I don't want to go too far into this because we're going to leave some bonus material for the people that are out there on YouTube. Those of you are not on YouTube. You should be because we have bonus material, literally every episode, sometimes more, sometimes less, but there's always some extra stuff, especially this season. We have had some pretty cool stuff that we've thrown out there after every single episode, sometimes very key stuff. So I got through like half of the response of AI. So check us out. Also shoot us an email at info at development or.com. I do not get enough of these emails. I would love to see that. Yes. I know we, you guys give us, you know, we'll get responses, we'll get reviews and things like that. I would love to get some emails because I want to, I want to actually connect and hear from you. What do you like? What do you not like? What would you love to see us do? That's why we're here. We're here to not only build better developers. We are also here to build a better you to entertain you, to inform you and do the things that matter to you. Yes. You, I am talking to you, whoever you claim yourself to be. That being said, we're going to wrap this one up as always. There's so many ways you can reach out to us. I'm not even going to bother listing them this time around, but I am going to tell you to go out there and have yourself a great day. Great week. And we will talk to you with AI next time. Thank you for listening to building better developers, the developer nor podcast. You can subscribe on Apple podcasts, Stitcher, Amazon, anywhere that you can find podcasts. We are there. And remember just a little bit of effort every day ends up adding into great momentum and great success.