Mastering the Project Kickoff - Setting the Stage for Success

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 discussion of the developer journey here on Building Better Developers. Spoiler alert, that developer journey should take you to becoming a better developer. That's our goal. That's why we're here. This is what we've done and how we want to share with you and hopefully get some feedback from you guys as well, guys and gals and whatever else you want to be. My name is Rob Brodhead. I am one of the founders of Develop-Nor, Building Better Developers, also a founder of RV Consulting, where we simplify, integrate and automate. Basically, we take your mess, your sprawl of technology. We take a look at what's there, whether it's modern or whether it's 15 years old and it's about to go out of support and all that kind of bad stuff. We help you figure out what you got, where it needs to go and how to best move you there. We'll even move you there if we need to. We'll supply the moving trucks, you name it, we'll do it. On the other end is Mike. Go ahead and introduce yourself. Hey, everyone. My name is Michael Mollosh. I am also one of the founders of Envision of Develop-Nor. Boy, I need more caffeine. I'm also a founder of Envision QA, where we help small to mid-sized businesses and healthcare startups and clinicians build custom software to meet their needs and review their current processes to make sure that they have the right software to do the right job. And a little pro tip there, while he was talking, I took some caffeine. While I'm talking, he's doing the same. So that's how we keep this thing going. This episode, I want to talk about kickoff, not like football kickoff or something like that, but project kickoff. And this could be if you're working for, you know, if you're a company somewhere, if you're employed, it may be a new project there. I mean, like an internal project. It could be kicking off your side hustle project. It could be a customer that you've got if you're, if you do consulting or something like that and they bring you a project. And this is, it does vary a little bit what you're going to need from project to project, but there's definitely, there are definitely some things that you want to have as a part of your kickoff. Now the first thing, which is funny because it goes back to my first job. Very first job I was in, I can't remember how, I'd been working for a few weeks, something like that. Then something happened. I can't remember if I was sick or something like that, but I wasn't going to be able to make it to work on time. This is before everybody had cell phones. We had these big things. You had to have like two hands to like pull the dial and sort of look like Price is Right stuff. But I didn't have phone numbers. I didn't have a phone number for the business. I didn't, I mean, I could look that up in this thing they called the yellow pages, which was a book that had phone numbers in it and I could go get that, but I couldn't get a hold of like a specific manager or anything. And even then the business phone like never got answered. Basically it never got answered. There were a couple of phones that you could get to people that were, you know, internal, but you couldn't get to the, through the actual business phone. You got nothing. And so I realized fairly quickly, it's like, oh, I need to have that. I should have first thing when I start a job, I should know like, who's my boss? How do I get a hold of them? These days it should be like, you know, phone number. If there's a phone number to get a hold of them, email address definitely. So I can get hold of them that way. Anything like that, you know, those kinds of really it's, it's just administrative stuff. And now most of the time when you do a, when you start a job, one of the things you're going to do is you're going to have like a, an orientation. You're going to have something that first, you know, a little bit first day, whoops, first day of your job and stuff like that. You're probably filling out paperwork and they're walking through. This is what your job's like. This is what the company's like. This is sort of what you want to do with your project. One of the most important things to get going on, on a project when you do the kickoff is introduce yourselves. We should know it should include, then have to include everybody in the project, but definitely the major players. So if you've got a team of thousands of developers, they don't all have to be a part of it, but you should have like the leads, you should have the testing leads, you should have the customer representatives, those kinds of things. The people that are the, for lack of a better term, the executive team of the project. Now that may just be you and a customer, but still those people need to be part of that. Whether they don't have to be in person, but they have to be a part of that kickoff call. Because what you want to do is say basically, this is the team. This is what we've got as far as the, you know, from a software point of view, like here's the implementation group, here is the customer, and this is who these people are. This is their role. Ideally, and it doesn't always happen, but one of the things you want to do is identify like the key decision maker or the decision makers. Who are your primary contacts? Both ways. So for the customer, part of that conversation is if I have questions about, let's say requirements, because we're going to go into the requirements phase sometime early on, if I have questions about who should I talk to? Or should I, you know, or is there a group mailing list? Should we set up a group mailing list? Along with that, it is a lot of this administrative stuff. It's things like, okay, what happens? How do we track conversations? Do we use that thing I mentioned earlier, like Slack? Or do we use some sort of a ticketing system? Or do we use Teams? Or do we just have an email that we pass back and forth? Or do we have a spreadsheet that we pass back and forth? Is there a Wiki site? How do we track this stuff? And then with that is like, how do we build, what is our goal for building documentation and other deliverables? Are we going to have shared stuff? Is it going to be something where it's sort of passed back and forth? And this is not necessarily at a specific level where you're going to have to have all your templates and everything done, because your kickoff should not take you three days. It should take you maybe 30 minutes, maybe an hour, depending on your team and things like that. Here's how we're going to proceed. This is typically going to be a reiteration of the project charter or statement of work or MSA or something like that, where it's just basically like, okay, this is what we're doing. This is the team. Maybe this is the phase that we're working on. And this is how we want to work. This is how we're going to communicate and how we're going to work together. Getting that is really one of the key things for your kickoff, because kickoff is not gathering all the requirements or anything like that. Kickoff is really like setting the stage to say, okay, let's introduce everybody. Let's talk. Let's do what we need to do. Let's get our ducks in a row, because in the next meeting we have, it's almost like a pre-meeting, because in the next meeting we have is where we're really going to start working on these things. Those are my thoughts. That and however much $15 will buy you a cup of coffee these days. But over on the other side there, I want to see what are some of your thoughts and some of your experiences with kickoffs and even some feedback on some of the things that I threw out there. So before I jump into my thoughts, I have a couple of questions for you based on how you introduce the kickoff. So in today's world where we've gone away from the more waterfall approach to the more agile approach, do you feel that we've lost some of that requirements gathering piece where this type of kickoff documentation gets put together? Because typically we would do that at the start of the project and then over time we would update that. But with agile, sometimes we're moving so fast that we forget to do that. Like we do that at the beginning, but then we're just constantly going, going, going. We assume that that's the right document and it never gets updated. What are your thoughts on that? Wow, that's a whole, that'll be the next episode. We'll talk about documentation and keeping it in sync. I do think there's part of that because with waterfall, you really don't move forward. In the strict sense, you don't move forward until the document is done and then you don't change the document. That's the waterfall thing is you get it all figured out and then you move forward. That's like, you know where you're running and you know you're going to run until you get to the finish line. It's different because it's basically saying we're going to start moving and we're not really sure where we're going to land. We really, we sort of know where we're headed, but I'm not sure how we're going to get there. And so it's sort of the difference if Columbus had come to America and he had used a zip line to get across the ocean, very different from how he managed to get where he, you know, his trips and how he went. So I think you, if the agile approach, especially if you're doing like scrum with sprints and things like that, if part of it is that you are making sure you're updating documentation as you go, if you have as part of your deliverables each time, and this is something you would discuss in a kickoff, would be things like we're going to take an agile approach. We're going to do, you know, two-week sprints. At the end of every sprint, we're going to have a half-hour demo. We're going to deliver this kind of document, this kind of update, blah, blah, blah. Doing that is part of it. I think it's an essential part of that kickoff is to set yourself up from the start to say, this is how we're going to do it. And then if you don't, at least you've said it and you've tried, you've got some accountability hopefully, and even something that you have somewhere down the line. Usually it's going to be maybe the developers, but a lot of times it's going to be the customer going to say, wait a minute, you mentioned you were going to do X. You were going to have unit tests to run for every deployment. I haven't seen those. Those are the kinds of things that you want to set that stuff. You set it up at first, and then when you get into that first sprint from the kickoff on, that's sort of your checklist of are we doing all of these things? And if you do that right, then that answer, that goes back to your question. I know it was a long trip to get there, but I took an agile approach instead of waterfall. And that is how you're going to, we'll call it protect yourself or do it right. Now, can you get away from it? Yes, you can. However, we do what we can to try to set ourselves up for success. Back to you. Gotcha. OK, so I'm going to put a pin in the documentation part of things because I like the idea we can do that in a future discussion. So to me, the kickoff idea, which is interesting because I've worked in a couple of different companies from Fortune 500 to small startups to the individual consulting businesses and our own type of businesses where we've started our escorps and LLCs. Essentially, as I'm going into any type of job, you know, as developers, we have kind of ingrained in us the whole software development lifecycle. We have this whole idea of how software gets built, the processes we go through. But when you walk in and you deal with any type of kickoff, be it a project, be it a new job, be it a new position, you need that critical information to do your job. Now, it's not necessarily what it is that you're doing, but you need to know the key players that you need to talk to. So you're going to need things like the organizational chart of the organization. How is it structured? Who do you talk to? If your manager is out, where do you go? In some cases, there is no one to go to and you're basically going to have to figure it out. The key there is understanding which scenario you're in. If you're in a scenario where there is someone above your boss, you need to make sure you include them with that kickoff. You need to make sure that you communicate to the right players at the right time. For instance, a couple of jobs ago, I was in a situation where I had moved up to being a manager, my direct manager, I replaced the manager of our team, and our director literally within the first month of me moving up left. So we had an immediate vacuum for our application. Well, funny thing is, we're in the middle of a sprint and we have a release about to go out. I immediately run into panic mode because at this point in time, I had not received all of the kickoff information I needed for who I need to talk to, to handle the release cycle. Thankfully, I was able to finally figure out that we had a release committee that required certain players to sign off on what we were doing. So it's not necessarily just who to talk to, but it also requires not just the tools to communicate, but what you need to do to get a release out, what type of release notes, what type of documentation is necessary for us to do these kickoffs. So again, I don't want to get too far into the weeds on documentation, but as you're kicking off a project, with most SRSs or system requirement documentations, you're going to need some key information. Like Rob said, what type of communication tools are needed? Who is required for what? What is maybe the organizational chart? Who is the current project owner? Who is the current tester, user tester? Who are your testers? Do you even have testing? Some organizations don't even bring in testing till later in the cycle, which is not a good thing, but it happens. So in these situations, having something like the start of a software requirements document at the beginning of the kickoff, even if it doesn't contain all the requirements, you can still fill in key information that is necessary for the organization to move forward with any release or software development. So again, we're not getting into the software documentation per se, but we are talking about that software development life cycle. This is in the requirements gathering phase, and even before the requirements gathering phase, these are questions you need to be able to even go into the requirements gathering phase. Who are the players? Who are the people in the organization? Who are the customers? Who is the end user? Is it internal or is it external? If it's external, you may have to go a totally different route to figure out who you can talk to because it may be mobile users. Well, okay, if this is a public app, who are you going to get to test your app? You don't necessarily have one key person, so you may have to go get a set of people to test or give you information on your application. So that's one thing to think about as you're doing these kickoffs. Thoughts on that one? That's actually that's an excellent point is that that I didn't touch on at all is the third party external stuff in particular is that you've got your you've got your team that is part of this. But it also a lot of what you said reminds me of a lot of the sort of like assessment type kickoffs I've done where you you start off talking to, you know, a manager, CEO or whatever it is, you're talking to somebody, a couple of key people, leaders in the organization. But the process from there is going to be reaching out to other people in the organization. So things like an org chart are very helpful. So you can say, what do you have? What do you know? Who do I talk to to get some of this information? And some of that is conversation like who am I able to talk to? Who you know, who should I talk to? And some of that is even what should I know about discussions? Because there are going to be things where particularly when you get into larger organizations, they may have partners that are trusted partners where you can talk about anything. And there's going to be other partners that you have various you need to be very specific in what you say or don't say. Sometimes I've been in situations where there are third parties and they are not supposed to know each other exist internally to the company, basically. You know, where you've got things where it's like you're sort of playing different people against each other or competing or however it is. And so you really want to get that that lay of the land. Now, you may not get all of that in the kickoff, especially the the political details we'll talk about, we'll say. But you want to get some of that kind of information because you do want to be able to at least get that start of who am I supposed to be talking to? And then further down the line, you can come back and say, oh, wait, you're supposed to you need information from that person. But that's not the person you need to talk to. You actually need to go talk to that person. You know, there's there's all of that mix. So the just because they're not in the kickoff doesn't mean there's not some sort of a dotted line or some sort of need for them as you get into your project, just like there is need for you to come back here and listen as we continue to do episode after episode. We are going to continue the developer journey. We are going to continue out on YouTube where you can you can see us instead of simply just listen to us. You can see all of our little hand gestures and realize why I can crank out 10,000 steps a day because sometimes I talk with my hands a little bit. But more importantly, you can give us feedback. You should just email info at developer.com. You can put a get the contact form out at developer.com. Leave us a note there. You can put comments out wherever you get your podcast or out on YouTube and go out to the developer channel, check out all of our content, including this and leave comments wherever you would like, as many people do. As always, like, subscribe, all of that fun stuff that that helps us know sort of who's out there. But more importantly, I'd rather than us. If you're thinking I could like or I could send them a comment, send us a comment. I would rather have a useful comment, a good feedback than, you know, a score of one to five stars or something like that. Give us that feedback because that is what we thrive on. That's how we sort of work our way forward on what's the next topic, what's the next season. Sometimes what are we going to talk about even five minutes from now? That being said, we're going to wrap this one up and just continue. So, you know, don't go anywhere. Come on back soon. We'll be back with more of the developer journey. As always, go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Noor 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.