In a previous video I recommended using deadlines to keep your project on track, and making sure that they're realistic deadlines (or target-dates, if deadlines are too scary). But, how do you come up with "realistic deadlines?" In truth, any estimate for how long a project will take is always just that: an estimate. It's an educated guess. However, there are techniques to make that educated guess more educated and less guess. Here's one that I often use...
Steps to Estimating How Long a Project Will Take
- List all of the tasks that need to be performed
- Subdivide all large tasks into smaller tasks, until the tasks are small enough that you feel confident you can make a reasonable estimate
- Estimate how long each of the tasks will take
- Add up al of the estimates to get your total time (spreadsheet software is made for this)
- Add extra time for testing and the unexpected
- Multiply your estimate by a safety factor. In software you can easily underestimate by a factor of 2-3, depending on your past experience with the type of tasks that need to be done
That's it. It sounds pretty simple, but there are plenty of ways to screw it up. So, here are some don'ts (and dos):
Don't (i.e., Ways to Screw Up and Fail)
- Don't make estimates based on how fast you hope you'll finish tasks (very easy to do). The goal is to get a realistic estimate, based on what you can actually do. Estimates based on hope are a complete fiction
- If you're on a tight schedule or budget (e.g., you're going to run out of money in 3 months). Do NOT go through and revise estimates to fit into your budget. It's easy to start thinking "I could do that faster," but really you can't. This is especially true when you've got the stress of running out of money, because it'll kill your creativity, which in turn will hurt your ability to make design decisions and devise innovative solutions to problems. Again, you'll end up with an estimate that you know deep down is fiction, and you'll be setting your project up to crash and burn in a very stressful manner. Instead...
- If you're on a tight schedule or budget, go through the list and remove tasks/features that aren't 100% needed for your first version. Then, look for tasks/features that can be simplified for version 1.0 (e.g., implement a basic version of a feature instead of the full feature of your dreams). There are always features/tasks that can be delayed till a future version
- Err on the high side with your estimates (but not ridiculously high)
- Factor in that your estimates will be less accurate when you have little experience with the needed work. With little experience, you'll always overlook and underestimate
- Look at the SCRUM methodology's way of estimating how much time a project will take. SCRUM has an interesting way of estimating time that takes into account that we're bad at estimating how much time something takes, but okay at estimating whether one task will take longer than another