Best Practices For Process Documentation?

jollyreaper writes "I have a nice new IT job with a non-profit. They are a growing organization and management has realized that they need to bring their way of doing business up to a professional level. Several years back, their IT department was still operated like it was in a home office — fine when you're dealing with three people, not so good when there's over a hundred users. IT got its act together and is now running professionally and efficiently. The rest of the organization is a bit more chaotic and management wants to change that. One of the worst problems is a lack of process documentation. All knowledge is passed down via an oral tradition. Someone gets hit by a bus and that knowledge is lost forevermore. Now I know what I've seen in the past. There's the big-binder-of-crap-no-one-reads method, usually used in conjunction with nobody-updates-this-crap-so-it's-useless-anyway approach. I've been hearing good things about company wikis, and mixed reviews about Sharepoint and its intranet capabilities. And yes, I know that this is all a waste of time if there's no follow-through from management. But assuming that the required support is there, how do you guys do process documentation?"

Comments

My experiences

[Anonymous Coward]

It's really hard to get people to write this kind of stuff. A wiki will work well for some people - developers and IT types particularly - but I've had mixed joy with non-technical types. I don't think it's the technology that's the problem, it's lack of desire to undertake the task and, in some cases, a wish to feel 'indispensable', which this process is trying to reduce. Some people find that very unnerving.

Where there is no motivation for the group to start documenting, I personally try and lead by example. If I have a process or a system that would benefit, I write a small and clear document (I try and keep it to one side of A4, three at most) and store it on the network. Generally, it never gets looked at, but when somebody needs to know how to do something, it is there and they appreciate it. I also document other people's processes as and when I need to know what they do.

After a while, and with some encouragement, people start to add their own documents and the whole thing starts to grow.

It's difficult though. The worst thing is when you see a company that have invested a lot of time and money writing process documentation that is clearly useless. The danger here is having the false sense of security.

It's also important to remember that the single biggest potential drain on a company is staff turnover, and this will always be the case, even if you have the best process documentation in the world. People are not cogs.

That's my (limited) experience. Might also be worth noting that I'm not a manager, I'm a developer, so I am working with and influencing my peers rather than my minions.

P.S. I hate Sharepoint and would not recommend it at all

FIRST: Capturing the Oral Tradition

[Tsu Dho Nimh]

OHHHH!!! ME!!! I KNOW THIS ONE!!!! Been there, done that, have the shurnken heads and tribal tattos to prove it! Also passed ISO9000 on the first try, with only minor criticism of the process docs I wrote.

These things become like folk medicine or a mystery cult, with multiple strands of "tradition" passed from Master to Student, with people adding their own ideas into them. You will need to reconcile the varying practices among the practicioners, which can lead to bruised egos and outright rebellion. After you have the real process identified and accepted, then you can decide how to deal with it.

1. Hire a temporary Technical Writer who had done this sort of thing before if you can. They can act like the outside anthropologist.
2. Let everyone know that they are going to clean up the documentation mess so that they can handle new hires, vacation replacements and temps without having to handhold them and spend days getting them up to speed (the real value of well-written process docs is as a training aid).
3. Department by department, identify the shamans: the person everyone goes to for training and problem solving.
   You can expect resistance from some shamans: their knowledge may be a source of power and job security to them. One carrot to dangle is the prospect of time freed to do different things instead of being stuck answering questions and training. A stick is the threat of being fired if it is discovered that thye are not handing over all they know - after all, they could be hit by a bus and you would be no worse off than if they are fired and take their tribal knowledge with them.
4. Have each of the shamans (or the tech writer, or a secretary) write down the process as they understand it - as they are doing whatever that department does, take notes. In a multi-shaman department, you will have several process documents.
5. If staff are following unofficial crib sheets and hand-written notes to themselves, collect these and make copies of them.
6. Someone - preferable the technical writer - takes the transcriptions and other documents and reconciles them. Wherever they are in agreement is a non-issue, provided that it works and doesn't violate regulations.
7. Anywhere two traditions differ must be reconciled. This may mean consulting the operating manual for a piece of equipment (maybe one tradition is using it wrong) and meeting with the shamans to decide which variant makes more sense, is faster, easier or what.
8. Write the final document and test it. Have someone follow the new process EXACTLY AS WRITTEN and see what happens. The definition of success is that they can follow the document and complete the process with a satisfactory product ... a completed form, a properly filed case, etc.
9. PUBLISH ... wherever it makes sense.

TIPS:

• Follow the process from incoming "raw materials" through to the exit of "finished product"
• While you are cleaning up the process, check the forms and related documents ... they might be simplified, or they might be the cause of part of your problems.
• The usual heirarchy is: Policies, Processes, Procedures. Write the docs as modules so you can change a procedure (say if you go from paper to computer filing) without rewriting the a 300-page mother-of-all documents. Policies point to processes, processes point to procedures.
  Refer to operating instructions, do not incorporate operating instructions (I saw one process where EVERYTHING was in the process instrucitons, including how to change the toner on a cdretain brand of photocopier!)