Slashdot Mirror
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?"
In order to (successfully) document all the processes in your company you are going to need support not only from management but from all the staff as well. This is going to be the most difficult thing to get.
Forget about wikis and all technical solutions you can think of, for now. First, you need to explain everyone what they get by documenting everything. For most people, explaining what they do, how, etc, means to give away their value. I'm not saying it's true, it's just the way many people think, and this is why they refuse to cooperate as much as possible. Asking someone to document everything sounds like '...so we can replace you'. In particular, drop the 'hit by a bus' argument.
So, your project is probably not to be about documenting everything, but probably about improving those processes as well, making life easier for everyone (and making it clear than that's the final goal), etc.
Once processes are more or less defined (or redefined) with the participation of staff (meaning that they get to give feedback) you can implement a policy of 'all processes need to follow the documented procedure. Procedure can be changed if needed'. This will in turn help to keep your documentation updated.
Anyway you are definitely going to need help from a change management specialist, human resources, etc.
1. A document control specialist who understands what does and does not go into the vault. 2. The vault, software to manage the documents, something like Carmen http://manedge.com/index.asp. 3. The discipline instilled into all to trust and use the system. 4. Good backups.
Sharepoint is a system to control flows of documents, like a web filesystem for Office documents. It's supposed to grow in a planned way, that means you can't grow new structures. And if you want a Wiki you will have to get another one because the one in Sharepoint is not usable, it doesn't help you write good structured documents just to get a web page going fast.
Now... You aren't looking for tech solutions, but when it comes to that beware, that there is such a thing as adopting too early.
1. define your goals! democracy or not - procedures should be centrally managed but influenced by everyone?
2. define you tools/methodology/language - make it easy to understand and update by everyone!
3. run it like RFC's go: make a draft and ask for comments - centrally manage what is acceptable and what isn't
4. make it structured, indexed and easily available for people to see
5. make each procedure as short and simple as you can
6. define exceptions...
7. go step by step - don't try to do everything at once
Something like a wiki should serve you fine if you define stuff in advance...
Want to know how to sort it all out? Get some sticky notes, and a whiteboard. Write down each suggestion on a sticky note, and stick in on the whiteboard. Step back... look at it. Move some notes around. Group them. Get a dry-erase marker, and draw some boxes, circles, and arrows. Throw away the redundant notes. Repeat. Call in a co-worker. Repeat. Call in your boss. Repeat... as necessary. Now, take a picture of the whiteboard. Get a notepad, and summarize what you've found. Oh... and all those software tools and processes you were thinking about for knowledge capture? None of them work as well as a whiteboard and a pad of sticky notes. That's because none of them let you work unconstrained by artificial structure, and none of them let you step back and take in the whole of your work. By the way -- the second best tool for knowledge capture is a cocktail napkin.
The certification might not make sense, but 99% of the practices do.
So, even if you are not going for ISO9001, you should see what the requirements for it are. I was lucky enough to be involved in quality assurance during the period the company got ISO9001 certification.
Yes, I have heard horror stories how ISO9001 has been interpreted to mean "document everything randomly", which it does not. Quite the contrary, the requirements for documenting are quite lax. Not as lax as programmers would like (i.e. nothing), but not a burden if you start any kind of documentation for your projects.
I will have to second this. You need a person who is not intimately acquainted with the process to describe it objectively and with enough detail for the ultimate users of the manual - i.e. people who are not intimately acquainted with the process. Also, the end document is more likely to be cohesive and consistent if completed by one person.
Where my opinion differs is in the carrot-stick part. Explain to the "shamans" that not all they know will be in the document - you can't write the Encyclopaedia Britannica. You just need the structure of their knowledge - that cannot replace their decision-making skills, which, after all are mostly why they are "shamans".
"I'm not good. I'm not nice. I'm just right."
1. You're a new hire and not the CEO. Proceed carefully.
2. The non-profit's management may be perfectly content with what they have now.
3. Non-profits usually don't have time or money to burn.
4. Getting many non-IT people to contribute to a wiki or to use Sharepoint to document their stuff may instantly make you the most hated person in the office.
I used to work for a company that had a rather big department devoted solely to processing the IT docs we authored into an incredibly strict format. I got used to the insanity of it all. I can't tell you the number of times we needed to refer to these documents, likely never.
Then, a few years ago, I switched to a big company that descended from "oral or unorganized documentation" crowd but which had different factions who did things their own way depending on the individual in charge. At first I was pissed at the lax and fractured way I perceived them to be doing things. My career would have ended very quickly if I tried to manhandle everybody into what I thought was a "Is This Good For The Company?" type of philosophy. I learned to adapt.
Oddly enough, there is a new layer of bloat within my company (record profits + 2% raises = more bureaucracy) trying to get the IT crowd on the same page, so-to-speak, about everything. To say they're hated and despised is to put it mildly. What do they say? Those who can't teach, teach gym. Well, the IT equivalent of that go into this sort of job.
Be careful, man. Tread lightly.
you are grossly underestimating the level of stupidity coming out of American schools these days. Yes, you probably need to document steps like "Invite Participants" and "Attend your own meeting." Jebus Rice Federal and State guidelines require a maximum of 8th grade reading level in writing. A max of 8th grade... WTF!?
I am at the point I have to document for some of these kids processes like, "In the event that you cannot log in, contact the help desk immediately at xxxxxxxx. You computer not working isn't an excuse to surf the web on the other functioning computer 4 feet away all day. And no problems don't just fix themselves overnight much like your laundry magically gets done by mom..."
Kids seriously don't undesrtand that they could actually WORK on the other computer. The concept is nearly alien to them. If THEIR computer doesn't work they have no comprehension that they could possible use a different computer.
Sadly either in a doc, wiki, or presentation you'd be suprised what you have to document now. Tons of kids that can tell you the year the Civil War started, but have no clue why it happened. Plenty of kids that can deploy Exchange but have no idea how to configure it to meet the business needs. They know how to do various steps in configuration but have no concept on how to stich all that together to provide a solution. Their like robots now, complete deterministic people in a digital universe. No analog throught anymore...
-=[ Who Is John Galt? ]=-
If this post has confused you, I apologize in advance. This is a soft skill that is hard to explain in one paragraph on /. (see my sig for further explanation).
Whatever other steps you take, please be sure that your process documentation is published and announced to people in the company and even go over it in a presentation to all staff. Nothing is worse than a committee or working group creating a bunch of process documentation for processes that maybe never existed and then never telling anyone about the documented process until they violate the process. I just went through a year of hell with newly created and documented processes that sat in an obscure network share and were never told to anyone until an offense against the process was performed. Then it was roadblock after roadblock because "this is out of process". Inevitably, my response would be "do you mean a documented process? because I've never seen it documented or been told that it had been"