If the project was well planned and managed, the documentation should have been nearly complete before a single line of code was written. Please don't misinterpret me as advocating any specific development methodology, in particular TDD. However, every proposed feature of a program should be well described prior to work actually beginning.
Of course there will be changes, which means you'll need to update the project specification as you go. However, if done faithfully, the only mundane task is to take that specification and polish it into documentation that is ready to ship.
This avoids the daunting task of writing it from scratch after the project has been completed, and helps you to quickly identify scope and feature creep. Additionally, it helps you to better visualize the impact of changes in a way that can quickly be communicated to the client.
Finally, your testers aren't just testing the program itself, they are also testing how well it adheres to the given specification.
If done correctly, documentation is a painless process.
That being said, sometimes you will have to document something from scratch. In those cases, I highly suggest writing naturally, as you normally would and hiring a professional editor which is cheaper than you might think. Learn from the editing process.
I agree with finding ways to practice and refine your writing skills, but for different reasons. Effective writing skills make you a more effective communicator in our world of e-mail and instant messages. You'll also be refining how you communicate verbally as you begin constructing shorter, more concise sentences naturally.
Being able to write better documentation faster, imho, is an ancillary bonus. Your job is to write programs and communicate.