Brett Harned:       Hi, and welcome back to The Art and Science of Leading Projects. I have a question for you: How long is it going to take this painter to finish this job? And how much do you think it will cost? Hmm, not so easy to answer, huh? Probably because you have a lot of questions, and that's a good thing. You should never just throw numbers out there unless you're on a game show, but when you're working on projects, you're gonna wanna take a more measured approach to creating estimates. Lucky you, that's what this class is all about, so let's dig in.

So, what is estimation? First, I want you to know that I understand estimating projects is not easy for a number of reasons: teams and talent differ on projects, our approaches to projects change, sometimes we're not giving enough info to create good estimates: the list can go on. But before you say, "Forget it," you have to understand what an estimate is and why you should do them. A big reason it's not easy is because by definition, an estimate is an approximate calculation or judgment of a value, number, quantity, or extent of something. It's just a rough guess. But for some reason, people tend to think estimates are carved in stone, they never should be, they're not exact, they're guesses for what it could take to get something done. That often makes people ask the question, "If our estimates are never exact, then why bother?" And I get that, but there are a lot of good reasons to create estimates, even for those people who just want to start working, or just don't value the idea of an estimate. The thing is, if you do not value estimates, you probably don't try to create them accurately. And if you're a project lead, you might need some powerful and specific reasons to create estimates. Here are just a few.

The first question a solid estimate can answer is, is the project worth it? Estimates help calculate a rough determination of costs which can help decide whether or not the project is worth the investment. So, whether you're on a client side or an internal team, you want to know if the effort or cost matches the potential outcome. For instance, I'm not going to build an app for my company if it costs a lot of money, and I won't see a solid return on that investment. The next question and estimate can help answer is, "Do we have the staff to complete this project?" A good estimate will be based on specific tasks, and the talent used to complete them. So, estimating with staff or even talents required in mind will help you to staff the project properly. Honestly, just exploring what something might be, can help you to determine if you have the right people on staff, or if those people are even available. And if you really need to do the project, it'll make you find those people before you urgently need them. If you're lucky, they'll help you to estimate their time as well.

And then there's the question, "How much time do we have?" You'll probably be wondering about the time needed to complete a project, especially if you're taking on something that you've never done before. So, asking this simple question, "Can we get a sense for how much time this will take?" Is going to help you. You always want a sense for how long something will take to complete, so you can set the right expectations about deadlines, but it's also important to consider that more complex projects can be dependent on other projects or tasks. Knowing just how long it will take to complete your project, might answer an important question about another project, and when it may have to start or finish. Better yet, if you wanna build something for an in person event or an announcement: will you have enough time to get that done? If not, you might have to think of alternative approaches or ideas. But when you create solid time estimates, which we'll cover in this class, you can make some pretty direct assumptions about overall timing, and that's powerful.

The last question is one that not all teams have the luxury of asking, but it can be important to team morale and even productivity, and the question is, "Are we excited about the project?" You've gotta have your team's investment in the project in order for it to be a success. Because working with a team can often be a challenge, particularly when no one has agreement on working on a project. Working together to produce an estimate, can be a great way to pull the team together to ask about staffing, responsibilities, process and even timing. It might also be a good time to do a gut check about how interested everyone is in approaching it.

So, those are some simple questions you can answer by creating an estimate, and even help you to make the case for why you should create estimates, but the questions won't end there. When you get into estimating, you'll ask some project specific questions that will help you to shape your estimate and project scope. But first, you wanna get a high level understanding of these things; your industry: trends, changes and innovation. It's important for project leaders to have a current and ongoing view of what's happening in their respective industries because their projects often come to us as a result of a trend or a change. Projects are also sometimes an opportunity to try something new, so making yourself aware of innovation or big changes on the horizon, will help you to understand, possibly, what's ahead of you in a new project. That might not always help you with an actual estimate, but it'll give you an opportunity to ask even more questions, and figure out what might be coming to you.

An example of this for me was back in 2009, when responsive design became the next best thing in web design. We had to figure out how to estimate for it. That caused a lot of questions and changes to the way we presented work, gained approvals, and even the way we talked about what we did, and that certainly affected our project estimates because we put more time in the process. Later, that changed because we found efficiencies, but having the opportunity to explore the process and create estimates with the team was so helpful because if we had not done that, we have lost a ton of money.

Next is your team and their capabilities: You cannot forget to consider your team. After all, your collective team will make the work on the project happen. And because not everyone works on the same level, you'll wanna consider that. On some level, you should have an understanding of what your team members are capable of doing, and even where they might need some help. It's all about understanding capabilities and expertise, because when you know that, you'll be able to create more solid estimates based on who might be assigned to the project. Next is process: Process will play a pretty big role in how you create estimates. Chances are, you have some general guidelines for how your team handles process. If you don't check out class number two, and tighten your process, so you can consider how you'll do things when you're estimating. I also just wanna note that process can evolve especially if you're using a hybrid method. So, do everything you can to be consistent about conducting and documenting retrospective meetings that way you can continue to learn about what's working and what isn't, and create fair estimates to improve upon those things.

And be sure to check in on projects and understand the complexities of what you do well, and what you struggle with. If you keep a log of work you've done and your experiences, or better yet retrospectives, and notes, or even time logs, you'll find a lot of detail to help you to get better estimates. And that leads me to my last point here, history on similar projects. When you're estimating a project, and you're just not sure how long something should take, look back at similar projects to see how they were handled: That could include looking at plans for timing or even hours logged in a time tracking system to find actual time spent. Just knowing how something worked in the past, will help provide context for how you might approach it in a new project: it might not be apples to apples, but it'll help you to ballpark estimate.

So, those are things you should keep in mind when estimating every project, but there are some more specific questions you can and should ask when estimating a new project. At this point, it's all about drawing out the important details on the project, so you can think critically about what the project will be and how you'll actually shape it. You wanna ask a wide range of questions on topics from goals to budgets, requirements, and more. Grab the estimating questions download and work them into your own estimating process. It'll help you to start an important dialogue about project details before you actually start working on a project, and that will help you to create more accurate estimates. If you come up with additional questions, mention them in the comments below.

Brett Harned:       And I wanna make one more point before we move on to tactics. While you might know the answers to all of the questions I mentioned earlier, it's a good practice to keep them in your back pocket. Just simply asking some smart questions, shows that you're taking a considered approach to creating an estimate, and that shows that you care about how your projects work. Optics are pretty big in project leadership, mostly because no one can actually see good leadership, so make it a point to speak up and share info or ask questions when you can, it'll make you look really good, and it'll also make people trust you, and you'll need that trust when you get to the inevitable, tricky project situation.

Okay, let's jump into some estimating tactics. But before I share the tactics, I wanna mention that it's not just about the project leader sitting at his or her desk, coming up with numbers based on what they know: working in a vacuum like that will likely be counterproductive, especially if there are parts of the project you're just not truly sure about. I know that when it comes to web projects, I know enough to make me dangerous, and that means, I don't know enough about code to sit down and create an estimate for a developer, and that's fair because I'm not a developer. So, I prefer to make estimation a collaborative team process: That way I get the input of the people who'll be working on the project or the people who can represent them in their tasks. I found that estimating in teams brings up more and sometimes better questions, and new approaches, quality discussion on process and collaboration and ultimately more accurate estimates. So, if you can work with the team to estimate, try it. If not use the questions I've shared to dig deeper on the info you need and use the tactics I'm about to present to create your own estimates, but maybe get a second person to do a gut check on what you come up with.

Okay, so first, you should talk about the project with your team before you start throwing out numbers. Yes, that means more discussion, and it'll build on the things you've asked stakeholders: it's necessary. If you think you're spending too much time about the estimate, then scale it back, but if you wanna be really thorough, talk about these things with your estimating team. First, dissect the project goal, issue or feature. This is an important question to agree on as a team, and you'll notice that I've added issue or feature here that's because you can use these estimating tactics when a new idea, requirement or even a bit of scope is added to your project. Sometimes requests come in small bites, and you have to address them as one offs.

No matter what, you wanna make sure you truly understand what it is you're actually designing or building, also, understand the intent: what should it do and why? If you have requirements, great: if you don't start thinking about what they might be, and discuss them with your team and your stakeholders, so you can get pretty clear about what will be included in your scope and your estimate. Essentially, you have to get granular on the 'What' and 'Why', so you can figure out the 'How'. Next, discuss goals: Every project has a goal. If you identify it early on, you can use it as your way finding tool to not only help formulate your scope, but to avoid the inevitable scope creep. Then discuss timelines and resources needed. A project deadline can create immediate constraints on process, deliverables, and sometimes even budgets. So, make sure everyone is aware of that constraint. If you keep your team's availability and experience and expertise level in mind, and look at that through the lens of a budget, you'll be able to decide who is best suited for the project.

Finally, consider stakeholders and partners. You always have to consider who you're working with. As a project manager, I can tell you that not all clients or stakeholders are created equally. Some folks get it and are easy to work with, others need more attention. Diagnosing that early, can tell me how much time I'll need to spend with them, and that will definitely impact my estimate. But also think about how large your stakeholder team is: will they require a lot of education and meetings? Do they work with other partners who will have a role in the project? That's going to take time too.

It's easy to only estimate the tasks, but remember to consider the amount of time you spend in meetings, in Slack, in email, in TeamGantt, on the phone or any other mode of communication you use. So, those are all good discussion points. You might ask, "What is the best way to have those discussions?" I always recommend that teams estimate together and discuss how and why they're coming up with estimates. Simply talking about the variables that contribute to how you're thinking about an estimate, will spark ideas about process, pricing, collaboration, deliverables, and so much more. So, if you work with a team and get into a room to talk it out, you should.

Okay, now that you're armed with the info you need to make some real decisions based on actual facts, you're ready to create the most realistic estimate possible. I've got this traditional project management method in my toolkit, and I use it all the time: not only at work, but with home projects as well. A work breakdown structure is a method by which you can visually represent the composition of a project by breaking down all project stages and aspects into their smallest possible components. So essentially, this method makes you think critically about all of the tasks and sub tasks that make up your project. Here's an example of a traditional work breakdown structure. As you can tell, it's for a birthday party. Project management seeps into our daily lives. Just think about all of the projects you take on in your life: Everything from planning dinners, vacation, home projects the list is never ending. And you can use the fundamentals of what you learn in this class to help manage your own personal projects as well.

So, this work breakdown structure shows the project broken into four groups of tasks: Guests, Location, Caterer and Decorations. Within each, there are sub tasks to explain all of the work that needs to be done for each. Your work breakdown for a similar project or event might not be the same as this one, and that's okay, we all work differently. And that's why listing out steps can be really valuable to talk about process, timing, and, of course, estimates. You'll also notice that there are no estimates related to the tasks in this work breakdown structure, and we want more info than that. That's why I've adapted in a bit. So, to me, because I have a background in web design, this format, kinda, looks like a sitemap: that makes it somewhat confusing to read.

And because it's missing the actual estimate in numbers, it requires a little bit more work. So, I've extended the work breakdown structure a bit. And I like lists, so my format's a little different, but easier for me and my teams to read an edit. Here's a work breakdown structure I created for my own personal project. Well, this is a designed version of what I created, which was actually scribbled on a piece of paper, you'd probably never be able to read on screen. I moved recently and wanted to get a sense for how long it might take, and how much time my wife and I would need to devote to the project. I have to say, this was an estimate and not even close to reality, but that's okay because estimates are guesses, and I learned from it, and I'll do better next time we move.

Check out how I broke it down. First, I listed the high level group as tasks: Searching for a new home, Buying a new home and Moving. Under each group, I've added tasks as well as possible durations for each with a total of days needed. Side note here: when estimating projects, you can use any time value you'd like. I tend to use hours on work related projects and days for home projects. To me, estimating hours is more difficult, but it will get you a more accurate and specific estimate that you can benchmark, especially if you're tracking time against tasks. One place where I screwed up with this, was in Moving. I have packed boxes at five days, and in reality, it took us about seven days. And then Move, was a huge miss as well because while we took two days to do that, it took about a month to truly settle in and know where everything was. But again, that's okay. I was ahead of the game. Just having a general estimate here.

What it comes down to, is that you have to break every larger task down into sub tasks to truly understand the level of effort, and sometimes it's really helpful to get really granular by breaking a task into sub tasks. For instance, if I'm writing an article, I'd break that work down into smaller tasks like outlining, drafting content, thinking about and requesting or creating images, editing, delivering for review, gathering feedback, editing and revisions, proofreading, formatting and presenting. Getting at that level of detail just makes it easier to translate things that might seem big and unmanageable into small, manageable and sizable tasks. You should try it on your own. Download the work breakdown structure homework download and create your own estimate. Feel free to post an image of your work breakdown structure in the comments and I might check it out and reply. So, you may be thinking, a work breakdown structure is great, but I need an easy way of calculating a project estimate in conjunction with an actual plan and resources. How can I do that? TeamGantt can definitely help you and I'll show you how now.

TeamGantt Demo (Brett Harned):          Okay, let's talk about estimating in TeamGantt. So first, I'm gonna build up my plan in TeamGantt to show all of the steps and tasks that will be needed to complete the project. As you can tell here, I'm starting with a pre-made plan. If you want more guidance on how to create plans, check out class number five, or even some of the awesome resources that we have on the TeamGantt website. I do wanna mention that you'll need to be on an advanced plan in order to estimate by hours. So, you're gonna need to do that before you can do anything that I'm showing you in this quick demo. Then you wanna be sure that you've added your team to the plan, so let me show you how you can do that.

It's a couple of ways that you can do this: you can invite people here or you can go over to the people tab. I'm gonna show you how to invite people through this functionality right here. So, it's gonna bring me over to, essentially, the same place where it's gonna show me who's already a part of my project. So, as you can see, I've already added Jason, Lara and Tim to the project, they're all people who are on my team who have accounts, I can also invite people by email, I can add people just based on showing who is in the account already, or I can add a new person here, right? Okay. So, I already had everyone in the plan, so we are ready to go. I'm gonna pop back over to the Gantt view.

All right. So, let's see. Back to where we need to be. I've got all of my tasks in. I wanna go in and add estimated hours, but before I do that, I wanna check my project to make sure the settings are set up to actually have hours enabled. So, I'm gonna go into menu and then I'm gonna go to project settings, in project settings, you can see that there are a bunch of settings here. The one that I'm focused on for this demo is enabled hours. So, I wanna make sure that that's set to yes, so that I can actually add hours to this. So, it's set to yes, and we are all set. All right. So, what am I gonna do? I've got all of my tasks in, I've got all of my people in. I'm basically ready to go in and add my estimates.

So, you might have your estimate on a spreadsheet or some other paper that tells you how much time you should be spending on things. So basically, what I'm gonna do is go to the first task, which is Conduct Stakeholder Interviews, and I'm gonna click on this little button here to the right of the bar on the Gantt chart that says assigned task, and on that, I'm gonna add myself to that. I'm gonna be the person who's doing that, and you can see that it's showing three days on the Gantt chart. And I know that it hours estimated for this was 15. So, I'm gonna say I have about five hours per day to get this task done. You can see I accidentally just clicked on Jason I'm just gonna check him off, but if I do click on him again, I'm able to add his hours there. So, all I have to do is click done. I've got 15 hours set up for myself. You can see it sets it up in the bar, in the Gantt chart at five hours per day, 15 hours total. In my estimated hours column, it's showing 15 hours. Super simple to do that.

So, what I would do is go through all of my tasks and make sure that I am assigning the proper people to do the work at right amount of time, and it's going to keep adding my hours to my estimate. Estimated hours will keep telling up at the top of each section. If I go in here and add some hours, let's say we give Jason three hours here, you can see it's gonna show 12 hours because it's over four days: 12 hours added to that estimate. And then also it adds to the larger estimate at the top of the Gantt chart. So, then when you're done, you can even open this availability tab, you can see 'em down here at the bottom right. Open the availability tab to see the hours that have been assigned to people across days. This is gonna be really helpful if you want to do some workload planning within TeamGantt which isn't really a part of our estimating class, but I wanted to let you know that that is something that you can do. It's pretty simple.

So, what I want you to do after the class, is to check out the homework assignments for step by step instructions and actually do an exercise to get yourself comfortable with estimating in TeamGantt. Okay, let's get back to the class.

(End Demo)

Brett Harned:       As you can tell, you could do your whole work breakdown structure in TeamGantt, and then turn it into a plan by adding dates and dependencies. TeamGantt's a huge help, when you wanna create an estimate for a project that you've got a plan for, or even just to come up with a quick hypothesis of what something could be. Remember, starting a discussion about a project with a team and stakeholders will likely yield a better result than just finalizing an approach on your own. So, make sure you share that plan with your team and make updates as needed. But what about those times when there's just an idea for a project and you don't have a plan? Download the estimating Excel spreadsheet, to help you list your groups and tasks along with your team members, and to assign total time and even a cost to a project. You can edit the doc to fit your needs, adjust the formulas, and find a quick way to create estimates on a large project without skipping over major tasks or deliverables.

I've also used the same Google Sheets, and it works really well when you're collaborating with a team on an estimate. On that note, you might wanna think through a good process for estimating projects with teams. Here's what I found to work. First, collect all background info on the project request and share it with the team who are gonna help you to create the estimate. This could include an intake form, a request for a proposal, an email, or a list of requirements. Just share it all because context is key when you're creating estimates. Be sure to share this info far in advance of your estimating session, so people have time to think about it and read through documents. Next, conduct your meeting: sit down to talk through all the questions your team has. If there are a lot of open items, you'll probably wanna get back to your stakeholders and get some answers before proceeding.

If you're ready to go, crack open your TeamGantt plan or your estimating sheet. Talk through process at a high level and make sure you're in agreement and make adjustments together as needed. Next, talk through the steps one by one, and make sure the person responsible for that step is considering the level of effort required. Make sure you list your assumptions, and document the scope on each task as needed, in case you have to write a scope document that correlates to your estimate. Finalize your estimate, and check out the durations or cost to verify that it meets the constraints of the project. Sometimes, you'll end up out of range and have to go back and adjust your scope or estimates, other times you'll be dead on and feel really confident. But practice makes perfect, especially when you're working as a team. So, keep at it, and work out a process that works for you. When you formalize the process around how you estimate, you'll actually find that your estimates will become closer and closer to your targets over time. That means you'll be less stressed and far more profitable, and that's a good thing.

Okay, those are the tips I have around creating project estimates. I just wanna mention that the process I outlined works really well for Waterfall and Hybrid projects. Estimation in Agile projects is similar, but also just done in a different way. It's most important to remember that you have to set expectations around how you will work with the Agile environments, in order for your projects to be estimated properly. There are a couple of rules to consider: first, if you're truly Agile, your team should work on one project alone and nothing else. If they're not, then you're going to have a hard time estimating their time: it's going to become more of a Hybrid project. Next, in Agile, all work is done in time-boxed sprints, that means you're gonna estimate your time based on the people working on the project over a specific number of sprints. It's essentially time-boxing. In other words, to create an estimate in Agile, you're basically asking, "How much does it cost for a whole dedicated team to work on only one project for a month?"

But it's still really easy to mess up: you have to consider: what roles do you need? How much time is considered full time? Think about company meetings, management tasks and so on. Will your team be truly dedicated? Will there be holidays or time off? There are a lot of questions to answer and expectations to set, but once you've sorted it all out, and set the expectation of the dedicated team and sprint's needed, you can do some really simple math. So, let's look at this example. I never talk about rates because they vary from location to location, company to company, and even person to person. And some companies don't even charge back rates internally, so chances are this part doesn't matter to you. Anyway, we're using a simple round number to create this estimate.

So, let's say it cost your company $10,000 to dedicate one person to a project for four weeks, and your team does two weeks sprints, that would mean that for one person to complete a sprint it will cost $5,000. So, what if your project is six months long? Then you'll need 12 sprints, and let's say your project will require four team members over those 12 sprints: the simple math here would be four resources times $5,000 per sprint that comes to $20,000, but then we multiply that by 12 sprints and get a total project cost of $240,000. It seems too easy, right? Just remember it will never be perfect. People will call out, stakeholders will delay: you'll encounter issues. There's no doubt this is how all projects work. But the ease of this process allows you to truly control scope and process at the same time. Anytime a new change comes in, you can talk about adding sprints to complete work rather than incremental fees you have to estimate. And your flat cost is easy to calculate. In fact, we did it in the example and the cost of the sprint was $20,000: simple and pretty pricey.

Okay, so that's estimating at the project level. And again, even that's problematic because Agile projects aren't supposed to have a specific ending, of course, they end, but until you get into the process, you don't know how many sprints you'll actually need. So, again, it will always be just an estimate. Check out the estimating Agile Project homework download and try this out for yourself, using your own project variables.

I also wanna about estimating at the task level with Agile. The idea with Agile, is that you take an iterative approach to how the work is done, but you break the project into smaller pieces or stories and work on them to ship functionality independently. And the way you determine what can be done in a sprint, is done through estimation. It all starts with user stories. A user story is a tool used in the Agile methodology to capture a description of a project feature from an end users perspective. The user story describes the type of user, what they want, and why. A user story helps to create a simplified description of a requirement, and can help to lead you to a very distinct estimate for the design and build of that requirement. Most teams elect to write all stories using this structure. It helps to cover all of the bases and stay consistent. The most basic way to estimate a task is in what we know as humans: hours, days, weeks and months. The Agile methodology erases your memory of any estimates created with increments of time and requires a different way of thinking about estimates and that's story points.

This is a number that tells the team how difficult the user story is due to complexity, unknowns and effort. Teams use different scales to determine story points. Because story points represent the effort to develop a story, a team's estimate must include everything that can affect the effort: that could include the amount of work to do, that complexity of the work, and any risk or uncertainty in doing the work. When estimating with story points, be sure to consider each of these factors. What we're looking at here is the Fibonacci Sequence to estimate effort. Many teams use this sequence as the basis for producing story points. So, as the story's being estimated, team members select a number in the sequence that they believe represents the level of effort. The most confusing part of using story points is determining what the numbers actually mean in relation to effort. For instance, how do you know that a three means the same thing to the whole team? Well, the best way to determine this, with a first time team, is to sit down and define them. Some teams use Planning Poker to score stories, it's a fun collaborative way to share ideas on estimates and come up with a final determination of a story estimate.

Brett Harned:       T-shirt sizing is another way to score tasks. It's high level, but also relatable, and a simple way to convey the size of something without relying on more detail. As you can tell, there are several ways to do this: you can order a planning deck, make your own or select values that are more relatable to your team. For instance, I saw a cool example that showed London's buildings from size small to large that a team uses to help estimate tasks. So, you can get creative with your scoring. Just keep in mind that story points pull emotion out of the estimates by not talking about time. They focus on task and the size of the task, not the time you take to get it done. The minute you start talking about time, people tend to bring in outlying factors like time off, working time, and other personal things. Story points allow us to focus back on the task and only the task.

At the end of the day, whether you're Agile, or Waterfall or a little bit of both, like many of us, you have to come up with a way of estimating that will work for you. Follow the rules or break them, that sure doesn't matter. Because what really matters is that you learn about how you do your best work and get better at estimating over time. Just so you know, it's never easy. On that note, we asked some project management experts, "What's the most difficult thing about estimating projects?" Let's hear what they have to say.

Carson Pierce:      I think the trickiest thing about estimating is not so much the math, but I think we, kinda, have a pretty good idea of how to break things down and come up with some numbers that makes some sense. I think the trickiest thing is communicating to people, whether it's your project sponsor, or your boss, or the client: communicating that it's an estimate, it's really a guess, and not something that they should be writing in stone somewhere and committing people too. There's the cone of uncertainty that says, "The further something is out, the less we can be sure what it is." And we need to like, communicate that to people, so that the we set the right expectations about what an estimate is, and what a quote is, and distinguishing some of those things.

Colin Ellis:        Well, estimating is one of those things that quite often: it's a finger in the air. Sometimes you use historical information, sometimes we'll gather people together, and ask them what they think, how long do they think that it will take. And I often think that the hardest thing about estimating projects is finding the right people because people are so busy these days, and they'll go out their way to tell you how busy they are, but once you gather the right people, what you've gotta do is to make sure you're not tryna be perfect first time. People spend too long tryna get the absolute perfect day, and it just doesn't work like that. What you've got to do is say, "At this point in time, how long do we think that it will take? Who do we think that we will need?" And then you can work out a bit of a cost.

And it's the same whether you're doing Waterfall or Agile: it's exactly the same. You only know enough at that point in time. So, for me, making sure you've got the right people in the room is key, and then making sure as you iterate, you continue to reevaluate who are the right people to get in the room 'cause if you simply use the same people over and over again, you're closed off to other viewpoints. Always look for the history, always get the right people in the room. Consequently, you get a better job at estimating.

Dave Prior:         Stop trying to make estimates into exactiments. They're guesses, they're bad, they're made with imperfect information, and the problem is that once we make them, it sets an expectation, and people expect that we're gonna be good at it. But if we knew how long it was gonna take, we wouldn't be estimating, right? So, it's important to keep for yourselves. For the people on your team, I always encourage them to track their accuracy with the estimates, so that they can get better and find ways to get better at figuring out: "What things did I miss last time, how can I not do it next time?" But the biggest challenge I see with estimating is that people think that that's what's gonna happen. And so, you've gotta constantly reset expectations with the stakeholders, and help them understand that an estimate is just a guess, and we didn't have the right information to make it, so these things are gonna change.

Obviously, you're gonna have to protect yourself if you're doing budgeting and things like that, so you might wanna leave a little bit of a buffer there. But giving team members the freedom to estimate their own work is really important, and making sure they understand that we know these estimates are gonna change, we know they're not gonna be right, we know there's constantly gonna be flux here. So, that expectation with the team members and with the stakeholders is really important.

Lina Calin:         What's the hardest thing about estimating projects? I think it's optimism. So, often our teams and our management want to think that they can get a task done quicker than actually ends up being the case. In order to solve for this, we can break down all of the parts of a task that might need to be done. You can remind our team that planning, conversations, testing, QA, revisions all of that needs to be a part of the task and included in the estimate. We should also make sure that our team is talking about their confidence level in the estimate that they're giving us and challenge them when they give us certain numbers. And getting a second opinion is also important, so that we're not just taking the word of one person. And by having a conversation where we're going back and forth, and confirming the estimate that was given.

Meghan  McInerny.:         Estimating projects is like black magic: It's inaccurate every time. I think the hardest part about estimating is that people are bad at estimating, and yet, it's a necessity of our industry, and so we're constantly in this cycle of trying to get better at a thing that we're just naturally not very good at. So, what's hard about estimating projects is that it's hard.

Tera Simon:         The hardest thing about estimating projects is that it's just an estimate. A lotta times when you're working with clients, they expect you to be perfect in the way that you are identifying how long or how much money is going to take to do something. When you take a look at putting together exactly what the requirements are going to be, and if you have a lot of those details, it can help make estimating a little bit easier. One of the things that we do, is we stop looking at it from a number of hours that it takes to do something, but really start looking at it from a complexity perspective. We try to break out tasks so that you don't fall yourself hopping between 15 different things in one given day. Instead, focus on, "Do I think it's gonna take me the entire day to complete this one item because it's super hard or do I think I can probably complete it in half a day?" From that way you're looking at it both from a complexity perspective, but also giving your client the reassurance of how long will it actually take to do this.

Brett Harned:       All right, that brings us to the end of the class. I know that estimation is not easy, but hopefully these tactics will help you to tackle larger tasks and break them down. If you do get stuck, ask questions of your team or colleagues or even prospective clients because they can usually offer more information. Don't be nervous about being transparent about what you don't know, because that's gonna help you when you actually work on the project. You'll gain trust, you'll learn more and you'll deliver what the client needs within budget. Also, dig deep, nothing is high level when you create estimates like this. Get into the details, so you can understand what factors are driving your estimates. Look back on similar projects and see what they were like and if they were on budget. If you aren't tracking project histories in the form of high level retrospective notes, or logged hours in a time tracking tool, you should start now.

And finally, remember that no estimates are set in stone. List your assumptions, discuss risks, and work out an estimation process that works for you and your team. Don't forget to grab the class downloads, have some fun with the homework assignments, test out TeamGantt, and get better at estimating. Come back for class four, which will be all about gathering and documenting project requirements.

‍