It sounds like you're already got a great start with the whole documentation thing. The following isn't really advice, it's more a relating of my own experience and what's worked for me.

User Documentation
I've tended to prefer to use a version management system such as CVS rather than making hard-copies at every stage. With CVS it's very easy to see the difference between versions, to track who made which changes and when, and to maintain multiple branches of the software if necessary. Of course, CVS does have a bit of a learning curve, and non-technical people take quite some time to get used to it, even with a graphical interface.

For user documentation, I've found the best way is to get a user to write it. Seriously. There'll be things which neither yourself nor your fellow developers will think to document, simply because they're so obvious you'll never think of them. I've been at workplaces where the user documentation was always written by non-technical people for that very reason.

Documentation is like software in many ways, in that it also needs to be tested. The best people to test are those who aren't already familiar with the software, and haven't had you drop a previous copy of the user manual on their desk. I always exist my test population much too quickly. ;)

Technical Documentation
For technical documentation, find a document that you find really useful, and copy the layout. POD is fabulous for tech docs because you can have the documentation sitting next to the code it refers too -- nobody can lose the documentation or be too busy to look it up.

I try to document every function -- what it's purpose is, an y bugs or unexpected behaviour it might have, and an example of use if it's not immediately obvious. Good, clean code is often self-documenting, and that's certainly something worth aiming for.

Each file should also (at a minimum) have some header documentation stating the purpose of the file, when it was written, and who by. This means someone can quickly and easily find if they're in the right place without having to look at code.

Keeping an FAQ is also very useful. Usually the same questions keep appearing again and again. These are obviously things you want to document.

Cheers,
Paul

Just as an aside, I also subscribe to having the users write their own documentation.
This has numerous advantages:
• They gleen a more formal understanding of your solution to the problem
• Its more likely to be complete -> not missing 'coder-obvious' elements
• Its 100% technical-jargon-free!
• You dont have to do it yourself!
Of course, am sure you could generate a framework template from your code for them to fill in (:
the 'qif;

• In the same document
  Taking care to put the simple abstract part at the beginning and hiding as much as possible the too specifics details (in an APPENDIX for example)
• In several documents
  This allow you to specialize your documentation to the reader
  (Beccause a techie don't need the same informations as a commercial...)

• Write a READABLE way
  Otherwise nobody will (be able to) use it...
• Adapt your text to your reader (the content AND the form)
• Don't forget your initial goal
  your technical doc shouldn't become a technical rant about how good the solution is...In the same vein in a commercial documentation, it's totally useless to explain your over-smart technical hack, speak about technological advance ;-)
• Use spell checkers (It's VERY important for some people (usually your bosses ;-))
• Use a portable format to allow other people to work on your documentation, convert it...

• First comes the POD, to allow a man-page like overview of the functionality of the script. Anyone reading this is assumed to be technically literate, and likely to either be reverse engineering your whole system or developing it further.
• Next comes the internal comments to the code. I always have the functions seperated from the rest of the code quite visibly. Each of the functions is domment described as to what arguments it expects, what it does, and what it returns. This means anyone skimming through your code can treat functions as 'black boxes'.. This greatly speeds someone's understanding of just what your code does.
• Next comes the 'HOWTO'. This is a rough guide to the dataflow of the system. What datasources you have, and what datasinks. What programs do what, and why. Also, where you keep things like temp files, and any bits that may need cleaning in case of serious system failure... Basically, this is a guide to keeping things working without having to know just what the system is doing.. It's there to give someone time to understand the true intricacies.
  
• As time goes on, it's a good move to have a proper user guide on the go. This should be a detailed version of the 'HOWTO' dealing with all the data munging that you perform, how the seperate scripts interact, examples, and just about everything you can think of to detail the system.

1. A generic HOWTO to enable a random technical person, with skills in Perl/Apache to keep the system alive, and give them a few pointers to maintenance without going too much into specifics. This will at least give them time to lear the system without the world falling apart around theirs ears.
2. The POD documentation. This is a wonderful aid to letting people get a good view of what the system as a whole is really doing, and learn it rapidly.
3. The internal comments. This is great to allow people to use your internal APIs you develop, and re-use your code when they develop later.
4. The in depth user manual is the icing on the cake that walks people through everything... It's good to have, but, without having the above steps complete, it'll likely be lacking in vital areas, that usually get picked on when you do the above docs.

The first is that one way to document is to strive to make as little as possible worth documenting. What do I mean by that? Well suppose you write a script, and it has a bunch of dependencies. What is good is if you can make it have as few installation dependencies as possible, and make those as clear as possible. Then you don't have very much to document about how to install it!

The second is to consider ways of combining user documentation and specs. An extreme is the approach that Microsoft has been known to take, of actually writing the user documentation as a spec. Somewhat less extreme is the approach of writing down "use cases" for a spec (this is advocated by extreme programming, among other schools). When you have done that, the use cases are extremely suggestive about what to put into the user documentation.

I really like a flow diagram. I usually have two documents, one with the flow diagram and the other (that has a version as part of the filename) with version control as the first section (who did what and when and in what version and for who). The rest of the document is a descriprion of how the system works. Something brief, that a developer would understand aside from the introduction which is clear to all.