Project Scheduling – Tools and Techniques

All projects have some sort of inherent timeline. These timelines signify the key milestones for the project, itemize the work to be performed and encapsulate the full sequence of events for the product’s life-cycle.

So once a project’s inherent requirements are scoped, how exactly does the project manager determine the level of effort required to complete the project? And how is that level of effort translated into a tangible timeline with key milestones and dates?

Many individuals not familiar with project management often make the assumption that schedules are just simply ‘guesswork’. That the project manager and immediate management simply set target dates based on input from marketing or upper management that is looking to have a release ready for a specific calendar milestone. (Like a new toy for the Christmas shopping season) Now while those are factors for consideration when it comes to the full timeline for the project, in actuality, that is not the main driver of what the project’s timetable actually is nor does it provide any input to determine actual levels of effort to complete a project with a given set of scoped requirements.

With that being said, how exactly does a project manager gauge the amount of time it will take to complete a project, based on the requirements and allocated resources? There are actually some very effective tools and methodologies that a project manager leverages to accomplish this task. Much of the actual methods and concepts are driven by the type of process being utilized, since the inherent counters of effort can vary. So to itemize the concepts effectively, we will break them down by process type:

Waterfall Estimation Techniques

When requirements are scoped and the work breakdowns are created, project estimation timelines can be formulated from input from the key senior engineers. In waterfall, this can generally be accomplished by analyzing the work buckets and gauging level of effort through estimates provided by the engineers as well as reference points from previous releases that had scoped requirements which were similar. The Delphi technique can be utilized to get the individuals to provide estimates on the individual requirements and work items so as to narrow in on an agreed upon estimation of the level of effort for each item. From there, the estimates are pooled and the schedule and timeline are drafted. Note that this estimation technique is easier when there are previous releases to reference, since similar requirements that have common level’s of effort can be used. It is imperative for the project manager to receive level of effort estimates from several of the key engineers (or equivalent) so as to normalize the actual effort (through an average). A smaller pool of individuals providing estimates is more likely to give wider or ‘out of whack’ ranges for level of effort.

Agile Estimation Techniques

In this situation, when the requirements are scoped, you can utilize story point estimates to gauge level of effort. This can then be aligned against the timelines of previous releases (if possible) to estimate the average time it takes to complete ‘X’ number of story points of effort. (Example: average of 20 story points of work completed per week) Once that is performed, an overall estimate of the full schedule can be made based on number of story points going into that release and the benchmark you set for how many story points can be completed for a given timeframe. It is still necessary to get level of effort estimates (which become story points) from the senior engineers in the same manner. Note that in general, this is part of the scope planning meetings in the Agile process. One slight advantage that Agile has over waterfall in this realm is that story points are less abstract that some of the equivalent level of effort timelines in waterfall, since most often, level of effort is in the form of hours, days or weeks. Because story points are not coupled to any intrinsic time estimate in and of themselves, this reduces the likelihood of anchoring occurring.

Formula for New Project Estimations

The aforementioned techniques are often more readily utilized for projects that are part of an iterative product cycle, where there are previous releases to use as reference. But what about situations where the project is entirely new and the end deliverable has never been produced? How should the project manager gauge estimates in that fashion?

There is actually a formula that has been utilized in the industry for determining estimates for specific scoped requirements in situations where the project is entirely new. The formula actually works in both the Agile or Waterfall models, since it is independent of the process:

Estimate = (HE + 4ME + LE)/6

Where the variables stand for:

HE = High Estimate

ME = Middle Estimate

LE = Low Estimate

What this formula is essentially doing is getting three estimates, a high, middle and low. (Note that these can either be from an individual source or a set of averages from several sources) The idea here is that the individuals providing their estimates are given a sort of ‘best case, worst case and likely case’ set of scenarios. By providing all three and plugging them in, the formula is surprisingly effective at narrowing in on what the ‘true’ estimate is likely going to be.


In closing, there will always be a certain level of art coupled with science when it comes to setting schedules and determining the level of effort for a particular release and the requirements scoped against it. But as indicated, there still IS a science involved and project manager should exercise diligence in making these formulations. Simply taking schedules passed down from marketing and assuming that the scoped requirements will simply ‘fit’ is likely going to lead to problems and potential slippage of the project.