- The Official Approach (How It Looks on Paper)
- Estimating Project Duration
- Time Management and the Crystal Ball
- Time To Wrap This Up
Time Management and the Crystal Ball
How do we ever know how long any given activity will take? For some activities, you can rely on experience. Other activities have to rely on expert judgment, historical information, and approximation. Approximation?! Yep. Consider any IT project you've ever managed, worked on, or heard about. Each IT project is subject to the first-time, first-use penalty. Just about every IT project is unique. Even if it's an integrator installing the same old piece of software over and over in different environments, there are unique aspects to each environment. No two IT environments are identical. Even if it comes down to the humidity in the air, the ghosts in the machines, or the users who will crunch and crank on the software, there are always differences.
These subtle and sometimes not-so-subtle differences can drive us crazy, or inspire us to take up professional roller hockey. These unique configurations also confound best efforts to predict how long an activity will take to complete. Sometimes you think you know and other times you know that you don't know.
And now a word from reality: That's why estimates are called estimates. Management and customers don't seem to get this part, do they? Have you ever given an ad hoc estimate where you pulled a duration estimate out of the sky? This is a rough order of magnitude (ROM) estimate; a simple, ballpark guess that management and customers are certain to hold you to. No fun for you—just them. I encourage you to not give any ballpark estimates. If you must, add an asterisk to your verbal quote, indicating that this is an ROM estimate and that it can be way, way off—from 75% up to 125%. Otherwise, you're stuck with the number you throw out there. Should your actuals be different from the ROM, you've heck to pay. Right?