 Let the people walk in for a minute here. Thank you. Welcome, guys. We're going to be talking about project management today. Do I have any project managers in the room with me? OK, I've got a few. Who is a playing project manager, and that's not their day job? I got a lot of those. OK. All right, so basically what we're going to be talking about today is some of the different things that we have to deal with when we're either being a project manager or playing one on TV and trying to figure out how to get through everything. So a little bit about me. My name's Jessica Office. I'm a technical project manager at Blackmesh. You can find me on my Twitter handle. I also have a blog on the Blackmesh website. So what we're going to be talking about today is we're going to go over what defines a project. So we actually know when we're dealing with a project versus maybe something that may not be considered one. We're going to go over scope, what it is, how we deal with it, how to figure out what our tasks are, any of our dependencies, scheduling, stakeholders, expectations, which is a big part of what we do. And to touch a little bit about risk, if I went into all of risk, we'd be here until tomorrow. And then tools and any questions you guys might have. So let's talk about what a project is. A project is really something that's considered temporary in nature. So it's not something that we're doing all the time like a systems upgrade or changing the oil in our car or anything like that. It's something that's very temporary. But it also creates a unique product or service. So if I look at that and I use that definition, if I'm building a bridge, is that considered a project? See nodding, yes. What about software upgrades? Is it considered a project? I see some yes, some no. Why would you say it's a project? It's got a time box around some weeks or months or whatever, ideally. Okay, so unique. It's like a project in most part of a continuous product. Okay, and then I saw no. So we're saying unique features in time box for yes. What's our, why are you saying no? Okay, so it sounds like maintenance. It's actually not considered a project. It's considered a task because it is something that we do regularly and we should put a process around it. Absolutely. Very big, I'm putting a process around my upgrades. But I'm not necessarily gonna consider it a project because it is repetitive. It's not a unique thing. It's not temporary in nature. Software upgrades are always, always gonna be a part of our lives. What about processing insurance claims? Project or not a project? Nope, not a project. Same thing every time. Creating a new website? Absolutely a project. Writing a book? Yes, new project. All right, so we know what we're dealing with. We know we have a project. What's our next step? Our next step is really gonna be to start looking at scope. And I know this comic has kind of been going around the internet for a very long time. But to me, it really drives home the importance of scope is we all speak English. We're all speaking similar words, but we don't always speak the same language. When you say swing, I hear tire swing or someone else hears roller coaster. So it's really important for us to figure out what it is we're exactly building, which is why I love this comic. And scope is really defined as the work that needs to be accomplished to deliver that product, service, or result with a specified feature or functions. So when we're setting out on our project, we need to know what it is we're exactly building or doing or trying to accomplish. So how do we go about doing that? First thing is, first things first is we're gonna start talking about it. We're gonna have, we need to figure out what our constraints are, what our requirements are, who's involved, what are we trying to do here exactly? And figuring out that we're, and make sure we're documenting it as well. So we wanna make sure that we have the right people doing the right work and the right job for us at the right time. So for scope, it's gonna start very, very general. I wanna swing. Start, let's walk through this. I want to swing. Okay, that's great. What type of swing do you want? Do you want tire swing? Do you want this weird triple-decker swing? Do you want one that's going through the tree? Do you really wanna roller coaster? What are the features that you need for that swing? And you're gonna start getting narrower and narrower and narrower. So some of the starting places you're gonna have for that are things like your stakeholders, and we're gonna talk about identifying those, but a lot of people get a project charter. It's a great place to start is going through that project charter and seeing what people are looking for, seeing what we're being paid to do. For most of us, we have clients coming to us and saying, I need X or I need Y. So we're gonna start going through and we're gonna start creating that list. And we're gonna be as granular as we can be because it's that whole language piece. If I just say a swing, I could wind up with anything. But if I say I want a tire swing that hangs exactly this far from the ground and it's this big of a tire and it's this color of a tire and it's used with this kind of rope that holds it onto this type of tree, I've got a much better chance of hitting what it is I'm actually looking for. So my scope is where I'm gonna spend a lot of time up front on my project is I need to make sure I know what I'm building before I go build it. Or else I'm gonna start with the whole, well, is this what you wanted? No, not really, okay, we'll start over. And Agile has helped with the scope piece. If you look at the Agile methodology, you have a lot more checkpoints than you did in waterfall. But still you need to know what you're trying to build before you go into it. And then there's the dreaded scope creep, which a lot of you I'm sure have heard the project managers talking about and every time you have a change they're like, no, that's scope creep and here's why. And I think we've all been this guy in the grocery store. I know I have, it's like, I just need three things. It'll be fine, I'm just gonna grab the basket and go. It's not a big deal. And then it's like, oh, but I need this. Oh, maybe I need some milk too. And, you know, some lettuce and some other things. So I think for me it's helpful if you just accept that scope creep is going to happen. It's gonna be a part of your project. Something is going to change. And when you're dealing with scope creep, which basically all that is is it's okay, well, something I wanted I didn't ask for and now I'm asking you to add. When you're dealing with that, it's better to have a plan up front with how you're going to handle that scope creep. You need to accept that it's going to happen. At some point in your project, someone is gonna change their mind. Or some requirement got miscommunicated or something happened where it's not, not what you're expecting it to be. So we know that we're gonna have it. What do we do with it? My thing with scope creep is to make sure that you have a plan to address at day one. Make sure everyone's on board. This is what we're doing. We're gonna be as specific as possible. But if there's a change, this is how we're gonna handle it. And the biggest key with that is communication. You've got to keep talking to your stakeholders, talking to your project team. And then when that change comes up, you've got to evaluate what it's going to do to your project and you can go, okay, you want to change this piece of your project. So here are your choices. You can give me more money to add more people. You can give me more time to get this done for you. Or we can drop other features. So it's really taking and evaluating what that change's impact is. Figuring out, okay, so here are all your choices. I have a preference to what choice I want you to take. I'm going to make a recommendation and tell you why I'm making that recommendation. So I may say, you know, I really think we should add more time because this piece is critical. We went through all of your other features. It's really not smart for us to cut anything considering, oh, thank you, auto update. Considering what you've got going on. Are we going to behave? Okay, sorry about that. So figure out your change request policy and figure out who are the right people to get involved when those changes come in and when people want to change the project. Because just because you have one person saying, it's okay, you need to make sure it's the right person saying that it's okay. All right, so now we know what we're building. We've got to go through this process and this process is going to vary a little bit depending on what methodology you're using to manage your project. But it's going to be the same idea. It's just going to be when you do each piece. You need to know exactly what you need to do to build what you're looking to build. There are different methods. With agile, you usually do the sticky notes and do the storyboards and the user stories. With waterfall, you usually wind up with something that looks like this and you try to figure out all your dependencies up front and figure out who's doing what when. But really your inputs are going to be your scope, your lessons learned from anything you've done that's been similar to this, your subject matter experts and anything in your organizational process. So if you have rules of your organization that are not necessarily a hard dependency but something you have to do, for example, we're in hosting, we don't make your site live until we have monitoring turned on. There's no technical reason for us not to turn on monitoring but that's our organizational policy because it's a horrible idea for us to turn your site live without knowing if it goes down. So that type of stuff is also going to be an input into this list. And then you're going to start determining your major deliverables and this can, again, the way you do this will vary depending on which methodology you're using but you have to design something before you can start programming. You need to know at least a little bit about it before you can start coding for it. So you're going to start getting those purple ones and purple lines there of design, program, test, release. However, that looks in your organization, this is going to look a little different and then you're going to start breaking it down even further and even further. And depending again on which methodology you're using, it may be into stories, it may be into tasks that are think PMIs thing for waterfalls eight to 40 hours. So it really depends on how you want to do that and you're just going to keep going until you figure it out. There are other ways to do this. You can do it in outline format, you can do it in bubble format, you can do it in sticky notes, cross the whiteboard. The major point here is you need to figure out what you've got to do to accomplish your project. So once you've figured out what it is exactly that you are doing, you need to start figuring out if you have any dependencies. So there are a couple different categories of dependency. You've got your mandatory versus discretionary. Your mandatory is a very hard logic so there are physical limitations here. You cannot code a website if you don't have a computer on which to code. There's just nothing there to, you can't do anything. So those are your mandatory ones. Those are the ones that cannot move until the one is solved. And then there's the soft one and that's based on knowledge of best practices. And this goes back to that whole monitoring example I was just using, right, as technically I can launch without monitoring but I don't think any of us want that to happen. So those are mandatory versus discretionary and they're both very important. One you obviously cannot work around if there's a physical barrier for you to do it but the soft ones, a lot of times you don't wanna work around. And then you've also got your external versus internal. So external is gonna be outside your project team's control. It's based on relationships between project activities and maybe outside of the project activity. So for example, if your project team is waiting on a software deliverable from another project team, that's an external dependency because you guys have no influence over that. You can work with that project team, you can ask them, how are things going? You realize that I'm waiting on you for this. We need you to hit this target. How can we help? But really you're not in control of that external dependency. Another example would be hardware. If you ordered hardware and you're waiting for it to be manufactured. Not a whole lot you can do. You can write it in the contract. You can help, they listen to the contract but there are things outside your control there. And then in the internal is within your project team's control. So you have that ability to actually influence it and know the different relationship between the activity. So if I'm waiting on a project team member to finish their code before I can do it, we're all in the same project, we have control over that. So how do I identify these dependencies? A lot of times it's gonna be just brainstorming and categorizing, especially if this is something new that we've never done before. We don't have a lot of those past lessons but if we do have them, that's certainly gonna be what comes in. So we're gonna take a look at everything we have to do. We're gonna try to identify anywhere where we think there might be a dependency. So I can't start coding until I have the right software on my machine or my server set up or I get design in. So those are the different types of dependencies we can start figuring out. And you're gonna rely on a lot of your subject matter experts for this input. As a project manager, you're probably not gonna know all of them. You probably aren't gonna know most of them if it's your first or second project and you're brand new to whatever you're doing. So as you do this more often and as you have software projects more often, there are some that you're automatically gonna know about. You're just gonna be like, yep, these are all the dependencies I have. Now team, come tell me what dependencies you have. But as you're getting started, you're gonna rely more and more on your subject matter experts for this. And then the next part you need to start talking about is okay, I know I have all these dependencies but now when do they have to be done in order for me not to delay what's dependent on them? That's where you start figuring out where things go in your schedule and then trying to figure out what type of dependency it is. Is it internal, external, mandatory, or discretionary? Or more than one of those? And once you start categorizing those, you can also start figuring out how to deal with them and that kind of dovetails into the whole risk discussion we'll have in a little bit here. And then you also wanna document your dependencies. So if you've talked about them and you know about them, doesn't do any good until you write them down so everyone else knows about them and you can communicate them out to your team. Then as you're going through your schedule, make sure you confirm that you have your dependencies covered. Okay, I have task A. For task A to start, I need dependencies one, two, three. Any other dependencies? Are these still legitimate dependencies? Tell me, you know, tell me is this still right? And then as you go through your project and you learn things about your project, you're gonna just keep looking for more dependencies because usually along the way, things will unearth themselves and people will be like, I kind of forgot to tell you that I need this little piece before I can keep going. So you wanna, it's not something you just do up front and then forget about. You're gonna keep visiting that and keep reviewing it. So to manage your dependencies because we love managing things as project managers, first step is gonna be to the identification and documentation of them that we just talked about. Then you're gonna have to align them the best you can. If you have external dependencies, make sure that everyone's on the same page. The external dependency you're dependent on knows about it. So if they have issues, they can tell you as soon as possible. Align your timelines, make sure that you guys stay in communication with your external dependencies and then just keep an eye on them. And if you see one kind of going off the rails, keep it, try to get it back into where it belongs. So I know what I'm doing. I've got my scope, I've got my tasks. My next thing is gonna be schedule. And there's a few things that go into schedule. We've got your task list, which we just talked about. Your resources, so do I have the right people? If I have the right people, do I have all their time? Do I have some other time? When do I have their time? A lot of things that people I see get bit on is effort versus duration. So I've got a task that takes 40 hours. I've got a resource who I have 50% of his time. I schedule him for a week to do that 40 hour task. My math does not work now because I've only got 20 hours of his time. So that is the area where I've seen most project managers get bit is that whole effort versus duration because, and customers as well, because they don't realize it. They're like, well, this task starts today so it's gonna be done in a week, right? And you're like, well, no. I've got this person for 50% of their time so I need two weeks to hit that 40 hours. So you need to make sure you balance that when you publish those dates to your client or to your project team or to whoever it is that you're working with. People actually know that, okay, this is the date it's not, oh, it's a week long activity. As soon as we start, it's done in a week. That is, that's a big one that I've seen many. I know I've been bitten by it when I was first starting as well. So, and then you're gonna have your dependencies that you're gonna keep into that. So make sure you know that your schedule's gonna change. It's a project. Everything's gonna change at some point. Yet to meet a project where at least one thing didn't change from start to finish. So make sure you know how to handle those changes. Do you have time in your schedule where if something drops you've got a little extra time? Not usually, but let's be honest with ourselves. We usually don't. We're usually trying to cram everything in. Are there contingencies I can put in place at this point? Is there anything that I see that might be a problem if it slips? And then it's again keeping constant contact with your project team and see if things are starting to go a little slower. Figure out why. Figure out is there anything you can help them to unblock them? Figure out is there anything we can do? Do we need more people? Do we need more money? Which again, we usually don't get, but it's how do we solve this problem? Because as the project manager, you're also there to help unblock your people when they get stuck. So biggest players here are your stakeholders. Stakeholders have a variety of different definitions and different roles. You've got your employees can be, are your stakeholders, your project team, your public company, shareholders, your customers, community and you've got, if this project is impacting them, they are a stakeholder. Now not all stakeholders are created equal. We're gonna go into identification in the next slide of your stakeholders. There's a couple ways I've seen people classify their stakeholders, one being internal versus external. So if they're an internal, they're a group within the business or the people who work directly within the business. So they are your employees, your project team, or there's also external where they are outside of the business. There's also direct versus indirect. Your directs are directly impacted by the project versus a peripheral impact on the project. So when we talk a little bit about identification and analysis, we need to figure out who our stakeholders are. We need to figure out who's important in that stakeholder list because given our definition of who can be a stakeholder, and this could be anybody, especially if you're in the business of designing a website, it could be the entire world because they're gonna be impacted if they go to your website. So you need to find out a way to identify and figure out which stakeholders are the important ones to listen to and which ones you need to add, how you need to treat each stakeholder. So when you're going through and you're making your list of who your stakeholders are, you've got influence versus interest. And this is really how you can figure out who you can use to your advantage, who you need to communicate with a little bit more, who you can rely on and who you need to come to when you've got changes. So I'm gonna start in the top left and you've got someone who's high influence and low interest. So this is a tricky person because they've got a lot of influence, but they're not really interested in what you're doing. So if you get on their bad side, they can use that influence not in a good way for your project. So what you wanna be doing and how you wanna treat them is, get them engaged, consult them a little bit, figure out what their needs are, try to get that increase, increase that level of interest and see if you can move them over to the right, which is key player. And that's the person that you really wanna keep engaged and on your side if you can. Some key players you can't, but those are the people you really do wanna keep engaged and keep moving and you're gonna focus your effort on this group of key players. So if you have, the person paying your bill is usually gonna be a key player. A lot of the people in your client base are gonna be your key players. You wanna involve them in the decision-making. You wanna make sure they are engaged and consulted on a regular basis. These are the people you're gonna be talking to a lot for your statuses, for your decision-making. That's where your key player is gonna come in and the more people you can move on the high influence, low interest over to that key player, the better off you're gonna be because you've got the right people who can influence the direction of your project. And if we go down a level, we've got the low influence and low interest, you're gonna keep them informed if they wanna be, it's gonna be general communication, maybe an email status update or a newsletter. You're gonna just let them know what's going on but not really do a whole lot with them. If you do find an interest picking up, you're gonna wanna aim to move them to the right, which is high interest, low influence. These guys are gonna wanna just show them consideration and use that interest to your benefit if you can. Involve them in the low risk stuff where it's an easy decision, that it's an easy win, they can feel more involved. You've got a cheerleader on the ground for you. If it's a not so popular project, it's always good to have as many of those around as you can. Consult them in their interest area, keep them informed in their interest area and then use them as that positive influence if you can and just have them help you, especially with some of our projects bring about change and as humans, we're not so good with change sometimes, so it's always good to have those folks on your side. So how do I manage my stakeholders? Communication is the biggest thing here is we need to know who wants to know what, when do they have a preferred way to be communicated with, do they want an email, do they want a phone call, do they want an IM, do they not care? But when I need an answer from them, I need to know how to get a hold of them and how the best way to get a hold of them is. And then I also need to understand their needs and that's the biggest point is, we've got stakeholders who are spending all this money on this solution, they're gonna have their own needs that need to be filled. Are they nervous about something? Have they been bitten by somebody in the past? What's going on there? And some of them will open up to you, which makes life really easy if they're just gonna be like, well, yeah. Just got burned from my last software dev shop and here's why and here's what I need from you so I feel better about moving forward and I'm comfortable. And some of them are like, I don't understand any of this, just make it happen. Show me a pretty picture at the end of the day and I'm good. So you really need to understand where your stakeholders are coming from and what's driving them, especially for those key players that have that influence and power and interest in your project. You wanna see what those needs are so you can make sure you're meeting them and building that partnership between you and them. Sometimes that means they need a daily call. I have one project where my main player at the height of the project I was talking to seven times a day on Skype, on a Skype call. Thankfully, that only lasted a couple of weeks but that's what he needed to feel comfortable to move forward in this massive project that we were working on. So sometimes it's a balance of finding the time to have seven calls in one day and sometimes it's finding another way to make them feel comfortable but ultimately you wanna be communicating and wanna have that partnership with your stakeholder especially your key players. But on the flip side you also need to be able to set their expectations. I think we've all been on this call where they don't care, they want it now. They don't want it in a day, they don't want it in a week, they want it yesterday and they want it now. So for your expectation setting the biggest thing is to get started early. Set those expectations. I cannot move forward on X until you give me Y. I need you to know that I'm dependent on you to move forward. I need your sign off on design before I'm going to spend money to start building. I need your information on what you want me to do before I can do it. And if you keep starting that early maybe not that forcefully at first. Hopefully not that forcefully at first. If you just start going okay, so here's how it's gonna go and here's what we need to move forward. Let's start setting those expectations and making sure people know who's responsible for what instead of having that meltdown towards the end of the project or when they realize that deadline's been missed. And make sure you've got the stakeholders involved as early as you can. So I think we've all been in that project on some end or another where it's like so yeah, we forgot to talk to this stakeholder over here and he's got an entirely different set of requirements that we kind of didn't take into account because we didn't know about him. We wanna try to avoid that it's not always avoidable especially when you're working with clients and you can't always see behind that main contact that you have but you need to make sure that you have a plan for that. And if when that does bubble up you need to acknowledge that it's a change. You need to acknowledge what the impact of that change is so this goes back to, okay, I need to add this feature. What is that? What are my options? How can I get around it? Can I drop a piece of something here? Am I running ahead of schedule over there that I might be able to slip it in? Do I need more money? Do I need more time? Do I need more people? What is it exactly that I need? Another big thing with setting expectations especially with stakeholders is be realistic. I think we've all been part of that team where somebody over promises and under delivers and that really leads for some awkward conversations and it also sets expectations poorly. So I'm not saying lie. I'm not saying lie to anybody. I'm just saying be realistic in your responses. Can you give that to me tomorrow? Well, let me see what else is going on. No, I probably can't. But I can get it to you by Tuesday. Is that okay? If not, help me understand what's okay. And if I've got other things I'm doing for you, what can I switch out to get you this by Tuesday? And if they say nothing, then that's a whole other negotiation. We've all been there too. I can tell by the faces in the room. But if they say nothing, that's when you have to start negotiating. But if you get to the point of being realistic with them, there's going to be a little more trust built there on your average stakeholder. We all have the not so average stakeholders that we've dealt with before, but it's for another time. Be clear also in your communication is if you think, if you're the more specific you are, the better your expectations are going to be because it goes back to that whole language. When I say swing, I mean one thing, someone else sees something else in their head, someone else sees something else in their head. But again, if I say, well, it's a tire swing and the tire is this big and the rope is this long and it hangs from a tree with a branch that's high, we're gonna be on a bigger page. So the more clear you can be, the better off you're going to be. Also, make sure everyone's clear with their roles and responsibilities. What am I responsible for? Why would someone come to me versus my head developer versus the stakeholder versus a manager? Make sure everyone knows what part they're playing in that project. And they have a little bit clearer expectation on, okay, I'm having this problem, I need to go to that person. And the default as project manager is they're gonna come to you because you're gonna traffic cop that in a lot of cases. And then make sure you also within that have an escalation strategy of if things do get out of hand, either on our side or your side, this is how we move up that chain and this is who we go to talk to that can help unblock us, that can help move us, that can help get things moving again or solve those problems. And then the other thing is, try to make sure you're communicating, just tell them the good news, tell them the bad news, tell them the bad news when you know about it, don't try to cover it up and then tell them. Be frank with them, be a little honest, talk to them about changes and talk to them about status, whether that's in a meeting, whether that's in email or phone call, however they prefer it, make sure you've got that status going. And if you can, and I know this is so much harder these days because we're all just distributed, there's still something to be said with FaceTime, with your big stakeholders. So if it's possible, which I know it's not always, getting in front of them in person also helps build that relationship and partnership. And if you can't, there's always things like Skype or HipChat or Slack or Hangouts or something where you can start reading those facial expressions and getting to know each other that also helps with any communication blunders too, if we have a tone and email problem as we're getting to know each other. And we've all been there where that tone, you read it like three days later, you're like, oh, I really didn't mean it that mean. I don't know how to fix that, but if you've got that relationship and they know how you talk and see your body language on a somewhat regular basis, you're gonna, that's not gonna be taken as seriously as if they're just still getting to know you. Your stakeholders and your setting expectations and those relationships are going to be one of the most important parts of your project, simply because we're all in this together, we all need to get through it together and we can't do it without each other. So as soon as we can get that relationship built and get things moving in the right direction, it's a little easier to keep expectations in check. So a little bit about risk. I picked this particular picture because risk is often that tightrope. You don't wanna be the ultimate paranoid project manager who says everything's a risk and oh my gosh, the world's on fire. But at the same time, there's that whole keeping things in check, keeping with reality, keeping our eyes up on what might be coming without causing chaos. So it's very much that tightrope that we're walking over the cliff with the water running below us. Unfortunately, I can't go too far into risk. I'm gonna cover what I can and am I doing on time? I've got about 20 minutes. So project risk is really defined as an uncertain event or condition that if it occurs, it can be either a positive or negative influence on your project. So risk can come from a lot of different places. It can come from unknown stakeholders like we just talked about where they're like, oh, hey, I have all these things I needed to do and I didn't tell you, sorry. It can come from external dependencies. I remember one time I was working on a data center refresh and we had everybody lined up to start moving their stuff and about a week before we were supposed to start putting stuff on hardware, we get a call from our manufacturer that their tsunami had hit where the manufacturing plant was and we had no ETA on when our servers would get to us. Not really something you can predict. Not really something we accounted for. We did after that, but the first time that happened, it really wasn't something that we even dawned on us at that time, we're so used to we order it, it comes, we order it, it shows up and gets on the boat and then eventually it's in the data center in Virginia. So we were working on it and it impacted a massive launch at that point because we didn't have your new servers. We had no control over it. Ultimately we found another provider, but it still added time to the project that we had absolutely no idea about. Your customer stakeholder availability is also a big one. If you're expecting sign off or information from them and they're on a three week vacation, that could be a risk to your project if they are running up against that vacation, where they're about to leave, that can impact you greatly. Technology, sometimes technology doesn't work the way we want it to. And when that happens, that can certainly be a risk. If we're trying to code something new or do something we've never done before and we start hitting roadblocks that we didn't anticipate, that can be a risk. Scope, schedule, both risks, because they're always changing. We want them to change as little as possible, but they do actually change. So that can be a risk. And then a new law could come in and cause a risk. So if you were in the middle of doing something with government and they said, okay, well we now require everything being FedRAMP and you don't have a FedRAMP provider, that could be a problem because you now can't have nowhere to launch your site on. So that's not a comprehensive list by any matter, but the idea is make sure you're looking not just at your immediate surroundings for that risk, look anywhere you can think of. But also remember that risk can be positive or negative. That's another thing is as project managers, we tend to focus on those negative risks of if we miss this, we're gonna be late or we're gonna go over budget or we're gonna lose this resource or or or or. And okay, well what if something works out where we didn't expect it to and it's awesome and now we have a new great problem of, I don't know what to do with all this attention that I'm getting from my project. People are interested in it, it's selling or this piece of technology is really interesting to the community and I need to be able to account for the positive risk as well as that negative risk. And the key really here is just like everything else we've been talking about is you wanna make sure you identify it. Usually initially it's gonna be brainstorming just like everything else with your project of, okay guys here are the risks I see, what risks am I forgetting, what do you see, what are things that we need to keep an eye out for. I like to put together a risk register which basically has an identification what the risk is. Is there a high likelihood, medium likelihood or low and then I'll do the same for impact. So if it's, yeah, this is probably gonna happen but if it doesn't, yeah, it's not that big of a deal. I'm gonna pay different attention to, this is really probably gonna happen and we're derailed if it does. So it helps me classify my risks that way. And then I'll also have a date that if it happened, you know, if I think that it needs to happen by, if it's gonna happen, it's gonna happen by this date so I don't pay attention to old risks and who's responsible for it and if we have a response. And there are a lot of different responses that you can have, you can have, we're just gonna accept it and deal with it. You know, it's, there's nothing we can do about it so we're just gonna have to accept the consequences. We can avoid it. So for the example of the server with the tsunami, I could, I could try and find someone who doesn't manufacturer in a tsunami prone area. Though I don't know how possible that is anymore. Tsunamis are showing up everywhere that has a coast anyway. I can, so I can avoid it, I can accept it, I can transfer it so I can buy insurance or I can make it somebody else's problem or I can just, there's fourth one that I'm forgetting right now, I believe it's ignore. I'll have to look at that. So those are my four responses for negative risk is what am I gonna do? How am I gonna respond, mitigate? How am I gonna mitigate that risk? And really go from there and figure out exactly how I wanna respond to it. And I'm gonna review that and I'm gonna keep reviewing that. And as risks fall off and okay, this isn't a risk anymore, I've got the servers in my data center, not a risk, I can stop it. Are there new ones coming up? So you wanna keep talking about your risks. I'll usually do it weekly or if we're meeting less often than weekly, I'll do it when we meet. If we meet daily, I'll usually do it weekly just because talking about it every day is usually a little much. So your key on that is identification and then continuous review, continuous determining of your response. Some of the tools I know, I know there's way more out there that people use. I know a small project, I've seen people do all of their project management outside of Excel, in Excel. Not sure I recommend that. But it's certainly there and if there's some other options, if you wanna do collaborative, there's active collab. A lot of people use JIRA Basecamp 5 PM. OmniPlan is the yellow one that has no name. MS Project. So there's a bunch of different tools out there that you can use. The best thing I can say for a tool is figure out what you want it to do and then try and figure out what fits it the best. There's never gonna be an exact match and I'm curious what the project managers out here use. Trello? You use what? Okay, I haven't used that one. Why do you hate it? Active Club is very structured I find. I've not used Trello, but it sounds like it can get out of hand very quickly. How do you control that? How do you keep that rained in? I'm... You're working on it. Okay. That's a fair answer, still working on it. All right. Any other tools that people use that you wanna talk about? Google Docs. We're not allowed to use Google Docs where I am because of certain FedRAMP restrictions. But it is handy. I have a lot of clients that use it. It's definitely an easy tool. Any feedback? Feel free to tweet me. There's my handle again. That's all I have for you guys. What do you guys have for me? What questions can I answer? It's Saturday afternoon. I'm seeing a lot of blank faces. Sorry, I didn't hear the second part of that question. So when I'm going through the task identification, how far do I go? So just to repeat for anyone who didn't hear you. Basically, in the beginning of a project, this also makes sure I'm getting your question right, the beginning of the project, the tasks are very, very well-defined. And then as you look out further, the tasks are more and more loosely defined and always changing. How do we handle that? Is that? Yeah. Okay. It really depends on what version of what methodology you're using for your software development. If it's waterfall, you should be very, very granular all the way to the end. A lot of dev shops aren't using waterfall anymore. I've seen a lot of dev shops that are doing kind of a bizarre hybrid between Agile and waterfall because it's a hard transition to make that jump from pure waterfall to pure Agile. And there's a lot of figuring out new processes. And that's usually where I've heard the, we're very, very specific at the beginning and then we kind of start getting bigger and bigger as we go. And for those, are you doing sprints? Okay. Yeah, I've been there. You do the sprints, you don't adhere to them. The biggest thing on that is your sprint planning. And if you're not doing sprint planning, you should probably start talking about doing sprint planning where you start breaking those big tasks down into something that's actually achievable during that sprint. And with the changes, again, it's really that communication piece of I need to make sure that, okay, you've just changed everything on me. You realize what we've just done. There may not be anything usable if everything changed or X, this sprint is now, we're not using it. So we need more time or we need to drop functionality or we need to figure out what our options are and here, Mr. Stakeholder, here's your list of options, choose one. Let us know what it is that you're looking to do. And I saw some nodding over here. I didn't know if you guys had anything else to add on that. I've worked in the bizarre hybrid. It's challenging. It's challenging. Okay. That's challenge. I think I saw a question over here. You're beginning on your starting so that they have a chance to really feel how much they can actually handle because people always are optimistic when it's been followed. Just assume that you're not gonna be able to complete it because time and time again, my teams have overestimated how much they can handle and you're always gonna expose more dependencies or more functionality than you expect to have within the sprint. So that's how items start to spill over from sprint to sprint. That's a good way to try and mitigate that. Yeah, they're doing more and more on research on how many projects a person should be working on at any given time and then how many hours you should actually schedule them for. So we've got an eight hour day but realistically, nobody's working all eight hours of that eight hour day. They're gonna get up, they're gonna need coffee, they're gonna get interrupted by someone at least once or twice per hour. There's all of this research going in is like you really can't plan for eight hours. The last number I heard I think was six and a half hours is realistically what you can plan for in a day. And that number goes down even further if you've got this person spread across several projects because there's that time for content switching of, okay, I'm doing this, this, okay, now I've gotta put this down, I'm gonna go start here. Okay, now what was this again? And there's that time, that transition time that isn't accounted for because we're like, okay, we've got eight hours, I'm guilty of this too, I've done, I've got eight hours in a day, gonna use those eight hours and you're gonna work on these three things. And it's like, no, realistically, that's not gonna happen because it takes too much time to keep switching from, okay, I'm doing this project. All right, I'm putting this down. Now I've gotta go look at this one and figure out where I am on that process. So there's a lot of interesting research coming out on that field right now. Any other questions? Yes? When you're estimating, I've seen places talk about card systems with that guy or how do you get enough input to have a valid estimate instead of my best guess and one other guy's best guess? Right, so estimation is tricky because there's not as much science behind it as we would like. I could be talking to a senior engineer and ask him, well, how long does it take? And he'll be like, well, that's nothing, it's like an hour. And then I go to the junior engineer who's assigned to it and she's like, I'm sorry, an hour, what? So it's, for me, I'm fortunate enough that I'm working with the same project teams on my end. The clients, obviously, are always different. But on my end, I'm fortunate enough where I get to know the team and I know who overestimates. I know who underestimates. I know who I can go to. I had still a lot of art, unfortunately. And I saw, where was I? Somebody did a talk on turning estimation into a science and not an art. And I think it was Drupalcon LA. That was really, was that Drupalcon LA? Okay. It's by like three different, it was by three different people, I wanna say. But they had gotten further than most project managers I've seen on getting that and encourage you to find the talk from Drupalcon LA and look at it. But basically it is figuring out how do you turn that? Cause there's so many unknowns when we go into a technology project. It's like, are they learning a new code base? Cause that's gonna be a while. That's gonna cause, you know, what normally should be an hour task or someone who knows it is gonna be a lot longer for someone who doesn't. So for me, it's really considering the source. You're gonna learn who your overestimators are. You're gonna learn who your overpromisers are. Figure out the level of the person doing it. And then, you know, if you know that they're an overpromiser, tack some time onto it. If you know they go a little conservative, maybe shave an hour or two off of it. I wish I had a better answer for you on that one. I really do. Yeah. So we're, yeah, we're contract basis for where I am. I've been on the time and material side. Clients generally aren't fans of time and materials because way too many unknowns. But as far as managing risk and factoring it in, generally when I'm putting together the schedule and we're going through our risk plan, it's like, okay, you realize that if this risk happens, it's gonna do X, Y, and Z to the timeline. And generally, people don't want the time built in unless it's, you know, we know that it's gonna happen at which point it's no longer a risk. It's an issue, right? So it really depends on the client and how conservative they are as well. So my biggest thing with risk as I start, as soon as I see the big one, I will start beating that drum and I will tell anyone and everyone who will listen to me that's on that project that this is about to happen. This is coming. I need you to pay attention to me, please. And I need you to accept that this is happening. And if it does happen, I need you to tell me how you want me to handle it. Here are all your choices. Please pick one. But that's usually what I'll do. And some of our risks have financial implications and some of them don't. And it really depends on where that falls. And if there is a financial implication and it's a risk, but it's not one that your company is involved in. So for example, I was doing a giant migration. They had to be off their servers by September 30th, but they weren't getting me the credentials in time. There's no way we were gonna take that financial impact. It was, hey guys, remember those credentials you promised me? I need those if you want me to meet this deadline. If I don't, you're going to be responsible for this because we can't do our jobs. This is the amount of time I told you I need. Any other questions? Mm-hmm. No, it was, let me see if I can find it real quick. Yes, thank you. Who did that one? Okay. So it was Drupalcon LA estimation, science.nart. Thank you. Any other questions? Going once? Going twice? All right, well thanks guys.