Estimates are wrong if you cannot beat them half of the time; they are also wrong if you are not late half the time. Neither condition is one that should make management upset. In fact, matching that score is a great accomplishment. So how can people get so emotional about the statement? The answer is that people do not understand estimates and how they work. Through years of estimates being treated as quotes, we have been brainwashed into thinking our best effort is to meet the date, not better it. Heaven forbid if you are late. This lack of understanding is very evident by the number of blogs on the subject and some of their bewildering comments. The comments point out wildly different views. Some people think that Monte Carlo analysis gives you an estimate that has a 95% chance of being right and others believe that using Agile relieves people from having to make estimates entirely. Both of which are plainly not true.

Why is it that tasks always seem to be late? No matter how much time we allot, there never seems to be enough to complete a task on time. There is one overreaching reason pervasive throughout the enterprise—poor time management. To accommodate the continual barrage of supposedly urgent tasks, we heavily pad estimates. Excessive padding triggers numerous negative work patterns. The extra time and over confidence in estimates allows people to accept other unrelated tasks, introduce low priority features, and strive for perfection. It is unfair, however, to saddle the individual with the entire problem; the work-place culture reinforces and rewards the behavior.

The policy reads, "Before you can proceed, the PMO needs to approve the design gate." So, you begrudgingly wind down the project so the slowest members of the design team can catch up. A week, maybe two, sometimes even more flash by. The rest of the project team starts finding work on other projects. Once the PMO finally gives the project the green light, you will need to wait for people to complete those other tasks before they can focus on your project. Precious time is lost.

Estimates are a pain in the... er... butt. Everyone hates doing them. The reason? They are always wrong. They are either too optimistic, when we think we know more than we do, or they are overly padded, trying to account for the unexpected. Other times it is much more subconscious. Some little voice in the back of our heads is working on our conscience to change the perception of the work required. We can be our own worst enemies when it comes to creating estimates and do even more harm when we go to work the task. For now, let us look at a couple factors that influence how we determine the length of time it takes to do simple tasks and save the effects of that estimate for another article. With a little audience cooperation, we will produce a fun answer from a simple mental exercise.

Todd's first book delivers twenty-five years of project rescue experience. Unlike other books on the subject, Rescue the Problem Project focuses on the process to rescue the project. This is the critical few weeks that transform a failing project to a successful project. Other processes blindly layer processes on top of a project without finding the cause of the failure. Rescue the Problem Project focuses on root cause analysis to determine the source of problems and solve them once and for all.

The book starts by discussing the biggest hurdle in rescuing a project—realization that there is a problem—and proceeds through detailed discussion of the four-step process to recover them—audit, analysis, negotiate, and execute. In addition, it includes a complete discussion of four key processes to prevent failure.

People, who know me, are aware I am less than enamored of certifications and titles. Therefore, when I got my PMP many were taken aback, some laughed aloud, and, since I seemed to get it overnight, all asked why and how I got it. However, it is not just my situation, this is a perennial question in online forums and groups and it is a common topic at local project management meetings. In many of those discussions, people try to analogize the PMP to a CPA or MBA; without question, the requirements to get a PMP have none of the independent educational rigor of college level degrees. The PMP's worth is visceral and personal—it depends on each individual's goals and their project management experience.

Last week I had coffee with fellow tweep, Peter Kretzman, at the Zeitgeist Coffee in Seattle. We had a wonderful conversation and shared stories, philosophies, and impressions. In the process we stumbled upon a common literary love—The Mythical Man-Month by Frederick Brooks. I read it for the first time last summer and Peter reads every few years. We both extolled the virtues of the book and lamented at the fact that so many of the items Brooks brings up continue to plague us today.

The two most common project attributes that raise the red flag are cost and timeline problems. Both are easily measured and inextricable intertwined. As the timeline extends, there is a commensurate increase in cost; similarly, as cost goes up (usually from increased scope) the timeline increases. However, time is different. Benjamin Franklin said it best, "You may delay, but time will not." Work can stop work (controlling the burn rate) and extraneous features can be removed (decreasing the required work), but time marches on. We cannot control time. Although intuitively obvious, the concept seems to escape a large number of managers and executives.

The quickest way to get lost, in business or in your personal life, is failing to make decisions. Not knowing where you are headed increases stress and frustration. It would seem natural, then, that teams on projects beleaguered with indecisive management would be excited to have the logjam broken by a dynamic, decisive leader. Simply put, they are not. Every decision has its opponents and they are bound to be irritated, feeling they have lost prestige or stature. However, turning the decision into action requires a unified team. One of the best tools to accomplish this is to understand what impeded decision making and tactfully educating the team members on the source of the problem. This will garner their backing and improve their willingness to support the decision.