A project manager walks into a bar after a long day and orders a drink. While enjoying it his cellphone rings and he answers it even though it's his wife.
   "Where are you?" she asks.    
   "At the pub," he answers.
   "Are you almost done?" 
   The PM looks at his drink and ponders for a moment.
   "Well, I'm about 40% done with my drink, but that's based on quantity. I don't know if I will continue to sip at the same rate, especially given that my coordination might diminish, and it's unlikely that will happen at a linear rate. Also, I plan on having a second, so all the uncertainty of the first will apply, as well as a bathroom break-there might be a line-the response time of the barkeep, given that more people are coming in. That's a finish-to-start relationship, given that I can't begin drinking until she finishes pouring..."
   "You're having a relationship with the bartender?"
   "What? No! I simply meant..."
   "Give me a number!"
   "I'll be done in 20 minutes."
   With that the call ended, 
   The bartender, who couldn't help but have heard the PM's side of the call, saunters over and exclaims, "That's amazing! I never considered how many factors go into calculating something that seems so easy...and you figured all that out so quickly. How did you do it?"
   The PM looks up sheepishly from his drink and said, "I used the same method my programmers do. I analyzed the variables, then picked a random number that seemed reasonable and doubled it."
It's a fact that project management depends on tracking the percentage completion of each task. I was a project manager and program manager for many years, so I understand the concept. However, I've been a developer for much longer, so I also know the dirty little secret of project management: with tasks for which progress is not objectively demonstrable, the numbers are a wet finger in the air. The developers know it, the PM knows it, but the unspoken agreement is to ignore it and march on. 
Sure, there will be PM's who email me now and tell me about their wondrous developers, who always deliver on-time. I believe you, but I also believe that it's a fallacy to then deduce that when the developer (or mechanic or landscaper or author ...) tells you that a task is 40% complete (or better, 42% complete) there is accuracy involved. The fact is the developer finishes on-time by doing the work necessary to complete on-time. If that means they work extra hours at night and spend 11 hours on a task they said would take 8, you might never know about it, but the task is complete on-time. My challenge is this: if you were to know how many hours were really spent on the task at it's conclusion, and how many hours had already been burned at the time the person told you that the task was 42% complete, you'd find the number was likely well outside a 5% margin or error.
Of course, this is only my opinion, of which I'm 87% certain.