June 1, 2013 Leave a comment
One of the more common-place (and potentially the most daunting aspect of a project manager’s specific duties), is the notion of creating estimates for project tasks and in turn, creating a more aggregate project schedule. Determining the time required to fulfill specific project tasks and then in turn, merging all pertinent data segments (including dependencies) into a singular, cohesive schedule is by no means a simple task.
Yet in essence, this is arguably one of the most important functions that must be performed prior to a project moving forward in earnest. All individuals that have a vested interest in the project, such as the team itself, the stakeholders, the sponsor and those working in ancillary positions such as sales and marketing will need a tangible time-frame of expected completion for the project.
The project’s schedule itself is likely to be one of the most commonly referenced items in the overall project plan. Stakeholders, the project sponsor and any other interested parties who ask the question ‘How is the project doing?’ almost always want to know if it is on track to meet its agreed-upon target date. Specific KPIs (Key Performance Indicators) will likely have some timeline related metrics that denote whether things are on track, slipping or behind schedule. (The famous green, yellow and red stoplight is often used in this regard)
So as it stands, being able to put together a functional schedule and timeline is going to be a difficult task for even the most seasoned project manager. And in cases of scale, where a schedule is needed for a broader program with multiple projects and various dependencies, one can guess just how complex and difficult this can become.
Fortunately, there are tools, techniques and even software packages that can assist the project manager in their estimation and scheduling needs. Employing these techniques effectively can allow the project manager to leverage the concepts into more complex and larger scale projects.
With the aforementioned in mind, what are some of the more effective project estimation techniques that one can employ to better gauge timelines and schedules for a project?
Analogy Based Estimation
Leveraging analogy is a concept that is certainly not confined to the project management space. Humans in general will often look to the familiar concepts as a way to understand something new or to get an idea of a particular outcome based on experience in similar situations. As such, project managers will often times function in a similar fashion, whereby they look at timelines and schedules from projects that were executed in the past and then attempt to extrapolate some baseline estimation of the current project from those other reference points.
The concept is by no means ideal. Projects in and of themselves may not have been adequately scheduled in the first place and thus leveraging them as reference can lead to a false impression or incorrect assumptions of the current project. A project manager should by no means simply use one project as reference; rather, several similar projects should be examined and an average estimate be utilized from those multiple data points. The concept is similar to a survey attempting to gauge customer satisfaction. One would never simply ask one customer for feedback and be done with it. Instead, a large sample of customers would be polled and their responses would be averaged statistically. In a similar case, a project manager can make projections based on estimated time to complete tasks in previous projects and then use those averages to estimate completion of current tasks with the present project.
As one can guess, this is by no means an exact science. The closer the previous projects are from the standpoint of similar resources, outcomes and tasks, the higher the likelihood of the estimates being valid for the current project. Using this technique does require a fare amount of finesse. But if no other means are available to the project manager, it is a better technique than simply guessing.
Nearly any project will have some breakdown of tasks that need to be accomplished by specific resources that have been assigned. These tasks in an of themselves can become quite granular and as a whole can give a pretty good impression of what needs to be achieved to complete the project. For those familiar with Agile methodologies, the project backlog is a good frame of reference.
Now not all tasks are created equal; some will require more effort than others. Additional, various tasks can occur in parallel with others. Taking those factors into account, a project manager can make decent estimates with regards to timelines for the project by merely evaluating the number of tasks that need to be accomplished and determining time values for each task. With some additional work to narrow down parallel activities and number of resources per task, the project manager can simply apply arithmetic and come up with an estimated time for project completion.
Note that in this situation, it will become important for the project manager to actively engage with the team members to get completion estimates for tasks. This can become somewhat inconsistent in that people may be overly optimistic or overly cautious on how long a particular task will take, depending on their personality type. In these cases, if at all possible, the project manager should leverage older estimates provided by resources to determine how often they have been close to determining how long certain tasks will take. This will give the project manager a bit of a ‘personality gauge’ to use as well. For example, if the project manager determines that a particular resource has a habit of being overly optimistic in giving timeframes for their tasks, a multiplier may be used by determining what the average rate of ‘slippage’ was for this person’s prior tasks. Mathematically, this would be represented as:
Task Estimate X Multiplier = Updated Estimate
eg. If a resource has indicated it will take 30 days to complete a task, and the project manager has determined that this individual has a habit of being overly optimistic with a 25% rate of slippage (their tasks usually take 25% longer than estimated), the math would look like:
30 X 1.25 = 37.5
Note that when applying this type of math, more than one data point should be used. Don’t make assumptions that a person will have a particular multiplier based on only one or two previous task estimates. That will lead to erroneous results.
While not a concept that is strictly in the realm of project management, the Delphi Method (or Delphi Technique) is a mechanism developed in the 1940s by the Rand corporation as a means to more effectively create accurate forecasts based on input from numerous expert sources. The idea stemmed from the fact that accurate forecasts were difficult to achieve in group settings since certain individuals had a tendency to dominate the conversation or whose opinion was given more weight that their peers. As such, not all forecasts were deemed accurate since they seemed to be reflective more of the opinion of a select few individuals as opposed to the weighted opinion of all those involved.
What the Delphi method attempts to do is factor into account all potential voices by leveraging an anonymous form of feedback. Generally, the individual leveraging the technique will contact various experts and provide them a questionnaire to be filled out and sent back. The feedback from these surveys will then be analyzed and common themes extracted. Follow-up surveys can then also be sent to the participants that contain feedback provided from the original survey to further get granularity on the results. Because this is achieved anonymously, no one is aware of who made which specific responses and as such, all are treated equally.
From the standpoint of project management, a similar concept can be leveraged to gauge estimates on specific tasks or project tracks. By contacting knowledge experts, the project manager may ask them individually for their opinion on specific items, which includes time estimates. Those results are then analyzed and an average can be used to determine the most likely timeframes. And as indicated, because these opinions are anonymous, no one individual will have their response placed on a higher pedestal than others.
For those familiar with Agile methodologies and SCRUM, the above will ring a bell from the standpoint of utilizing flash cards with story point estimates that individuals will raise when attempting to gauge the level of effort of a particular task. Although not done anonymously, the concept is still similar in that various opinions are weighted at the same time. As more feedback is provided, a more narrow estimate becomes apparent. The underlying concept of this type of technique will be familiar to those with a background in statistics and understanding of the concept of ‘anchoring’.
Critical Path Method (PERT Analysis)
By far the most mathematical and analytical technique that a project manager can employ as it pertains to schedule and timeline estimations is the PERT technique, also referred to as the Critical Path Method. The concept itself is actually quite intricate and cannot be totally explained in detail in a few paragraphs, other than providing a short definition. (Note: for a comprehensive explanation of the PERT technique, please consult the following posts: The PERT Analysis – Part 1 and The PERT Analysis – Part 2)
To put it simply, the PERT analysis is designed to track major tasks and the primary dependencies in order to determine the ‘critical path’ for the project as a whole. The critical path is basically the least amount of time that will transpire for project completion. It can also demonstrate in a graphical fashion how the specific project tracks and tasks are related to each other and which tasks cannot commence until other tasks are completed. (See following graphic)
As denoted above, the various tasks (represented by letters) have certain time estimates associated with them (denoted by the numbers). To determine the ‘critical path’ for the project, all possible routes through the chart are mapped and the route sums are displayed. The longest timeframe (the highest sum) denotes the critical path.
The PERT concept is probably one of the best visual representations of a project from a holistic timeline perspective. Additionally, by having a very math focused mechanism and the data and calculations available, the credibility of the timeline estimate is given tremendous credence. The PERT system can also allow for other options such as ‘crashing the critical path’, ‘fast tracking’ and dealing with slack and float. (Please read the aforementioned posts on the PERT analysis for more detail)
Estimating the timeline for projects and determining the best possible paths to take is a daunting task. As indicated in this post, there are several techniques at your disposal in determining time values, with many others not mentioned here available as well. The question may arise: which technique should I use? The answer to that is somewhat subjective in that it may depend on various factors, such as the type of project, historical data available, number and type of resources, and so forth. From the project manager’s point of view, it doesn’t necessarily hurt to employ more than one technique and see how well the numbers line up. If you try three techniques and have two of those yield similar results while the third appears to be quite different, that may indicate that particular technique is not as viable for you, or the methods used when implementing that technique may be flawed. Regardless of your choice, it is imperative that the techniques leveraged be done so in conformance with the processes inherent to the organization and its structure. When possible, leverage the knowledge of fellow project managers to get guidance on your own implementations.