There is a lot to be said for detailed requirements. Everyone hates creating requirements documents but they are a very necessary evil. That being said, I've managed a lot of software projects over the years and I have a few methods that I've found make it much easier to estimate.
Personally I can't say enough about Microsoft Project. There are free tools with similar capabilities but MS Project is by far and away my favorite. Regardless of what project management tool you choose these methodologies should apply still.
- Create a list of high level tasks (CMS, site layout, custom coding, etc).
- Begin to add sub tasks and groups of sub, sub, sub tasks from the top level.
Ultimately what your looking for here is to understand everything that's involved. You won't get everything, you'll inevitably miss something, etc but that's not the point of the exercise. As you go through listing every task that needs to be done (put down things like Research X, Test X, etc) you'll discover tasks you never thought about as you go through it. Think of everything that has to be done from planning to building to testing to migrating to the customer.
Once you have all the tasks down you can start to estimate the time necessary for each item. Your times are an educated guess, make sure you pad them with 20-40% (or more) more time than you think it will take. The project management tool you use should have a concept of "Predecessors" or similar. This will allow you to link the tasks and indicate which tasks require other tasks to be completed first.
Now that you have tasks, time estimates and predecessors your project plan can "start" to estimate a timeline for you.
Project management essentially has two primary concepts. Either A, the project deadline should dictate the timeline or B, the project tasks should dictate the timeline. I am VERY much in the B camp. Many MBA types and "bean counters" will try to tell you when the project is "Due". They will also look at your plan and say "if we put 5 developers on task X it will get done in 1/5 the time". These theories are flat unusable in a software development world. While there are some cases a similar concept can be employed, it's generally a recipe for disaster. Imagine 5 people trying to modify the same file simultaneously. They will walk all over each other and even the most advanced source code management tools will fall far short.
OK, so you have an "estimate" now. Yes it's rough, no it's not complete and yes it will change (go back and add more time padding Now). Your probably also looking at the end date and thinking to yourself, the client / boss is going to go nuts when they see how long it will take. This is where you pause and take a deep breath. Not only have you thought throughly through what this project will take but you now have documented detail about WHY it will take this long. If they want to dispute time they have to go task by task to "cut out" time. I've found in 95% of the cases they won't have any interest in do this. You will also (in their minds) clearly understand what needs to be done and be seen as an "expert" in doing it since you have a detailed plan showing what it will take.
Notes: Make sure you put in tasks with estimates in hours where you can. It's hard to dispute something will take 8 or 10 hours. If you put 1 day they start trying to negotiate. There will be tasks that take weeks and months, just put them as such and be prepared to explain why. If you can, break that task into smaller sub tasks in hours / days.
Hope that helps!
Daniel.....
