3 x 5 notecards are good because you can lay them out on the floor. Or you can use sheets of paper. During my many years as a technical writer I spent a lot of time looking at a floor-ful of papers. It's easy to slide them around, too.

Use color if possible. Get a bunch of highlighters.

A big whiteboard is good as well.

These ideas boil down to using real space to simulate conceptual space. The conceptual space occupied by a manual or any sort of documentation is a lot bigger than a screen or a page. Visualize the whole thing first, including overview, basic concepts, approach, etc., then the sections, then the subsections, finally the details.

--C. Crowley

Look, you don't have a lot of time, and you don't have a lot of experience documenting software (you're a programmer, right?), so you need to use writing tools, rather than instinct, to maximize the result of your effort.

The best tool you can use is an outline.

Make sure you start with a document purpose (the more detailed the better), then organize your information in goals and tasks.

For example

Purpose: Use CMS to manage information throughout its lifespan.

Audience: Developers that are forced to write documentation

I. Overview
An overview of the system

A. Why should you use CMS
i. You won't have to write as much
ii. Those damn writers will leave you alone ....
v.

B. CMS process [result of a work flow model]
i. [intros to major sections II - XXX] ....
xi.

II. Creating a set of documents

III. Creating a single document

IV. Finding a document

V. Deleting a document

VI. Versioning a document

etc.

There are a lot of other tools you can use (3x5 cards, doc plans, work flow models, etc.). Just make sure before you write one word you outline your document. Otherwise it won't work well, and you, or the person that takes your job when you've failed, will have to re-do it.

Besides helping you scope out the work, once you have an outline it's easy to fill in the blanks with paragraphs because you know how to do each of the sections in the outline. For example, I'm sure you know exactly how to delete a document from your CMS system. So, when you get to that item in the outline, you don't have to think, you just write.

First, there are lots of resources out there to help you decide what you might want. Blogs, online articles, books, documentation you like to use. Second, if you can afford it, hire a professional (disclaimer I work for such a company www.ipov.net). It doesn't have to be nearly as expensive as you might think, and someone who specializes in to can often get much better turn around time and quality.

Designing from the top down is generally a disaster. But for an existing system, it is the best way to document it.

Few people document, even fewer do it well. One of the great crimes people commit against their fellow developers is to not give the bird's-eye view. If you want details, you can always go consult the source code. Getting the bird's eye view of the system, the unifying vision, the overall-architecture, that is much harder to extract from the raw code.

Draw the system out on a sheet of paper at a high level, the interacting concepts and major architectural features, the fundamental metaphors. These things need not literally exist in the code. That's your first diagram in the manual. The first chapter is a couple of paragraph overview of each blob, and a description of how they conceptually relate in the system.

Next, figure out some good order to drill down into the blobs, expanding them out as necessary and trying to minimize the pre-requisite knowlege necessary for each blob. As you drill down, you'll find you forgot high-level abstractions in the first chapter, and you may even find yourself eliminating some you thought were high level. (Few things refines your own understanding of a system like documenting it!) Document with a progressively-higher-detail "spiral" until you reach a reasonable level, such that there's no poing documenting any more since it would be faster to consult the code.

You are allowed to assume some domain knowlege, and the willingness to actually read the docs. (Without either of those two you're hosed; you can't teach the entire domain in a manual and you're not writing for people who won't read the docs, you're writing for those who will.)

Advantages:

• Gives view of the program no amount of source reading can
• Less reading leaves the user more capable of doing things in the system then a raw API table, shorn of context
• You start off from day one with a usable, albiet incomplete document, whereas an API document will most likely be useless without understanding the rest of the system. (In theory, your system has isolated concerns and it is not necessary to understand the whole to understand part. In reality...) You can stop at any time and still have a valuable document.
• The system itself will guide you towards what needs to be documented; you'll see what I mean as you get into this.
• You may discover a new and wonderful design for the system, which even if you never get a chance to implement it may educate you enough to make this whole thing worthwhile.

I actually tend to enjoy writing docs, for the reasons above.

API references are necessary, eventually, but in a way, they are the least important thing you can pass on, not the most. As the old saying goes, "Give me your code, and I will not understand your data structures. Give me your data, and I won't need the code, it will be obvious." Similarly, "Give me your API, I won't understand the concepts. Give me your design, and I almost won't need the API; it will be obvious."

use a documentation generator, like javadoc, or doxygen, etc.. and commment your interfaces and code a lot. It has the advantage of always being relatively up to date, something your documentation doesn't seem to be.

The first thing you want to discover is how the users are going to read the manual. A few options:

If they have an isolated problem to solve they don't want to read the entire thing, or even 1/10th of it to solve the problem - they want a microscope view that includes a very short broad overview then focuses on the salient details so they know enough to complete the task (ie, printing a customer record, or adding a plug-in module) but don't need to know about the intimate details of related modules. This is task oriented documentation.

If they need to understand what the system is trying to accomplish and how individuals in the company use the resource then they need a complete, high-level fly over with examples of why bill in accounting is accessing the same data jerry in manufacturing uses, and how the data gets there, etc. This is process oriented documentation.

If they need to know how the program accomplishes its objectives (laid out in both the task and process docs) then you need a low level, complete program documentation that shows an overview of the data movement and processing through each module/function/database and then a low level view of each module/function/table and how they interact with each other so a future programmer knows that foo won't work properly with a table that has a key length of larger than 128 bit int. This is code oriented documentation, and may include fancy flow charts, uml, etc.

Many self taught (and some traditionally taught) programmers are unaware of the benefits to themselves and their companies of having complete, up to date documentation, nevermind the actual types of documentation and how to go about designing and creating for different uses and audiences. There is a vast library of books on this subject. Two of which come to the top of the google search and appear to be similar to my points above are:
How To Write Usable User Documentation : Second Edition by Edmond H. Weiss (Author)
and
Writing Software Documentation: A Task-Oriented Approach (Part of the Allyn & Bacon Series in Technical Communication) by Thomas T. Barker (Author)

Make sure that you and especially your managers understand that this is not a one time project - if they truly want this done adequately (not even good, but adequate) then it may require as much time to write as the program was to create, if not longer, and that as additions are made to the code the documentation must also be kept in sync, which should double code writing time. Of course, code writing time will similarily be cut in half because you won't have to read the entire commentless program in order to understand how to insert new feature x, so it should be a wash with a much easier maintenance track.

-Adam

If the documentation is something such that the other users would be able to help you write (and edit) the documentation further, then use a wiki. I suggest looking the most well-known wiki [c2.com], and at PHPWiki [sourceforge.net].

Basically, a wiki will allow them to easily edit and update the documentation without needing to know HTML code, nor needing to have upload/write access to the documentation directory.

If you're the only one who's allowed to edit or make notes on it, then I'd say the best thing to do is start from the top down, and just keep writing as long as you can. The easiest definition of "the top" is usually the starting pount of the app, essentially doing a depth first search. The problem is, if you go too deep, you'll never get the other areas. So, I'd suggest going no more than 2 screens/areas (or 1, if it's really lengthy) deep before moving back up to the top to go on to the next section.

Once you've gotten all of the major/immediate stuff written, go through again and do the next 2 or 3 deeper pages/areas. Keep repeating this cycle until you have everything written.

A short book I wrote on the subject is available from USENIX/SAGE [sage.org].

The wiki style of doing things is beneficial even if you're the only one editing it. You can maintain links, and work ahead, then go back and fix something later.

And, as an extra bonus, in case you never finish it, unfinished things look right at home in a wiki!

A great way to write program documentation is the usage of DocBook XML, which is explained in detail in the LDP Author Guide [tldp.org] (by The Linux Documentation Project), besides many other tips and tricks to write documentations.