[MUSIC] If a project is unique and temporary, and has a defined start and finish, well then you need to define that start and finish. And of course your stakeholders, especially your sponsor, will want to know how much the project is going to cost. The Guide to the Product Management Body of Knowledge discusses estimating in two separate knowledge areas, project cost management and project time management. We are gonna draw from both of those areas for this discussion on estimating. In fact, most of the approaches you use can work to estimate how long something will take, or to estimate how much something will cost. Right now, let's begin by thinking about activity durations. Remember, by activity we are referencing a piece of assignable work, what some people might call a task. If you fully decomposed your work packages, as we discussed previously, then you have your activities identified. You know what work needs to be completed. You can use this to estimate how long each activity will take. This is gonna feed into your schedule. Whether you are estimating costs or duration, the best estimates come from experience. Whenever possible, you want the person who is doing the work to estimate the work. You also want to try and stay away from providing estimates before you and the team have had a chance to really determine the scope and really look at what it will take to complete the work. You are often pushed to provide estimates as soon as a project begins. And unfortunately, you may never recover from incorrect estimates provided too early in the project. Estimating at the activity level is an example of bottom up estimating. You look at the detailed work and provide estimates for each piece of work. If we are completing cost estimates, we add up all of those estimates to get an idea of our project budget. If we are estimating time, we use this information to create our schedule. To determine the amount of effort it will take to complete an activity, the person completing the estimate might look at a similar task and use that as the basis for his or her estimate. Revisiting the training for the redesigned human resources hiring processes. If the training is online, your estimator may look at the last time he or she created online training modules that had similar requirements. Then he or she might add to or subtract from the estimating, depending on the differences. Maybe last year he or she developed a course with three modules, this is gonna be four. So he or she takes the actual time it took last year to develop the three modules and increases the estimate by what one additional module can take. This is called an analogous estimate. Now it's possible that he or she realized that each module does take a pretty specific, consistent amount of time. Perhaps modules of a certain size and complexity take four hours each. Then the estimate would be created by taking the number of modules, which is four, and multiplying it by the number of hours per module, which is also four. So that would be 4 x 4, 16 hours. That approach is called parametric. Parametric estimating works well when you have good historical information which can be used in a reliable formula or model. There is also an approach called apportioning, and this is a top-down approach, where you assign estimates based on a percentage of the total. Now when I say top-down, I mean that you don't go to the work packages and create estimates for each of them. You come up with a total for the entire project, or perhaps a section of the project. Maybe the human resources hiring processes were redesigned five years ago, and we still have that data. And by looking at the data, we see that we spent 25% of our budget on planning, 25 on designing, and 15 on training, etc. We might now use those percentages to allocate the budget. You can use this for a schedule at a very high level, but to create a good accurate schedule you really want to get each and every necessary activity into the schedule with the proper estimate. Apportioning can be good for discussions about the pros and cons of the project, and perhaps to even help come up with some estimates for project selection, or maybe even the charter. As long as it comes with the caveat that the real time and cost estimates will be created when the project scope has been detailed. We have seen how some estimating approaches can be used for both time estimates and budget estimates. Now let's focus on the cost estimates with an eye for creating a budget. The more detail you have, the more likely you are to have better estimates. When you have decomposed your work packages to the activity level, and you have a duration estimate for each activity, and you identified the resources you need for each, you can create a budget that represents the scope of your project. Going back to our example of the online training for the redesigned human resources processes, we know that the development is gonna take 16 hours. Remember, 4 hours per module and there were 4 modules. If our developer makes $50 per hour, we know that this activity has 16 labor hours. And therefore, we have labor costs of 16 times 50, or $800, in US dollars. Of course, we also want to know if anyone else will participate in this activity and if any special materials are needed. If so, we need to add those in too. As you create your cost estimates, consider also documenting your basis of estimates. Your basis of estimates, or your BOE, reflects how you arrived at your estimates. And this is why I call it the what was I thinking documentation. When things change, and something is bound to change, this document helps me understand my original thoughts behind the estimate. And helps to gain an understanding of how other parts of the project may change. In our example, we are using a resource who earns $50 per hour. When it's time for the work to be completed, the planned resource is not available. In order to keep the project on schedule, the developer's team lead takes on the work. The team lead makes $55 per hour. Rather than change resources, a decision has been made to keep the team lead for the duration of the project. Now we know that the test to develop the training modules will take $5 more per hour. Instead of $800 US, it'll be $880. That gives us a budget variance of $80 where the variance on the task for the resource is assigned. When you have good notes, you can report the big picture, not just the information for one specific activity. This is a good place to discuss padding, or adding a little extra to the budget to protect yourself. You might think well, if I already had an extra $80 and I budget, I would not have to worry about this. The official way to handle your concerns about perhaps needing a little bit extra is to create either a contingency or management reserve. When we pad, or we put away a little extra, we failed to capture the true picture. And we have the tendency to use up that pad. Sometimes without even knowing where it went. Contingency is what we use for work packages. Maybe developing the online modules is not as straightforward as we would like it to be. Maybe this time the developer's gonna use some new software. He or she thinks it will take four hours per module, but because they're using new software, it could take more. The right thing to do is note that there is some risk that the activity will take more time. The goal is to try and complete within 4 hours, but perhaps an extra 30 minutes per module is set aside as contingency. Then the cost estimate is still based on the 4 hours. And some cost contingency is set aside to match the potential cost of an extra 30 minutes per module. When the activity is worked on, either the extra time is needed, or it's not. If it is needed, the contingency is used to cover the time and the associated costs. If it's not needed, the contingency goes away and the money that was set aside is released. In this way, the project is not hiding extra funds which, if not needed, could in fact be redistributed to another project. Management reserve is time or money set aside not tied to a specific work package, rather it's tied to the entire project. Perhaps there's concern about the overall budget. Maybe an extra 10% is put aside in addition to the budget. This money can be used to cover some things that come up that are not covered by contingency. Now your actual budget is created by summing up all your estimates. And your budget is gonna have categories such as labor, materials, equipment, or the categories that are relevant to your type of work. Your budget is time phased, that means you map out your plan costs by time. You show what you will spend throughout the life of your project. Your budget is to be approved by the appropriate parties. Once it is, you have a baseline budget. This is your original promise. When you report status and you discuss costs, you are comparing what is actually happening to your baseline. If the budget had been baselined with the developer at the rate of $50 per hour, then the team lead with the rate of $55 was used instead, you would report the difference and you would explain why. Now right now we're discussing the budget, but you also create a scope baseline and a schedule baseline, too. An important tip for you. If you are new at creating project budgets, see if you can work with someone in your organization who has created project budgets before. Ask for samples of actual budgets, and look at the baseline versus the actual to learn about what type of variances might occur. Each organization has their own way of budgeting, and it is important that you budget the proper way for your organization. That's it for now. See you in our next module.
