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

Tough project

[ccguy]

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.

Re:Tough project

[ultranova]

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.

Of course it is true. The whole reason to document, as given by the submitter, is to make people more easily replacable. Something that is easy to replace is less valuable than something that is hard to replace.

It simply isn't in anyone's best interests to cooperate with this kind of project; that's why it's doomed from the start.

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.

Improving the process = making it more efficient = making it require less manpower = layoffs. Again, no incentive to cooperate, and every incentive to sabotage.

Re:Tough project

[dltaylor]

Dead wrong.

1) almost no one knows what knowledge others in their organization lack

2) very few people really know how much they know

3) almost no one ever has the time to catalog their knowledge and write it all down (if they do, they probably aren't doing anything and don't know anything)

Pick something, for example, a set of personal wikis. Start a "test run". Every time someone is asked how to do something by someone else, they don't explain verbally, they put it in their wiki. Between the requester's follow-up questions (also through the wiki) and the answers, there will be the "oral history" captured electronically.

Management has to provide the resources, and the startup training time, as well as some sort of recognition for those who answered "in form" and for the requesters that followed through "in form".

One other thought is that "how I do X" could be captured through voice recognition. As a staff member performs a task, they could verbalize the steps to some easy-to-use voice recorder, then those recordings parsed to on-line documents. Allow the staff member first crack at editing as a courtesy (you don't know what was captured), and while they're doing it, they may also think of more input.

Don't be a grammar Nazi on the wikis (or whatever tool). Save that for the professional training manual writer(s) that end up compiling the "official" procedure manual from the raw data.

Re:Tough project

[psmears]

Someone got out of the wrong side of bed today ;-) The flip-side to these views is as follows:

Something that is easy to replace is less valuable than something that is hard to replace. Somone who is impossible to replace is impossible to promote

Improving the process = making it more efficient = making it require less manpower = layoffs. Improving the process = making it more efficient = making it require less manpower = increased capacity = PROFIT!!!

Re:Tough project

[CmdrGravy]

That is a flip side but in reality the other poster is right, as soon as you see any sort of company policy to capture knowledge and processes like this it's an immediate pre-cursor to them moving their operations somewhere cheaper and making you redundant.

I've seen this happen 4 times now and no one's gonna catch me out again ! You can still be promoted if no one knows how you do what you do because you'll still be around to handover and train your successor whereas the business is not going to have aas much success asking you to train your cheaper replacement.

Re:Tough project

[AndGodSed]

Well, the old adage goes "If you can't be replaced, you can't be promoted."

If you can get the employees to take ownership of their jobs and see this as an opportunity to:

a) Learn a new skill (especially for the non-tech savvy types)
b) Reduce their work load
c) Create an opportunity to expand their portfolio to the point they are promoted to run a department and/or administer a person that has been employed to do their old job,

they should buy into this and support the idea.

Unfortunately as with most great ideas the actual sale is more problematic than the implementation.

In fact I'd say the sale is key.

Re:Tough project

[bscott]

> It simply isn't in anyone's best interests to cooperate with this kind of project; that's why it's doomed from the start.

It's not necessarily as simple as that - could be it's just not COOL to document, duuude!

The group where I work (a small IT services company) is mostly younger guys who like a 'hectic' atmosphere, lots of fast action and explosions, or at least busy troubleshooting schedules. Getting them to sit down and record their time spent on various projects is enough of a hurdle; getting anyone to document "office processes" is more like asking for volunteers to make a handwritten backup of each bit on a hard drive.

No one's job is threatened - it's a growing company - and everyone's smart enough to realize that things really would work better if we all were on the same page more often. It's just not fun. Even when I point out it's easier than their actual work, while being just as appreciated by the boss - it's not gonna happen.

Never mind the fact that sometimes "documenting processes" is more a matter of creating them from scratch than describing what's currently done... in a nutshell, if it was easy it wouldn't be an issue worth discussing.

(I never thought of using a "wiki" before, so I'm already a step ahead just from reading the synopsis of this story!)

Re:Tough project

[Anonymous Brave Guy]

That is a flip side but in reality the other poster is right, as soon as you see any sort of company policy to capture knowledge and processes like this it's an immediate pre-cursor to them moving their operations somewhere cheaper and making you redundant.

I've seen this happen 4 times now and no one's gonna catch me out again !

Ah, yes, proof by anecdote. Of all the forms of proof, this is second only to proof by intimidation (a.k.a. proof by stating personal opinion as fact) in its effectiveness. ;-)

Seriously and honestly, I think you've just had a bad run. I've been involved with a major corporation-wide process change/documentation exercise for nearly two years now. Pretty much everyone wants the changes in question and the training to match, because we're not trying to force things on people, we're trying to come up with a sane implementation of ideas that most of the grunts (which includes me in my main job) already support. Making the changes will improve the quality of what we do and make people's lives easier, and having proper training instead of the typical corporate "on the job training" approach (a.k.a. whispers on the grapevine) will give people the confidence to use the new ideas and not screw-up, which again makes everyone's life easier. There is just no way you could interpret the kind of thing we're doing as a precursor to outsourcing. Software is a knowledge industry, and management who still believes in outsourcing and getting rid of all your people with knowledge and experience is pretty much doomed whatever they do about processes.

Re:Tough project

[CheeseTroll]

Can't be promoted, and can't really go on vacation, either.

Re:Tough project

[BVis]

Well, the old adage goes "If you can't be replaced, you can't be promoted."

And the new adage that replaces that is "If you want a promotion or a raise of any consequence, start working for someone else."

People don't get promoted anymore. They piddle along in a job that they're either too valuable in to be moved, or they're too incompetent/lazy to be given more responsibility. There's no incentive to work hard in this environment; you can't get a promotion no matter what you do.

Re:Tough project

[torkus]

Exactly. In the past I've made an effort to build a proces, document things, and get tedious/repetitive tasks off my plate. Did that make me redundant and cost me my job? No. It got bonus/promotion in the best case and at least an attaboy.

If your job consists of doing something simple and/or repetative and you're the only one tho can do it because you're the only one who knows how...you job is already in jeopardy. Someone like me will eventually come in, simplify it and hand off to a lower paid person than you.

It's the creative work...creating things/processes/documentation/ideas that get paid well. Manually pulling complex SQL queries that are pretty much the same every time will only last so long before a mid-level developer with something to proves writes a simple front-end and makes you pretty useless.

Re:Tough project

[the eric conspiracy]

To maintain their pay, employees should be expected to demonstrate improved performance, or employers will (and should) seek out employees that will.

Employers like to promote the idea that there is no job security; the ying to that yang is that there is no employee loyalty.

If I improve my productivity over time, and you continue to offer me the same compensation for that increased performance, I will take my improved skills to another employer to obtain commensurate compensation. I will certainly not allow an employer to exploit me in the manner you describe.

Too much good advice.

[evanyares]

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.

Re:Documetn the useful processes

[kenp2002]

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...