How to Improve Software Project Estimation Using PERT

Estimating the time required for software development projects is an intricate task that often poses challenges. With numerous moving pieces, such as evolving requirements, technological complexities, and dynamic team dynamics, accurately predicting project timelines can feel like trying to solve a complex puzzle. There are several unknowns that can disrupt the initial estimation, making it even more challenging to plan and execute projects effectively.

In this blog post, we will delve into a simple yet effective process that can help streamline software project estimation. By leveraging the power of two project planning methods—PERT (Program Evaluation and Review Technique) and WBS (Work Breakdown Structure)—we can bring structure and clarity to the estimation process, enabling more accurate predictions of project timelines.

So, let's dive in and discover how PERT and WBS can transform the way you estimate software development projects, equipping you to plan and execute with greater precision and confidence.

Step 1: Start with a thorough WBS

To estimate software development projects accurately, it is essential to begin with a comprehensive Work Breakdown Structure (WBS).

A Work Breakdown Structure (WBS) is a hierarchical decomposition of the project into smaller components, enabling effective planning, resource allocation, and progress tracking. It provides a structured framework for organizing and understanding project tasks.

You can create a WBS using various tools, but a simple spreadsheet can be effective. I like keeping things simple: I use the first column for adding the category of the task, the second for the tasks themselves and organize rows according to the task execution timeline I expect.

The level of granularity for tasks in the WBS depends on personal preference and project requirements. I generally tend to have 1-6 tasks per feature:

• If I'm working on a simple brochure website, I tend to not write unit tests because features are simple enough to not break after the first implementation, so the 1 task will represent the whole feature, e.g.:
  • Blog home page UI implementation
• If the feature is simple but requires tests, I create one task for the implementation and another one for the tests, e.g.:
  • Auth backend tests
  • Auth backend implementation
• If the feature is relatively complex and has subtasks that can naturally be bundled together, then I create a task for each of the natural bundles, e.g.:
  • Login view UI tests
  • Login view UI
  • Login view validators tests
  • Login view validators
  • Login view submit and handling response tests
  • Login view submit and handling response

On the other hand, it is important to take into into account random tasks that may or may not be linked to a feature such as:

• Setting up repositories
• Setting up servers
• Learning new tools

This level of granularity provides enough detail for estimation purposes while keeping the WBS manageable and focused. That said, how much granularity is optimal depends on each team, so you'll have to refine your own WBS process through experimentation.

By starting with a thorough WBS, you establish a solid foundation for estimating project timelines. In the next step, we will explore how to estimate task durations using the Program Evaluation and Review Technique (PERT).

Step 2: Estimate using PERT

PERT (Program Evaluation and Review Technique) is a project management method that incorporates probabilistic and statistical analysis to estimate task durations. Developed in the 1950s, PERT has proven to be effective in providing more accurate estimations for complex projects.

The PERT estimation formula is as follows: Estimated Duration (D) = (O + 4M + P) / 6

In this formula, the optimistic estimate (O) represents the best-case scenario, indicating the minimum time required to complete the task. The pessimistic estimate (P) represents the worst-case scenario, indicating the maximum time required. The most likely estimate (M) represents the most probable duration of the task.

The weighting of the formula reflects the typical time the task would take if it were performed multiple times, under the assumption that for every six times the task is executed:

• Everything will proceed better than expected once (1 * O)
• Everything will go wrong once (1 * P) (excluding major catastrophes)
• Everything will proceed normally 4 times (4 * M)

The unit of measure we use for the O, M and P values will be whatever that makes the most sense for you and the context of the project. I prefer to estimate using pomodori, but you may prefer using hours, story points or any other time unit that makes sense for the context.

Coming back to the spreadsheet example, if I were to estimate the login page tasks using 20-minute pomodori and applying the PERT formula we'd have something like this:

Step 3: Add buffers if needed

In software development projects, it is important to account for various factors that can impact the overall duration of tasks. These factors include communication overhead, small management or reporting tasks, and other unforeseen activities. To accommodate these uncertainties, adding buffers to the original task durations can be beneficial.

One approach to adding buffers is by applying a percentage increase to the original task durations. This increase is based on historical data or expert judgment, considering the typical additional time required for communication, coordination, and administrative tasks. By incorporating these buffers, you create a more realistic project timeline that reflects the practical aspects of project execution.

So, for example, if based on your experience you estimate that extra tasks take about 20% of the time estimated for the tasks in the WBS, then you'd add that percentage to the PERT estimate you got in the previous step.

On the other hand, if you have historical data on actual duration vs estimated duration of similar tasks, you can calculate a value known as the fudge ratio using the formula (Actual duration) / (Estimated duration), and then multiply your original PERT estimate by this value.

Step 4: Calculate totals

Once you have calculated the time needed for each task and adjust each time value using PERT and buffers, all you have left to do is to add all of the times to get a clear idea of how much time the entire project would take.

Notice that in this step there's no need for extra adjustments because we already made the estimation adjustments at the individual tasks level.

Bonus: Calculate inaccuracy range

Estimating project durations is not an exact science, and there will always be a degree of uncertainty involved even after all the adjustments made to the estimation. However, we can quantify this uncertainty by calculating the standard deviation (SD) for individual tasks and the overall project duration.

You can think of the standard deviation as an "offset" or a measure of how much each value deviates from the common value, the common value being the duration calculated using the PERT formula in this case.

The formula used for calculating the SD for individual PERT tasks is:

Whereas the formula used for calculating the SD for the entire project is:

Using the login feature example, if we calculate the SD value for the initial task, we'd get 1.5:

This means that our final estimation might be off by N 20-min pomodori (because that's the time unit we used) on either direction, either N 20-min pomodori more than expected or finishing N 20-min pomodori earlier than expected.

On the other hand, if the entire project consisted of only the login feature, the steps for calculating the SD for the whole project would be:

1. Calculate the SD for each task in the WBS
2. Apply the formula to get the value (2.915475947)
3. Interpret the value using the same logic applied when interpreting the SD value of each task (~2.9 more or less 20-min pomodori than expected when finishing the whole project)

Conclusion

Estimating software development project timelines can be challenging. However, by leveraging PERT alongside WBSs and time buffers, we can improve the accuracy of our estimations.

This simple 4 step process has helped me to improve project planning and execution and be more confident when presenting estimations to clients and other stakeholders. I hope that by applying this process with your own tweaks you accomplish similar improvements.