My previous article covered the benefits in using both a bottom-up and a top-down approach when estimating project effort. However, the best activity estimates will not help to bring your project in on time if the underlying estimates of team member availability are inaccurate.
I’ve written extensively about my belief that the inability to accurately estimate team member availability is an equally critical, but less publicized project risk than poor scope management, requirements challenges or bad governance.
In projectized organizations, this risk may not be realized as staff are dedicated to specific projects and until they complete their assigned activities on those, they are not likely to handle a different project. In such environments, the main source of team member risk is likely to stem from unexpected attrition or reduced productivity.
However, most of us work for matrix or functionally structured companies. In such organizations, it is very rare that a team member would be fully assigned to a project. Most likely, staff are splitting their time between multiple projects and many will also have operational responsibilities. Frequent readers will know about my loathing for multitasking and this infographic provides a very powerful depiction of the negative impacts.
When team members split their time between project and operational work, regardless of the maturity of the project estimation process, estimating operational utilization is as predictable as attempting to forecast (with any great deal of accuracy) what will happen in the stock markets.
You might argue that if time tracking is being done, it should be possible to come up with a reasonable estimate based on the previous year’s actuals.
Let’s take the example of IT analysts who split their working time between project and operational work with the majority of this operational work relating to resolving production system and application outtage issues which cannot be handled by first-level support staff.
Just a couple of the factors which could significantly reduce the accuracy of a previous year’s production support time actuals are:
- If the technology infrastructure has increased in complexity (e.g. if projects completed in the last year have increased the magnitude of the “base asset”), support work could increase. Conversely, if there has been a simplification in the complexity of the technology infrastructure as compared with the previous year, support allocation may decrease.
- If the number of users on the systems supported, or the number of other analysts who perform the same support function changes.
The silver bullet to slay this particular PM werewolf is simple – don’t have project staff also handle operational work. Unfortunately, in many organizations, a lack of cross-training or simply insufficient staff renders that option infeasible.
If so, the next best option may be to use actuals from a previous year, but to calculate and apply a weighting factor which attempts to analyze what has changed.
To plagiarize the popular mutual fund prospectus disclaimer: Past actuals do not guarantee future availability!