Here's a thumbnail sketch on one approach. I've used this, to develop SCM processes, procedures, roles, and responsibilities for a 600 person development organization. About 1/3 of that organization consisted of contractors.
It took us a little under one year to go from 0 to revision 1 of the system (including vendor selection, piloting, etc.).
The challenges are really the following:
- Deciding who the audience is
- Deciding what the purpose of the documentation is
- Deciding what are documentable processes / procedures
- Deciding how the documentation gets used
Once these issues are established, then it's just write, test, revise, test, revise, test, and publish.
I'll give you some scenarios, but the actual implementation is specific to the organization.
1. Deciding who the audience is
This decision will frame how the document is written, what level of detail the document contains, and the general structure of the document.
From your description, it sounds like you have a lot of contractors who will be unfamiliar with your processes and procedures. In that case, you'll probably need some environment documentation and some process documentation in addition to procedural documentation.
Deciding what the purpose of the documentation is
This decision will drive the detailed structure and the language of the documentation.
For example, if the documentation is primarily for education, then keeping the information at a structural level with a few well-chosen examples works well. If the documentation is operational in scope, then a use case type of structure can work well. Finally, if the document is focused on teaching, then an underlying example, lots of repetition, in-line exercises, and documented sequential steps seem to work well.
From your brief description, it sounds there are two purposes. You need to educate incoming contractors concerning your environment and processes. You also need operational documentation.
3. Deciding what are documentable processes / procedures
"Everything" is not the answer to this step. Everything that is not industry-standard might be an answer to this step. A more reasonable answer might be whatever impacts performance metrics.
The level of impact can be assessed, and target topics can be put into MoSCoW (must have, should have, could have, want to have) order. This will make the documentation task more manageable.
4. Deciding how the documentation gets used
I see a lot answers jumping to this area. Flowcharts, wikis, web pages, SharePoint, etc. are all technical solutions to this issue.
However, the question has not really been asked. What is the normal work pattern of those people who MUST use the documentation?
If they're seated at a computer with either multiple screens or multiple windows, then online, hyperlinked documentation may be a good fit. The delivery mechanism (actual technology) is up to you.
If people leave their desks a lot to accomplish tasks, then a different format will be needed, as well as a different document structure.
The goal in answering this issue is to make sure the documentation gets used. For that to happen, the documentation has to be a natural extension to their current work habits.
Hammering out the Issues
For the truly ad hoc organization (CMM 1), an assessment followed by a series of JAD sessions works well. This may seem like a waste of time (let's get writing already), but it helps to identify the best use of effort, and it gets everyone on board with the process.
Many people view documentation as constraints, so getting everyone on board via a CMM assessment and JAD sessions is important.
Creating the documentation
Once these issues are hammered out, then the documentation can be created. Writing documentation, especially detailed operational documentation, is tough. One way to ease the pain is by adapting DSDM (dynamic systems development method) to the writing process.
Basically, you start out with an outline plus the major steps. You work on these with your subject matter expert.
Then you pick a test team (preferably mentored by a subject matter expert), and tell them to follow the procedure. Tell the team to do their jobs, and write down deviations or missing information as notes. The technology is up to you (wiki, SharePoint, LiveLink, sticky notes, etc.).
Gather the corrections, rewrite the documentation, and republish. Repeat until the level of detail satisfies your use of the document (see item 4), and your subject matter expert signs off. I've found that this usually takes between 3 and 5 revisions.
Finally, release the documentation into the wild as preliminary. Get feedback from the user population at large, and make one final edit.
Publish this as revision 1.
Coda
This process will bootstrap an organization from CMM 1 to close to CMM 2. Training (to make sure people know how to use the documentation) and budget will complete the task.
In order to be truly operationally efficient, you'll need to get to CMM 3, which means that everyone does the same task the same way. That means training, auditing, and corrective interaction when deviations are discovered.
Don't expect any of this to be easy. Don't expect any of this to be quick. In general, it takes an organization 1 year to improve 1 CMM level for 1 discipline.
You're probably shooting for 2 years optimistically, and 3 years realistically based on the thumbnail sketch of your problem.
