As bizarre as it seems, no one sabotages our efforts more easily than ourselves. We often leave ourselves vulnerable to failure whenever we respond to requests for project estimates. Like "A Tale of Two Cities" estimating can bring our best and our worst. In offering estimates, individuals may undercut their own efforts. For example, a developer may only consider time coding, and fail to include enough headroom for testing, rework, or documentation. While some aspects of these estimating attempts might suggest a passive-aggressive approach to avoid tasks, much of this estimate-short-sheeting often results from a desire to please and provide a number to make management "happy." There is always a desire from management to have more things done, and to do things quickly on every project. Even when not stated, this unspoken desire colors the responses of the individuals doing the estimating.
When on-time, projects still are not "safe." On a given project, if some stakeholders feel tasks should have progressed more quickly, then they may believe Parkinson's Law has come into play. Parkinson's Law refers to the concept concerning the amount of work necessary to expand until it fills the available time, like a goldfish continuing to grow until it reaches the maximum supportable size for the bowl in which it resides. These project observers believe that the estimates are self-fulfilled prophesy, as task-doers slow down progress to fill the time allowed. Environments having strict penalties related to missing project dates are likely to inspire an emergence of Parkinson's Law. Alternatively, if dates are missed, or constantly pushed back, Student Syndrome may be considered a contributing factor. Student Syndrome applies to circumstances where people procrastinate until critical dates are imminent, or already passed, before beginning activities.
An estimate should offer our best effort at guessing how long it will take someone to perform some unit of work, write a use case, code a stored procedure, build a web page, or whatever. The aspect of estimating too often assumed then forgotten relates to the level of confidence that the one estimating has in determining whether a task will be completed within the offered time. While familiar repetitive tasks should be estimated easily and with high confidence, new things will have some level of uncertainty. Even the repetitive tasks may have a variance range regarding how long a task may take. Dramatic differences can be seen in project hours planned if one estimates task efforts based on having a 50-50 chance of completing within a stated time versus having a one-hundred-percent confidence of completing within a given time. In helping to address this natural variance, project plans should incorporate buffers at appropriate points. Monitoring and addressing how quickly these buffers are "burned up" is a project manager responsibility.
Project managers need to collaborate with team members to gain acceptance and understanding regarding the planning process so that uncertainties do not overwhelm the estimator. Assumptions about buffers and floats require understanding by all those involved in the process. Equally, a confidence level regarding all effort necessitates an approach from a shared perspective. The project manager should actively manage float/buffer time within the plan. If every team member utilizes an individual confidence level and buffer, only chaos will result. This chaos shows up in projects everywhere. The fear of missing dates can be overcome, hopefully by establishing a practice with realistic dates and people thus enabled to get tasks done efficiently. Tragically, times are such that work gets piled deep and thick, with days where everyone flits about from project to project, providing a ready excuse for why things become delayed. We can work to avoid reliance on excuses.