The Basics

0:00Welcome to Basic Estimates. I'm Bob, your hostess with the mostest. We're going to talk about a number of things related to project estimates in no particular order. And I'm going to do this with a range of theory to a range of practical use. No particular order. Here we go. So what are we talking about when we talk estimates? We're talking cost and time. But here's the burn. Time is money. So I always like to talk about schedule estimates first, or the estimates to do the work.

0:33Activities. But there's another relationship here you need to be aware of. Do not forget it. These are your triple constraints. You have scope, schedule, and budget. Why does it matter? Because if you change one of these, you almost always affect one or two of the others. And let's face it. Let's be real here. If you change one of them, there's a 99.9% chance you're going to affect the others. So if you change something, just be aware, you should be looking in the other directions.

1:05But those aren't the only constraints. Those are the classic triple constraints, or as I like to call them, the triple complaints. There are other factors involved that impact your estimates. They are risk. If you're doing something well known, the risk level is likely low. But if it's a brand new task, brand new team, brand new location, something complex, risk goes up. And if risk goes up, it's going to take more time.

1:36If it takes more time, it's going to cost more dollars in cents or whatever currency you're using. What about quality? Higher quality, more time, more money to achieve it. If you go from one sigma to three sigma to six sigma, six sigma means you have less than three and a half incidents, I think, or three and a half failures out of one million possible failures. And the only quality standard higher than six sigma is 100%.

2:07What do you think it would cost to achieve 100% perfection in anything? And the answer is, it depends. I don't know. So when you start talking about estimates, it's not just cost, it's not just time. There are other things involved. Let's clear the board and let's start to dig into this. Let's talk about time. Since time is money, I want to start here. I've estimated all kinds of projects largely in the telecommunications and IT space.

2:38And when I say IT space, I'm talking about IT stuff inside of a telecom switch. Servers, data migration, new equipment turn on, retirement, all kinds of stuff. I've seen the good, the bad, and the ugly, mostly good. But if I'm talking time estimates, there are a number of questions I like answered right out of the gate. For starters, who's doing it? Why does it matter? Well, if it's someone who's very experienced, they might do it faster than the baseline.

3:11And let's say the baseline is eight hours, because that's the normal amount of time you have in any particular shift. If you're working 12s, that number changes, obviously. But don't think for a second that you're getting eight hours of actual work out of any particular person. What about breaks? What about lunch? What about people who smoke? What about water cooler talk? What about doing other administrative stuff? Do you really think you're going to get eight hours of productive work out of every worker?

3:41Because unless you're using some form of automation, that answer is a big fat no. It's not going to happen. But let's just focus on experience level first. More experienced people get more work done. It's a fact. Less experienced gets less work done. And then you have mixed experience teams. So who's doing it really matters? Then you have dependencies. That is terrible writing. But you know what I mean. Dependencies. What are they waiting for?

4:13Are they waiting for someone else to finish their work so they can begin? Are there multiple people doing this work? Because you've probably heard that expression, too many cooks spoil the broth. Meaning you can't just throw a bunch of people at something and get work done faster. Because then you can have confusion and you introduce other risk factors. Other issues. Is there new equipment involved? New equipment means there's a learning curve. I can use a backhoe. I can use heavy equipment. It really only takes me about 15 minutes to five days to figure out how to use it.

4:48How much time do I have to learn how to use it before I actually have to implement its use? And it really depends. What about quality? And I already talked about that. I can get a ton of work done if I'm not worried about quality. But if there's the quality standard, I normally have to take more time. What about risk? Risk is a big deal. If I'm around energized equipment, and most people in the IT world are, unless they're writing code, there's an issue there.

5:18What about lockout, tag out procedures? Am I doing the work? Is a vendor doing the work? Is it in the maintenance window? Is it during the day in a live, hot environment? Because here's the real issue. You can work around energized equipment in the maintenance window and not worry about bringing down the entire network or taking customer information or applications offline. But if you're doing it in the middle of the day, during the heaviest data usage time, that's a whole 'nother animal.

5:48You understand my point. I'm comparing apples to apples and I'm throwing in some oranges here, but there are a lot of issues related to time. And there's one more big factor. Tolerance. Your stakeholders are gonna have a very different risk tolerance than you might, or maybe yours is higher. Different risk tolerances change the amount of time and the environment in which you're trying to get this work done. All of these factors are in play as you begin to estimate the amount of time it takes to get work done.

6:21So I promise you, if you feel like this is easy, if you feel like you're off and running and it's no problem, you're probably walking yourself into a trap. So don't do it. So now that we've talked about time a little bit, let's clear the board. Let's wander over to the cost issues. Let's talk about cost for just a moment. Right out of the gate, what's the rate? Different people doing different work have different cost rates. I know what my hourly rate is. A vendor's rate might be different.

6:52Someone who's brand new might have a different rate. So you need to figure that out. And then which schedule are you using? Is it normal eight to five? Is it over time? Is it the weekend, which could be double time or holiday? I once spent eight hours in a sell site on Christmas day and I got paid double time and a half. Don't think my boss was happy about that pay, but he was happy that I was able to fix the issue and get the network back up to speed. What about resource availability? Their availability can mean a different cost.

7:23It also impacts the schedule. What about material? Material costs matter as much as the resource actually doing the work. What about change requests? If you have a contract, there may be a penalty cost to actually doing this work. It just depends and I've seen that. What about inflation? That's a factor. And once again, risk plays a big role here as well. Yeah, that's gonna take me more time in the schedule to get some work done. But here I have contingency and then I have management.

7:54These automatically mean more cost. Think of contingency risk, additional money in this particular case, as additional funding for known or identified risk is, as I like to call them. But then you have management reserve, additional funding for unknown risk. These all factor into your cost estimates. There is a very clear, dynamic, indisputable relationship between time and cost.

8:24And now that I've brushed over, excuse me, just a couple of the questions that if I were an estimator that I would begin to ask, I wanna start to dig into which estimates we could be using based on where we are in the project.

0:00But throughout my project management career, plenty of people have come to me and said, "Look, we know we have a lot of estimating tools. Which one should we use? What's best?" And the answer is, I don't know. It depends on each project, each deliverable, each team's experience level, each team's tolerance level. There are a ton of variables here. But what is known is you have a lot to choose from. So let's take a look at it. The first one, and one of the best ones, is analogous estimating. Big assessments are based on something you've previously done, something similar.

0:34For example, and we're going to go over these again a little bit later on with some examples. But in this example, let's say you had a previous server migration project and it took you two months and it cost $100,000 just as arbitrary numbers. Well, if the scope will work as similar on this one, then you can probably start estimating right there. And it's just a start though. It's not the end all, but it's a good start. Another good one is parametric estimates. Parametric estimates are usually x times y equals something.

1:05For example, if I know I can build 10 feet of fence an hour and I have 200 feet of fence that I can safely build, I simply divide one by the other. 200 divided by 10, approximately 20 hours. And then it's a question of how much time do I have based on availability? X times y equals something. This one's one of my favorites and it's really good for things like equipment rentals, times days and weeks and months, salaries, stuff like that.

1:36If I know everybody's salary and I know how much time you're working with me on a week, it's pretty easy for me to calculate what your cost is going to be. Well, then you have bottom up estimates. Bottom up estimates are slow and detailed. Now riddle me this. The final guess is fast, then this must be slow, which makes you wonder, where are we doing these? Well, probably in planning. And we're going to talk some more about this. Early planning, also planning. There is no one size fits all and there is no one in done.

2:10You can use them over and over and over as you elaborate on the details. Another fantastic one is three point. Also known as PERT, program evaluation interview technique. We're going to have some great examples on this one. This is a good one to use, but this one will get you into trouble. Another one that will really get you into trouble and one of my favorites is expert judgment. An expert said so. Well, who said he was an expert and why is he saying so?

2:42We're going to talk some more about that. But since we're talking about experts, you can get into trouble and it's called group think. What I'm talking about, if you've ever been in a room, as someone has said, you know what? This would be a good idea. Let's do that. And everyone else who wasn't speaking said, yeah, that's a great idea. Meanwhile they're thinking, I'm just going to go ahead and go with what this person is saying because number one, I didn't have an idea. And number two, he's on the hook for it. So everyone raise your hand. Yay, I'm not in trouble.

3:14If you want to eliminate group think, there's another technique called delphi. And it's anonymous. Anonymous. I can get your opinion in an anonymous manner. For example, if I ask five people to write down their opinion on a piece of paper about which technique is best from one estimate to another estimate and they're not allowed to say it out loud, I'll get their honest opinion. I simply poll the results and I can see who said what. That's a great way to do it.

3:44So let's clear the board and keep going. Another good one is top down, which I said earlier, but I like to call this one directed. Meaning you were given a budget, you were given a time frame and now it's your job to fit everything in the middle of it. That one's a little more difficult. And now you have a constraint. And don't forget about the triple constraints. Scope schedule cost. As soon as they say can only cost this much, now this is impacted and possibly how much you can actually produce is impacted.

4:15Transfer bids is also great in the form of analysis. Sometimes it may cost you a little bit more to actually use vendors, but it's a fantastic risk strategy called transference. It's pretty easy for me to put some sort of contract language in there that says if you're doing an IT upgrade or a cut over and you bring the network down, there's a financial penalty. Or if you don't have it back up in time, there's a financial penalty. Or if we get sued, we simply transfer that to you.

4:48Great way to do it. And because of risk, you also have reserve analysis. You must analyze how much additional money you need based on the risk. More risk, more money. Less risk, obviously. Less money. These are just a couple. These are not the end all be all. And since we have a few of them, let's talk about when we might use them. When to use, that is the question. Very early on, when the project is initiating, this is very early.

5:21What do we know? Very early. We know very little. And because we know very little, we need to use tools that take advantage of that. Expert judgment. That's an easy one. Analogous, something similar. And if it's very early, it could be top down directed. One day one, they could say, "This project is due August 1st, and you can't spend more than $1 million, just as an arbitrary number." So initiating is very, very early. Then we get into planning. Does that mean we can keep using these tools?

5:53Absolutely. But we have better tools. We know more, I hope. And when we know more, we can move on to three-point estimates. Or pert. We can also move on to bottom up. Think of it this way. If I know the cost of the wood to build a house, the framing, the drywall, the electrical cost, the plumbing, the shingles, all of the components, and I know the labor cost to do it. I can quickly aggregate it, sum it all up to get me to a total cost.

6:28Bottom up is slow, but it is usually very accurate, which is why you're doing it later in planning. Vendor bid analysis can happen in planning as well, normally nearing execution. And the reason I say that is because most vendor bids are only good for 30 days . Otherwise they'll change them. Look at the cost of material. Look at inflationary costs and stuff like that. You also need to worry about reserve analysis. The majority of risk occurs in execution, which is why we need to know how much management and contingency reserve we need.

7:01All of this is done through something called rolling wave planning. It means we simply revisit and revisit and revisit. Here's another way to look at it. I try to plan my projects from four different levels. I have the strategic level, usually very early. Then I have the operational level. What's the impact to the company? Can we support it because we have normal operations and we have project activities happening at the same time? Then I have activity levels based on people who are doing it, when they are doing it, and then I have task level.

7:39Here I'm worried about in one example construction. Yeah, I know the people that are doing it, but what about the material? And I'm not just talking about construction equipment. I'm talking about personal protection equipment. Gloves, boots, hard hats, vest, hammers, stuff like that. All of this stuff gets rolled into your estimates. All of your estimates get rolled into your budget. Let's take a pause for cause right there and when we come back, we're going to start digging into these individual estimates.

0:00Okay, let's dig into some of these estimates and right out of the gate we're going to talk about initiating. Initiating is very early in the project. Think of it as the project has basically just come to life. It's got a heartbeat. What can we do? Well, the first thing we can do is look at analogous estimates. How similar is this project compared to what we've done before? And I've got a great example coming up. Well, then we have experts. I have been called an expert and it scares me every single time because trust me, when you're an expert, you can't get it wrong too many times and they strip that expert title right away. And then you just go back to above average, which, you know what, I'm pretty comfortable there. Well, then you have top down directed. Basically, someone told you this is it right out of the gate. You have a constraint, but there are things you can do about it. And then I have a bonus resource we're going to get to in just a moment. So let's clear the board and walk down the road of awesomeness. Let's look at an analogous estimate. So it's based on something you've previously done. So let's look at something you've previously done.

1:09Let's say the HR department came to you and said, Hey, we want an internal knowledge database for the HR team using confluence. And you said, Okay, we can do that. So you set it up, you created 25 pages, there was customized layouts, you trained 10 people. And here's the cool part. It only took two weeks with one team member working full time. So not too overwhelming. So that was the baseline. That's the past project. Well, someone else came to you and said, You know what , you did such a bang up job. We'd like you to do it for finance. And you said, Okay, same thing , similar setup, 25 pages, similar layout, only this time there's eight users. You can expect two to two and a half weeks with the same team member. So the first one took two, we've got the same team member. So that gave us the benchmark. Why are we doing that? We're reusing the page templates in the branding, if we can, because we certainly don't want to reinvent the wheel. And finance may need a little more customization. So we're adding a small buffer. And that's why you're ending up with slightly larger schedule. That's how an alic access to making works. And you're probably thinking, Well,

2:25how similar is it? And the answer is, I don't know. But there is a way out of it. So let's take a look at it. Let's add a twist. And here's the twist. They're all remote. What do we do about that? Well, it depends. How big of a deal is it to have remote users? And what's the impact of the schedule? And if there's an impact to the schedule, what's the impact to the budget? Luckily, we have the same team member again. That may not happen very often. And based on the success we've had before, we're only going to add an additional week. And that's because remote coordination, it really comes down to similarity. And you can't put a square peg in around hole, folks. Don't say, Well, this IT project is very similar to this construction project, because we're going to have the same person running it. That is not similar enough. And if you're looking for a cool tool to help you stay out of trouble, I have one for you. So let's take a look at it. As soon as I figure out how to do it, ah, here it is. What you need is a similarity scoring model. And this becomes very important because a whole bunch of people need to agree on this thing and sign off on it.

3:36Here's a great example. Now, these are random weights. I came up with them. I came up with these components. And I just came up with a random example. So let's take a look at them. Is it the same lead? That's very important, particularly if it's someone experienced. Is it the same tech stack? Are you reusing templates or reinventing the wheel? Never reinvent the wheel. The problem is, people take that wheel and they put it someplace on their hard drive and they forget they have it and they never share it with anybody. Don't do that. Share the wheel. Are the requirements similar? Easy peasy, but in this case we're going to say no. Is it the same number of users? This is really important.

4:19It's rarely the same. Is it the same team doing the work? Also very important. Anytime you have a new team member, particularly with Scrum, there's usually a loss of productivity while that team member integrates into that team. Not always, but quite often. Are there the same security needs? I don't know, but could be. And is it the same integration? In this example, we had two nodes, so we basically took the weights, we moved them over here and we added them up.

4:50And then we had a score that everyone agreed to prior to our using this. In this case, it looks like we can use it with some adjustments. Again, you need to do this without incorporating and injecting bias into your scoring mechanism. So if you create this on your own, make sure you float this up to leadership and get buy in across the board. Do not keep it in house into your own department and then surprise everybody else later on, because I promise you, they're just going to push back.

5:23They're not going to do it. It's easier for you to create this and ask for their buy in. Excuse me, then it is to ask everyone to create something together that will take far too long. Do not do that. Create it, float it, make some adjustments, defend yourself, justify, get everyone to sign off on it, and then use something like this on a small project first. Do not go crazy and try to implement it across the board because you will lose your mind and people will push back to the status quo, which is really easy to maintain. I love this tool. Come up with one. And there's one more point here, folks. 80% of what you do is going to be very similar. So there's no reason for you not to have one of these. It's that last 20% that's going to require some movement to the left into the right to get buy in. Those one offs are no big deal. Aim for the 80% and let the 20% work itself out. This will save you a ton of time. So let's look at one more.

6:29As I figure out where my cursor went, let's look at a few more tools here. Well, expert judgment. There's a reason we have experts. They've been there and done that. They have experiences outside of your company. And here's the cool part. They are not concerned with the politics and the internal environmental factors. That's why you need to bring someone from the outside in for really big changes. If it's an enterprise level change, you should have an expert. But when you get them, ask them what other projects have you worked on that are similar to this and what was the cost?

7:05Make them justify. If you're not doing that, they could make anything up. And there are plenty of people out there calling themselves experts. I'm one of them, but I'm not going to show up without past performance approved you. I know what I'm talking about. Other things, is it feasible? I've had people ask me about projects before and it's completely unrealistic. And you have to be able to tell them that and you have to be able to hear that. What are the typical risks involved? Remember , when you're inside the business, you're not seeing what's happening outside. And so you can be looking at the world through what they call rose colored glasses. It looks fantastic until you take the glasses off.

7:45And then it looks like chaos. Everything is burnt to the grounds. Experts have a different point of view. If you don't have a solution, ask them what they recommend. There's a reason you are paying them. Get their opinion. And there it is again, I forgot. What is the solution you recommend? If it's completely bonkers and it's outside your budget, it's just a recommendation, folks. I've seen companies bring in two or three different experts and get their opinions. It's worth the money spent upfront to prevent the money you're going to pay later on reacting to all the problems that came with it. So think about it. Other issues you might have, top down directed constraints. Is it the budget or is it cost? It's almost always one of those.

8:32And as soon as you have a constraint, one of them that normally means you have flexibility. Think about your triple constraints. Scope, schedule, cost. If you tell me, cost is the primary constraint, that means I have flexibility in the other two. What I don't want to hear is, well, all three are as important as one another, because that's just not true. I've never seen it in 30 plus years of project management. There is always flexibility. What I prefer to hear is this one. The scope is absolute. It must be delivered completely, no matter what, which means right out of the gate, you're going to give me more money to do it. You may not believe it right now, but you will later on if the scope is most important. That's a fact. So if it is cost, that means scope is immediately impacted, which means you need to ask, what are the absolute must have deliverables and what are the nice to have? You know what the difference is between wants and needs, cost.

9:31No matter what, why is it the budget or why is it the schedule or the scope? You need to find out why they need to give you a concrete reason. And usually when you figure that out, you can begin to understand where the flexibility is. If they don't know, that means it's all up in the air and they just made it up. How did you get to these metrics? How did you get to this date? These are very important. Project managers, as it relates to estimating, needs to be able to ask hard questions.

10:02I feel like I misworded that, but do not be afraid to ask hard questions. The best project managers I know are impersonal. They are simply gathering information so they can draw conclusions. And if there's a fixed budget, are there pre-approved vendors and licenses we need to be aware of? Because if there aren't, this is going to be a problem. And if it's a predetermined budget, did someone already build in risk reserve? Risk reserve for contingency, for known risk, and management reserve for unknown risk is incredibly important. As soon as you do not have risk reserve built in, you are going to have a risk. And a risk becomes an issue. An issue is a problem. And a problem is something that must be solved. These are hard questions and I recommend you have a list of them when you interview your key stakeholders about any of these estimate issues. So one more. Whoops, I did the wrong thing there. This is one of my favorite estimating tools. Historical information is the best source of estimation that you can possibly have. What happened before? What was good? What was bad? Between the original and the final, you are always

11:18looking for the variance. What was it? Why did it happen? If you can figure that out, you can figure out how to prevent it or do it again. And the only kind of variance you want to do again is a positive variance. And that doesn't happen very often. But when it does, it is spectacular. So ask these questions. And here's the final one. If we had a negative variance and there were lessons learned, did we implement any of those changes? Because if we didn't, whatever happened before, it is absolutely going to happen again. So initiating is your opportunity to ask the hard questions. And if you're not doing that, these problems are going to follow you deep into planning and all the way into execution. And if you get into execution and you have questions unanswered, if you have magic floating around your head, if you're hearing, we'll just figure it out and cross that bridge down the road that bridge is going to burn beneath your feet.

0:00Now that we've taken a look at some initiating estimates when we know very little, let's take a look at some planning estimates when we know more. Let's start with parametric. Usually means x times y equals something. Bottom up, which is slow, but usually very accurate. And this typically happens deep in planning. Three point, also known as pert. There's the formula. P plus 4r plus o divided by 6, pessimistic, optimistic, realistic, sometimes called most likely.

0:30Then we're going to look at standard deviation of our three point estimate, as well as reserve analysis related to risk. So hold on, here we go. Let's start with parametric. And because my writing is sometimes questionable, I figured I would just go ahead and map this out for you so you can follow along. But don't think it's going to be easy. This is going to get complicated pretty quick. Let's take a look at it. Your company needs a new support portal. Okay, everyone needs support. There's a ticketing system of frequently asked questions section, some live chat, log in, log out stuff, and a dashboard.

1:06Approximately 12 functional modules, and it takes about 12 hours per module based on what you've been able to do so far. So far, this is pretty easy. So let's do the math. If we do the math, we come up with about 144 total hours. That is fantastic. But what about risk? What might happen? Maybe we should just go ahead and add 10% for any complexity problems or third party integrations, or anything else that may come to mind based on what you've previously done.

1:37Let's just go ahead and add it. Let's do the math. And when we do the math, we come up with about 158.4 hours. So let's just go ahead and round that up because no one works 0.4 hours. That's just ridiculous. Now here's where it gets interesting. What about the skill level of the person doing it? Are all of your employees equally as skilled as one another? Because I'm betting the answer is probably not all the way to a big fat nope. So let's take a look at what to do about it. We have a skill multiplier.

2:08Let's say the baseline is eight hours, just as a base. And it would be fantastic if any employee could be productive for a full eight hours a day. But I'm going to leave that for another time. So based on what we know about the productivity of our employees, our senior levels has a multiplier of 0.8. Well, what does it mean? They do work faster than the baseline. And they should. They're very experienced. So let's do the math. 160 hours down here times 0.8. Let's see, 0.8.

2:401.28. Put the decimal. It takes approximately 128 hours for our senior most person to do this work. Why? Because they've proven that they get it done faster than the baseline. If we go to the mid-level person, it's 1x. It's going to take them approximately 160 hours. That makes sense. But what happens if we assign a junior person to it? It's going to take one and a half times. Let's take that 160 hours, split it for 80. And if my math is right, I think we're up to 240 hours now to do this work.

3:15And what about the rookies? People who are shadowing. People who are at the very beginning of their career. 2x? This is real stuff, folks. And if you're not paying attention to skill multipliers, you're going to have over-estimated or under-estimated estimates all the time. But what you're really doing is setting a false expectation on when this work is going to get done. And it's going to have a cascade effect all the way through your project. But this is not the only issue.

3:47Let's drive forward. What about availability? And you're probably thinking, "Well, wait a minute. They work 40 hours a week on just this?" Let's say you have a shared resource. That senior person with a productivity multiplier of .8, they're going to be in demand. And we know they can get 160 hours of regular work done in about 128 if memory serves. So let's just go back to 128 hours. Well, what if this person is a shared resource and is only available 4 hours a day?

4:19Let's take a look at it. 128 divided by 4, there's 3, 12, 2. If they're only available 4 hours a day, the activity duration for them to do this is 32 days. It's freaking me out too. And I've seen this a hundred times. But it doesn't just stop there. Let's drive on and throw some more problems at this. Can your resource sustain that pace? Most of them can.

4:49Some of them can't. What if they get derailed with other higher priority stuff? You've just added time to that activity duration. What about upcoming vacation or business travel? Happens all the time. What if they get sick? Okay, well, let's look at the other end of it. What if we just add more resources? That's fantastic. You probably should. You should probably just start with more resources. Or ramp up along the way. There are a ton of reasons why level of effort and activity duration and availability and skill productivity are in constant conflict.

5:26And if you're not paying attention to these, you're going to have overly optimistic estimates that simply aren't going to meet the mark.

0:00It's time to talk bottom up estimating. Bottom up estimating is estimating from the bottom up. It's slow, but it's very detailed. And you can only do this when you know a lot of information or you can figure it out. These are the result of brainstorming sessions and walkthroughs. So let's take a look at an example. In our example, we're going to set up a new IT help desk space on site. Easy enough. Let's go to a workspace and figure out what we're going to do.

0:30So what are we doing? Well, it depends. Let's start with workstation setup. What might we do to set up the workstations? The places where the IT peoples are going to sit. Well, we need to order some PCs. And when they get here, let's put them together. Assemble. Let's call that three hours. And you may look at this and go, no way, dude. I can totally order PCs and set them up in 15 minutes. Well, if you can prove that, that would be awesome. But for now, let's just stick with three hours.

1:00And let's configure those accounts. Let's call that six hours. And again, these are arbitrary numbers. Hopefully, we have some supporting information to back this up. Well, let's connect them. They're not going to be much good if they're not connected to all of your systems. Let's call that three hours. And then we have to install the software. Actually, it's ticketing software. I was trying to be very specific. Let's call that just two hours. And then we have QA, Quality Assurance and Testing. Let's call that three hours. So we've walked through all of this just to order the workstations and set them up.

1:35We come up with 17 hours. That's step number one. Everyone write that down or I'll have a summary forward shortly. So let's clear the board and keep going. Once we get them, what about the physical space setup? What does that entail? Well, where are they going to sit? We need to order some desks, some chairs, some monitors. Well, there's a cost associated with that. Let's call it three grand. That seems pretty reasonable. What about cabling and network drops? Let's just call it cabling. We need cables. We need some network drops.

2:06Someone's paying for that. Let's call that 1,200. Whoops, not 1,000. What about setting up the Wi-Fi? Let's just call that four hours. Do we have signage? I have no idea. But let's call it two hours. And the last one, and this one might surprise you, is PPE. Personal protection equipment to actually do this, like gloves, hard hats, boots, maybe some knee pads. But what about mats? Chair mats. Let's call it another 150 bucks. So where are we? We have six hours.

2:37And let's do some math here. $4,200. All right, now we're cooking with Greece. Let's clear the board and drive on. The next thing we have to do is training. We have to create guides and SOPs. Standard operating procedures, four hours. We also have onboarding. Yes, I apologize if my writing looks very fast. It is very fast. But I'm trying to slow it down. I've had a lot of coffee, but I'm always doing something very fast. What about the ticketing walkthrough? And if you've ever worked with a ticketing system, it normally requires some kind of walkthrough.

3:10How to create, how to escalate, all of that stuff. Let's call that another two hours. Well, then once we have the IT people sitting there, we have shadowing. We want to make sure we have someone on site to support them while they go through their learning curve. So let's call it a shadowing period. Yeah, you know what I mean. Shadowing period. Eight hours. That's one day for three days. Maybe one day a week for the next three weeks. Or Monday, Wednesday, Friday. I don't know. Whatever makes the most sense.

3:42And right now, that looks like 24 hours total. We're sitting at 34 hours. Again, these are arbitrary numbers just for this example. If it were me, I likely got a couple of people together. We went to the empty space and we walked through this brainstorming, putting up little post-it notes along the way. And then we got together and aggregated all of this down to something that made sense. So let's keep going. What about security? You ever seen an IT space where anyone could just walk up on it?

4:12Yeah, I mean either. Those folks are usually secluded. Just like engineers. We put them someplace where they don't have to worry about anyone else because they're doing sensitive stuff. So we have badging. That's an hour. Then we might have policy and firewall updates. That looks terrible. I'm just going to rewrite that. I'm sorry about that. The other part of my brain took over. Firewall. That's what I was trying to say. Let's call that two hours. And then we have asset tagging. Can't have someone just walking off with our stuff, can we? And the answer is no. So we have another two hours for a total of five hours.

4:46There's a lot involved. And we're almost done. But what about all the project management that goes into it? And there is some. Well, what kind of project management? Well, how about meetings? Coordination. That's at least four hours. How many meetings do we have on the project? All of them. How many should we have? None of them. But I digress. What about status reporting? Let's just call that two hours. And that's being generous. And then let's add a buffer just because 6.2 hours. Where did we get that?

5:16Some arbitrary known risk events. And we just added 5%. Just as an example. So now we're at 12.2 hours. Well, what do we do with it? Well, we add it up. So let's do that. I've taken the liberty of adding it all up over here. And here's where we end up. You got the workstations. That's the wrong pen. And how did that happen? Got the workstation set up. Physical space. Training. Security. Overhead. And we had our cost of equipment and PPE. Personal protection equipment.

5:47We end up at 74.2 hours. Let's just round it up to 75. And $4,350. This is our bottom up estimate. Now here's the beauty of this. We can take these activities in these costs. And push them up a level into a work package. Which is part of scope. And we can go to the boss and say, "Here is our deliverable." This could be part of a larger company stand up.

6:17You might have a finance section, an IT section, an engineering section, a visitor section. There's no end to what you can do here. And we can keep adding these work packages and add them all up to get an overall project amount and an overall project schedule. That is the beauty of bottom up estimating. But again, you need a ton of information to make this happen. If you don't have it, you simply use progressive elaboration and rolling wave planning.

6:48Rolling wave planning is where you plan for the things that are closest to you. If you have to begin work, and most of the time we need to begin work much sooner than we should. So with that, let's take a pause for cause.

0:00It's time to test your knowledge, knowledge, knowledge. Okay, that's really me making the echo, but here we go. You have two resources, a senior IT engineer and a junior. There's a skill multiplier here and a cost for each one. Their availability is listed here, two hours for the senior, five hours a day for the junior. They have 100 hours of work to complete and each work day is eight hours. So here's what you need to calculate. Option one is how long and how much for the senior engineer to do it.

0:32Option two is for the junior engineer and option three, the toughest one of all , maybe, is how long and what cost for them to do it together. Good luck and may the force be with you.

0:00So how did we do? Loved it, no worries, or that was awful, and we just aren't friends anymore. Well, let's take a look at it. Another quick review. We've got 100 hours of work, two resources, a senior IT engineer with a different skill multiplier and rate compared to the junior and his rate, or her rate. We also have their availability over here, which I hope you picked up on. If you didn't, uh-oh, let's walk through it together. Here we go. Let's take a look at option one, the senior. That is not, let's get rid of that, the right one. Let's take a look at the senior. Look at the skill multiplier, not multiplier, that's a totally different issue.

0:41There's 100 hours of work with the skill multiplier. 100 times 0.09, it's going to give you 90 hours. Why? Because they're awesome. There's also a total cost times 55. That's going to give you a price of $4,950 because they're $55 an hour, there's 90 hours of work, easy peasy, and based on availability, it's going to take you 45 days to get this done. So we end up with 45 days, $4, 950 for option one.

1:16Take a look at that for just a moment. If you didn't figure it out, hit pause for cause, take a look at it. If my math is wrong, well, I apologize, it shouldn't be, but you never know. So let's clear the screen and move on. Let's take a look at option two, and I 've captured option one right here. Option two is the junior. Different skill multiplier, 1.2, not quite as proficient. If you take 100 multiply by 1.2, you get 120 hours. They have a different hourly rate. That's going to give us $3,960. Three, nine, 60. And how long is it going to take based on availability of five hours a day? You divide 120 by five, you get 24. So now we're actually getting it done faster, and we're getting it done cheaper. So not too tough. Options one and option two were pretty straightforward as long as you caught their availability, and as long as you caught their skill multiplier. But let's take a look at option three, because this one might cook your egg a little bit. Option three is we're using them both together, and this is where things can get really weird. This is where productivity really comes into play. If you look at

2:36the skill multiplier, for the senior, it's 0.9. And if you divide their availability by 0.9, you end up with 2.2 hours of productivity based on availability. This is their output. Okay, I got that. So then we do the same thing for the junior. He's got five hours a day divided by productivity or skill multiplier, if you will. That gives you 4.17. Because the junior is less efficient, the junior's output is obviously less. And if you add them together, you get 6.39 units a day or hours a day of workout put. Well, we know they're available seven hours a day. And if you divide 100 by 14 point or 100 by 7, excuse me, you end up with 14.29 days to get it done. So let's just put that over here and clear some of the rest of this. Because figuring out how long it was going to take was the easy part.

3:44Figuring out what it's going to cost, not quite as simple. So I'm using my magic eraser here, and we're going to figure this out. We know that the senior share of the work is 2.22. We also know that the total output for both of them was 6.39 hours of productivity a day. If we move multiply that, let me just move this back over here. I apologize. 2.22, that's the senior's productivity, his output, divided by 6.39, that's total output times 100 total hours, gives us 34.78 hours that the senior is charging for, times 55. Are you staying with me? If you do that, you're going to end up with $1,913 and looks like 13 cents for the senior. If you take a look at what's left, 100 minus 34.78, you get what's left for the senior. Correction, the junior, which is 65.22. And if you multiply that, times the junior's rate, you end up with $2,152. And 9 cents. If you add them

5:03up together, you have $4,065.22 for option 3. And I hope you were able to stick with that. If not, hit pause, back up, take a look at it. But here's the real question you have now. Which choice is best? And the answer is, it depends. Is speed and getting it done most important? Or is cost? Only you can answer that with your stakeholders. I hope you enjoyed this. And when we get into the next skill, we will continue to raise the bar and do some more complicated estimates. Get ready for it, it's on the way.