You had to design and document the entire project up front and then break it out into individual tasks and estimate them. Two points that I thought were particularly horrible:
Your estimates immediately became hard deadlines. If you guessed 3 months ago that gnarfling the garthok would take you 8 hours and you were wrong, it went against you on your metrics. Even better, if you finished the job in less time than you estimated, they'd complain and tell you that you missed low and needed to do a more precise job of estimation next time.
I suggested to my boss once that if they insisted on having all this documentation written (seriously, we were supposed to write up docs on what the function names were going to be, what the arguments were, and what they'd do -- before we were allowed to write any code) then we should probably build some time into the schedule to make sure we could update them based on what we'd learned during the actual process of writing the code. He told me "I understand what you're saying, but that's not possible. We need all of the documentation done up front so that if we're behind schedule, we can add more people to the project and they can read that documentation to get up to speed quickly."
I looked at him for a few seconds, stunned speechless, then basically said "In my experience, that never works." A few weeks later, I was laid off, I suspect because I wasn't toeing the line and buying into the "new" Lean waterfall process. Best thing that ever happened to me, in the end.