Estimating Tecniques - The following techniques can be used at a project level or activity level, or for any sized work in-between.
For instance, an expert opinion can be used to help guide the estimate for an entire project or a specific piece of work. The high-level estimates are typically referred to as top-down techniques.
Top-down techniques include prior history, analogy and ratio. Overall estimates that rely on a more thorough breakdown of the work are called bottom-up.
The WBS technique, for example, is a bottom-up technique.
Top-down estimates are typically quicker and easier to put together. They are usually less precise as well, except for estimates based on previous history and analogy on similar projects.
If possible, you should utilize multiple Estimating Techniques for a project, especially if you are using a quick top-down technique.
This is by far the best way to estimate work. If your organization keeps track of actual effort hours from previous projects, you may have information that will help you estimate new work. In this method, the characteristics of the prior work, along with the actual effort hours, would be saved in a database or other medium that could be searched for new projects.
A person that is estimating new work could describe the characteristics of their project to see if similar work was done in the past. If so, he or she could review prior results to get a good idea of the effort required to do the new work.
Even if you do not keep actual effort hours from previous projects, you may still be able to leverage previous work. Analogy means that you are looking for similar projects, even if they do not have the exact same characteristics as your project. If you have a historical database, that would still be the first place to look.
Otherwise you can describe your new work and try to determine whether any similar work was done in the past. You may be able to find out about similar projects by sending an email to appropriate department managers.
If you find a match, you can talk to the project manager on the prior project to determine how many effort hours the project used, and utilize the information for your estimate. If the prior project team did not track actual effort hours, you may still be able to obtain some estimating help.
The prior project manager should have at least had an original estimate of effort and duration.
Although he or she did not track the actual effort hours, he or she should know the actual duration. If the actual duration hit the estimated duration, you may be able to assume that the effort hours were close as well. On the other hand, if the project ended with a 20% overage in duration, you may be able to estimate that the effort hours were 20% over as well.
For example, let’s say a prior project was estimated to take six months and 2000 hours to complete. If the project actually was completed in six months, there is a good likelihood that the project also took approximately 2000 hours of effort.
On the other hand, if the project was fully staffed and took seven months to complete, you might estimate that the project took around 2300 hours to complete.
Ratio is similar to analogy except that you have some basis for comparing work that has similar characteristics, but on a larger or smaller scale.
For instance, you may find that the effort required to complete a software installation for the Miami office was 500 hours and that one of the big drivers for the effort is the number of people at the remote office. If there are twice as many people in the Chicago office, you may be able to conclude the work may take 1000 hours there.
In many cases you may need to go to an internal or external expert to get help estimating the work. For instance, if this is the first time you have used a new technology, you may need the help of an outside research firm to provide estimating information. Many times these estimates are based on what other companies in the industry are experiencing.
You may also have an internal expert who can help. Although this may be your first time to estimate a certain piece of work, perhaps someone else has done it many times.
The Delphi technique is similar to expert opinion, except that you use multiple experts and try to reach an estimating consensus among them. First, identify two (preferably three) or more people who you would consider to be experts in the type of work you are estimating.
Next, send them the relevant information they need to understand the work. They should send you back an estimate of the effort, along with any assumptions, risks, etc. they identify.
If the estimates are relatively close, you should feel very good about using an average of their input for your final estimate. However, you may find that the estimates are not close to each other, or that some of the estimates are close to each other but other estimates are not.
If that happens, send all the estimates, including the assumptions and risks, back out to the experts for review.
Ask the experts to consider the estimates, risks, assumptions, etc. of the other estimators. Then ask each of them to provide a second estimate of the work. Hopefully, you will find the various estimates closer now, since each expert has a chance to see the work of the other experts. Based on a common set of assumptions and risks, hopefully, the experts can reach a consensus estimate.
If they cannot, you can see if most of the experts have a similar estimate and use that number. You may have to also note an estimating risk in the direction of the experts that were not close to the consensus.
For instance, if three experts estimate work at around 1000 hours, but one expert holds to the belief that the work is 2000 hours, you may need to go with the 1000 hour consensus, with a stated risk that the numbers might be up to twice that amount, based on at least one expert opinion.
A second option if you have the time and inclination is to ask for more expert opinions. This would give you more confidence if the new expert estimates were close to your consensus number, and it would give you less confidence (and more risk) if the new estimates were not close to your consensus number.
Breaking down work into smaller pieces can be helpful when you are creating your project workplan, and it can also be useful as an estimating technique. You may look at a large piece of work and have difficulty estimating the effort required. However, as the work is broken into smaller pieces, the individual components will be easier to estimate.
When you have estimated all the pieces, add them all together for the overall effort. If you have time to create a good WBS, you usually end up with a good estimate. If you use multiple estimating techniques, one of them should be the WBS approach if possible.
The term PERT is often used to refer to a network diagram. However, it is really the formal name of an estimating technique that uses a weighted average of three numbers to come up with a final estimate.
If you are asked to estimate the effort required to complete a project or an activity, you start with three estimates - the most pessimistic (P) case when everything goes wrong, the most optimistic (O) case where everything goes right, and the most likely (M) case given normal problems and opportunities.
The resulting PERT estimate is (O + 4M + P)/6. For example, let’s say you estimate a piece of work to most likely take 10 hours.
The best case (everything goes right) is 6 hours. The worst case (everything goes wrong) is 26 hours. The PERT estimate is (6 + 4(10) + 26)/6. The answer is 72/6, or 12 hours. Notice that the number was pulled a little toward the far extreme of the pessimistic estimate, but not by much, since the result is still weighted heavily toward the most likely value.
In this technique, a pattern must exist in the work that allows you to use an algorithm to drive the overall estimate. For instance, if you know that you can build one mile of flat one-lane highway for one million dollars, you should be able to easily calculate an estimate for ten miles of flat four-lane highway (40 million dollars).
Or, if you are asked to create 40 new reports, first estimate the effort for an 'average' report (perhaps the average of a small, medium and large report). Then multiply the average effort for a report by 40 for the final estimate.
Some IT development organizations use function points as a means to provide meaningful estimates of the work required to complete a systems development project. Function points provide a mechanism to determine the relative complexity of an application.
The complexity can be expressed as a count of function points. In this way, an application of 1000 function points is generally ten times larger and more complex than an application of 100 function points.
Without getting into a lot of detail, function points look at the size of an application from a user perspective. The users see reports, screens, and maybe data files. They also see business functionality, interfaces to other applications, databases, tables, etc.
It makes sense that an application with 80 screens and 20 reports is probably larger than an application with 20 screens and 5 reports.
This way of looking at size is independent of the underlying technology and development language. In fact, the application with the smaller number of screens might require more lines of code, but that is no longer relevant in the sizing calculations.
You cannot do function point estimates early in the planning process. However, once you know the number of screens, reports, interface files, transactions, etc., you can create a high-level estimate of total function points.
Once you have been counting function points for a few projects, you will start to see the average effort required to complete one function point. After that, it is just a matter of applying the math to determine the total effort required, followed by the duration and the cost.
Libro El Director de Proyectos Práctico -
Un Método probado de 28 Pasos para completar tu Proyecto Exitosamente
EL DIRECTOR DE PROYECTOS PRACTICO -
Por fin ─ un libro sencillo con un método paso a paso para completar tu proyecto.
¡Y sin tener conocimiento previo sobre administración de proyectos!
Toda la "paja" de la metodología de dirección de proyectos fue eliminada, dejando solo lo que es absolutamente útil para completar la tarea.
El Director de Proyectos Práctico, Project Management for Small Projects.
Un libro pensado en el líder de proyectos empírico que salió ganador de la rifa del tigre. Pues ya tiene la responsabilidad de un proyecto, pero que no sabe ni por donde empezar. Necesita una receta ABC para seguir.
Contiene 260 páginas perfectamente detalladas con ejemplos e ilustraciones, que te llevan de la mano hasta completar tu proyecto.
Pruébalo, síguelo, ten éxito. O sigue haciendo lo mismo... :(
Compra aquí El Director de Proyectos Práctico en su versión electrónica─
BONO ADICIONAL: El libro incluye todos los templates─plantillas─que necesitas, listos para ser usadas. No necesitas comprar nada mas.
COPYRIGHT © 2007-2012 por Hector Olvera Padilla 1853071. Reproduction in whole or in part, or translation without written permission is prohibited. "PMP®", "PMBOK®", and "PMI®" are registered marks of the Project Management Institute, Inc.