Parametric Schedule Estimation "Lite"

Marcus Aurelius: “Never let the future disturb you. You will meet it, if you have to, with the same weapons of reason which today arm you against the present.”

Contributed by Wayne Mackey


What’s New?

There are environmental and internal changes that make schedule estimation take on a new level of importance. Parametric schedule estimation takes advantage of this new realm by rapidly providing (in less than 15 minutes) schedule estimates by phase (based on historical data) that can be more accurate than a bottom-up Gantt chart and always engender a more rational discussion than ad-hoc “guestimates”.

In general, things have gotten quicker in this so called “Internet age” where the world is a lot less forgiving when it comes to being late. Beyond just late schedule, extended enterprise design and development require synchronization of disparate tasks to optimize cost and quality. With the standard being raised in many areas (even in overnight shipping), predictability is now very important. The internal evolution of organizations has also enabled a new way of looking at predicting schedule in that many organizations are now using some form of phased development system with the overall timeline broken into a handful of key intervals. This provides a framework for measuring time in a more granular fashion - not just time to market, but time elapsed in a given phase as well.

What Is the Tool? Parametric Schedule Estimator “Lite”

The Parametric Schedule Estimator “Lite” is a tool that guides the estimate of the amount of time a project takes in a given phase by using experience combined with the “critical few” key drivers that impact schedule. There are five to eight inputs per phase for this simple model, which predicts the duration of each phase based on the range of typical times and the technical complexity of the design.

This spreadsheet-based tool has the phases running down the rows, and the time estimates and complexity inputs are in the columns. In the first column, under each phase are the critical few schedule drivers that come from your organization. The knowledge of the organization is tapped by collecting the drivers from the most experienced project managers in the organization. Examples of these drivers for a software project might be the number of interfaces, complexity of system integration, percentage of testing that is automated, and number of geographies. In the second and third columns is the historical range of these drivers (in number or in percentage) represented as low to high. The fourth column is your estimate of the complexity of the project, and the fifth column is left open for comments. The historical range of months is also indicated for each phase. After entering all the estimates for the drivers in a phase, the project manager applies judgment to indicate what the duration of the phase would be, given the various answers to the individual drivers.

The purpose of this tool is twofold. The first is to help inexperienced program managers be more successful, and the second is to help communicate the schedule duration to management. The tool also provides an alternative to the time-consuming bottom-up Gantt chart (although it is recommended that both be used in many situations).

In a pinch, the program manager can use this tool alone. However, the results will be more accurate if the cross-functional team works together to come up with the estimates. In the case of very complex systems, it is possible to decompose the estimation into software, hardware, accessories, etc. After coming up with the individual estimates, the program managers for the subsections should provide an integrated estimate, taking advantage of parallelism that is available in most programs.

What Are the Benefits of this Numerical Estimation Technique?

  • Improves the predictability of schedules
  • Reduces conflict between the team and management, thereby moving the emotional debate to a more rational discussion
  • Can start out simple and gain accuracy over time
  • Is a great way to capture knowledge, especially given the turnover in most organizations
  • Establishes a common language and one familiar visual tool for schedule estimation

Which Business Problems Do We Solve?

Most fundamentally, this tool helps ensure better customer satisfaction and greater competitive advantage. Fast and predictable product development helps satisfy customers who have come to expect a new product every nine months or less. The tool also helps inside the organization by predicting the milestones important to operations and the field.

In the area of product development, the Parametric Schedule Estimator reduces waste inside the organization because of increased predictability. Deliverables can be scheduled efficiently so that they are made available once ready.

What Are some Considerations?

There are several factors that can limit the accuracy of the method. The most important is that if the design paradigm changes, you may not have correct or sufficient baselines to estimate from (for example, if you just started to do remote development or implemented an agile software process). Another factor is that the estimation is inherently subjective, so the estimation quality is dependent on the skills of the team doing the estimate. However, in our experience, we found this tool almost twice as accurate as an average program manager, though less accurate than the best possible program manager.

Case Study

A technology organization with about 200 contributors was having trouble with morale and projects that kept slipping in their attempt to get new product lines to market. Because they are in the consumer electronics marketplace, the ability to have them available for the fall is extremely important. In January, the CEO asked the team to plan a follow up on their product line with a new release for the next selling season. The team was given the market requirements document, and the CEO asked if they could hit it. In the past, it was simply a yelling match where engineering agreed to a deadline and then (unfortunately) did not hit it. This time around was going to be different.

Using the most experienced project manager and the engineer who started the company, the organization decided to put together a parametric estimation process. They collected data over the last three years of releases dating back to the start of the company and determined the drivers (by phase) and then the range of dates from historical data. This constituted a rough draft that they piloted by having several additional project managers apply this to former projects. After doing this pilot, they ended up adding a driver that looks at resources available versus required, and they changed some of the historical data range. Then the estimation process was applied to the project being planned. The result indicated that the project would miss the fall by one quarter. Armed with this data and the market requirements document, the project team was able to convince management to shed some features to ensure that the product would hit the timeline.

The result was even better than predicted in that the team not only hit their deadline, but was also able to manage some slips (internal to the phases), which increased confidence and decreased costs by avoiding a costly third prototype build.



The above visualization shows the blank table template. This needs to be modified for your drivers and projects. It can be helpful in many cases to have different estimation charts for hardware, software, accessories, etc.