Estimating is a critical part of project management, and the Program Evaluation and Review Technique, PERT for short, is one of the most popular estimating methods for this task. And not without good reason! PERT, in addition to helping you to create a project plan, also helps you to make more accurate estimates by considering different perspectives and estimates for each task in your project.
People often try to compare PERT to the critical path method (CPM). However, the focus here is a bit different. Ultimately, it is about breaking down milestones, requirements, features into small and predictable work packages, or more precisely, clearly defined tasks.
The technique was developed by the U.S. Navy in the 1950s to manage the Polaris missile program, one of the most complex projects carried out at that time. The PERT method is based on three estimates for each work package in a project: the best case, the worst case, and a most likely case. A weighted average is calculated from these three estimates, which is then used as the estimate for the overall cost calculation.
More information:
- https://en.wikipedia.org/wiki/Program_evaluation_and_review_technique
- https://en.wikipedia.org/wiki/Critical_path_method
In this blog post, we’ll walk you through 4 steps of how to use PERT as a tool to estimate your projects more accurately.
- Break down your project into smaller topics, features, and tasks to estimate in smaller chunks.
- Determine the best, worst, and most likely effort for each activity or task in your project.
- Calculate the weighted average for each task.
- Add up all the weighted averages to get the overall estimate for a feature, requirement, or the entire project.
Let’s take a closer look at each step.
Step #1: Break down your project into smaller topics, features, and tasks to estimate in smaller working packages.
This step can be very time-consuming, depending on the complexity of the project and the level of detail of the estimate you need. You may also find it helpful to use a visual work breakdown structure (WBS), which breaks down requirements into smaller and smaller packages at different levels. A function-oriented breakdown is usually recommended in software development. The goal is to have estimable tasks instead of having to process vague high-level requirements.
This naturally requires an accurate analysis of all requirements in complex projects. However, the technique can also be used perfectly for individual stories or backlog items in agile projects. In these, a decomposition or a regular refinement of all items is typically planned anyway.
So think about the requirement, necessary tasks and the existing constraints — functional and technical.
More information:
Step #2: Determine the best, worst, and most likely effort for each activity or task in your project.
Once you know the work necessary to implement a requirement, look at it and answer the following questions for each task:
How long does it take to complete this task if the implementation runs perfectly and there are no delays? (Optimistic case)
How long does it take to complete this task if the implementation is likely affected by delays, dependencies or other influences? (Realistic case)
How long might it take to complete this task if the implementation is impacted and disrupted by unexpected influences? (Pessimistic case)
Experience plays a big role for all answers. As soon as you are unsure about answering the questions, you should ask for support. Often a brief discussion about a work package may help. From experience I can say that an estimation session with another person is very valuable. The second person should have a different perspective on the project. Often you can identify gaps in your knowledge in the short term and close them.
Step #3: Calculate the weighted average for each task.
We now have three estimates for a task. So let’s do the math!
To achieve this, take the values for the best case, the worst case, and the most likely case and insert them into this formula:
(optimistic + 4 · likely + pessimistic) / 6.
The calculation gives the time required to implement a task most likely.
Example: we estimate that a validation function for a web form is done in the best case in 1 day. From experience, we can say that we probably have to go through several tests and correction loops and estimate the realistic duration to be 2 days. However, since the implementation depends on a programming library that may not come with all the features we need, the implementation could possibly take up to 5 days.
This results in the following calculation:
(1 + 4 · 2 + 5) / 6 = 2.33 days of likely implementation time.
You can also calculate a possible standard deviation, which you can include in your calculation as a safety buffer:
(pessimistic — optimistic) / 6.
This is always useful if the estimate is based on high or even extreme uncertainty. For the most part, this becomes obvious when the values are widely divergent.
To stay with our example above:
(5–1) / 6 = 0.67 days of likely standard deviation.
If we are uncertain about the details, we can sum the two values to mitigate risk in the planning.
2.33 days + 0.67 days = 3.0 days of likely and planable implementation time for our example.
Step #4: Add up all the weighted averages to get the total estimate for a feature, requirement, or the entire project.
The result is ideally a detailed list of tasks, including their estimated effort. You can use this advantage to create a critical path, for example, to refine and improve your project planning.
We have had excellent experience with this approach. Go for it and make an estimate based on an already implemented project or feature, let the tasks be estimated by people who were not involved in the implementation, and compare the results. Then decide if this technique works for you and your next project.
You can find many templates on the web, mostly for Excel, which can be used as an exceptional tool. In the best case, use them to prepare your upcoming estimates and learn how to apply this technique.
More information:
- https://duckduckgo.com/?q=pert+estimation+estimate
- https://duckduckgo.com/?q=pert+estimation+estimate+excel
- https://duckduckgo.com/?q=pert+estimation+estimate+template
If you want to learn more about methodologies for estimating projects, read our blog posts at https://www.devlix.de/blog/, https://medium.com/devlix-blog or https://dev.to/devlix-blog!
Frank is writing for the devlix Blog at https://www.devlix.de/blog
This article was published first here (german): https://www.devlix.de/quickie-schatzen-mit-der-pert/
Feature image: Photo by Vishwarajsinh Rana on Unsplash
Top comments (0)