Scheduling a project correctly? Almost impossible!

Scheduling a software project, I can't say that it's enjoyable. To say that it's complicated, risky and very unreliable task is agreeable for me. All the task durations set are all guestimate, basically based on hunches. After all, who can measure software development correctly. And to imagine that everything would go smooth is one thought that should never cross your mind.

The latest schedule that I arranged was a schedule for documentation project, actually it was a product reverse engineereed and documented. We have a client bought the product and they're interested in buying the source code along with the complete documentation.

At first, I thought for this project I was a bit lucky, no development needed. The thought that I forbid to cross my mind actually entered in. Thinking that documentation are all measureable, I began to arrange the schedule. The project started and after a month passed by, I begin to notice that problems start to creep in along with their surprises :

1. New things to be documented start to pop up, things that I didn't see in the first place.
2. Tools that we used sometimes stressed us up, even M$Word! The documentation has reached almost 500 pages, when my team tried to format the doc sometimes it stopped working. And still not to mention other tools we used. Are we picking a wrong tools here? Nope, I don't think so. Problems definitely will be met whatever the tools we picked.
3. Human resources. When one member of the team quits, it left a hole that couldn't be filled straight away.
4. The skills required. Not everybody has the skill to document, create diagrams, read existing code.
5. Interrupt. I have to help other project and what can I do but to assign my time to help.
   

I hate the idea that working over hours is the only solution to finish the project on time. I prefer working smart, which are :

• Finding patterns repeatedly used in the documentation. I'm lucky enough to have a teammate who is also able to recognize patterns repeatedly used in the documentation. Create/automate it once and solve it for all.
• Start measuring the time spent for a task and focus on working faster for the same task either by optimizing the way we work, finding the common things (i.e. pattern) or even using copy paste :)
• Spend less time on the normal working hours for other things we usually do (e.g. reading mails, newspaper, etc).

The project is still on its way, let's see whether we could finish the project on time or not :)
and whether the smart way will prevail over working over hours.

Before I finish, some books that I read also mentioned that software projects tend to not meet it's schedule, which I hope I could disagree with. These two books I would like to recommend : Secrets of Success Software and Mythical Man Month.