Slashdot Log In
Best Practices For Process Documentation?
Posted by
kdawson
on Wednesday January 30, @05:18AM
from the trusting-it-to-the-little-i dept.
from the trusting-it-to-the-little-i dept.
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?"
Related Stories
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Tough project (Score:5, Insightful)
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 (Score:5, Insightful)
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.
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 (Score:5, Interesting)
You aren't going to get people on board by having a techie snooping around.
Re:Tough project (Score:5, Insightful)
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 (Score:5, Interesting)
I started a job as a IT supervisor about 6 months ago. There was very little useful documentation, and very little in the way of process. Everything was locked up in peoples' heads. The results?
We had two very experienced people leave in the space of two weeks, and another follow shortly thereafter. Most of the people on my team are pretty new, and we had a hell of a time trying to make up for the knowledge that walked out the door.
So what did I do?
Set up MediaWiki, of course. Initially, upper management was skeptical and slightly against, but I did it in my spare time and populated a couple hundred documents into it myself. It took days of boring, tedious work, copying from disparate sources, grabbing emails with useful information and making them into a coherent document...
The end result was something that, when I showed to the same upper management, they jumped. They made it standard operating procedure to document our processes, and even expanded the site to serve other departments. Amazing, considering it's only been around 3 to 4 months at this point.
Look, I know people say that docs "decrease their value", but that statement isn't worth its weight in horse shit. The fact is that, if you are an intelligent, useful person, your value is in *improving* the process or product. If you're stuck doing the same thing over and over like a farking monkey, then you're not really worth much more than a farking monkey. Eventually your "vendor lockin" will become obsolete, and then you won't be worth a thing. A genuinely helpful, useful person can simply go on to the new thing and help make that better too.
Re:Tough project (Score:5, Insightful)
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 (Score:4, Insightful)
Re:Tough project (Score:4, Insightful)
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 (Score:5, Insightful)
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 (Score:5, Insightful)
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 (Score:4, Informative)
This can go from billing to system maintence to whatever.
The best solution, I have found, is to have at least three people able to do a certain task. ! person doing the task, one as a backup, who will still do the task once in a while as to be able to be up to date and a third as backup for the backup.
The main person is give the responsability of 'his' project. Ownership will cause involvement. This will almost always also cause a more streamlined process. As it is 'his project', he will work harder for it, compared to 'the bosses project'.
The main thing is to do it TOGETHER with the people, not in spite of them.
Re:Tough project (Score:5, Interesting)
I worked for a while in a small factory that manufactured a few different items. Every step of every job was thoroughly documented, and every workstation (i.e. point in the production line) had a poster on the wall explaining in ludicrous detail exactly how to do the job.
The stupid thing was that they were hard to follow. They had been written in consultation with employees, and at the time everyone agreed they were accurate. The problem was that most of the jobs could be picked up much, much quicker if you had someone showing you. Once you picked up a task you didn't need to look at the instructions.
On the other hand, our employer saw value in making sure all the employees could do most of the jobs in the factory. When I left there were no jobs I couldn't do that didn't require a trade qualification. I wasn't the only one.
Here's how it played: for ISO accreditation we were required to document everything we did. Apparently it guaranteed quality. The owner of the business found more value in making sure employees knew what they were doing, and getting them to do it. We could tell if somebody was deviating from the process because our products wouldn't pass the test suite.
The employer wasn't too worried about buses either. I remember one month about half the staff were away sick, on leave or pregnant. The employer put on a few temporary staff, but on the whole we were more than able to cope with just a few hours overtime a week. There was no appreciable decline in our productivity during that month, and I remember him joking that he could fire half of us and still make his money.
I'm glad he was joking. Apart from the money it was the best job I ever had.
Operational manual (Score:5, Funny)
(1) Avoid being hit by a bus.
(2) Refer to 1.
Re:Operational manual (Score:4, Funny)
My experiences (Score:5, Informative)
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
I say go the traditional route. (Score:5, Funny)
To accomplish this is quite simple:
1. Create new management positions and dept. to determine and create new compliance metrics for appropriate bus avoidance.
2. Create committee to determine and define best practices for avoiding buses.
3. Hire PR firm to create awareness of above policies and create slick training videos to introduce employees to anti-bus methodology.
4. Create HR sub-department in charge of enforcement and compliance to metrics with appropriate disciplinary board and/or retraining.
See. Simple. Problem solved.
My approach (Score:5, Funny)
1. Put on to-do list
2. Procrastinate
3. There is no 3
Don't know if this qualifies as "best practice", though...
Re:My approach (Score:5, Funny)
Hmmm (Score:5, Funny)
More documentation may not be the answer. (Score:4, Interesting)
From "Maverick! The success story behind the world's most unusual workplace" [amazon.com] by Ricardo Semler ...
Documetn the useful processes (Score:4, Funny)
Did they really need a process to document how to arrange a meeting that had steps like "book a meeting room" and "invite participants to the meeting" plus a diagram showing the meeting with participants as an input.
I just imagine a guy sitting by himself in a meeting room wondering why he was all alone, checking the process manual and saying "Rats! I forgot step 37a - invite participants! At least I remembered step 62c so now all these cookies and all this coffee are just for me!"
Too much good advice. (Score:5, Insightful)
Using stickies (Score:5, Interesting)
I had a completely different attitude. I opened the drapes all the way and proceeded to cover that wall with sticky notes. As we held more and more meetings in there, team members got used to being watched and learned to ignore it. We developed our own code for note position and color that dictated what sort of action or task was defined on the note. Since the systems we were examining were huge and complex, we wound up with hundreds of sticky notes on the wall and, crazily enough, we could all grok it in toto.
Eventually, some of our bosses started hearing some water cooler talk about those people in the fishbowl. They started dropping by our floor and lingering in the elevator lobby. They saw our animated and intense discussions (they couldn't hear us) and took in the breathtaking complexity of our sticky note art, then left convinced that we were doing a lot of work. Now, mind you we *were* actually doing a lot of work but we could just as well have been planning where to go for lunch. The folks outside the glass had no real idea. But the impression became widespread that we were all a bunch of creative geniuses running our own skunk works.
After that project wrapped (and incidentally increased revenues by a few billion, yes, *billion* dollars), I think every one of us parlayed that air of mystery we had created into better positions.
Sticky notes. I love 'em.
FIRST: Capturing the Oral Tradition (Score:5, Informative)
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.
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.
TIPS:
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!)
Re:Critical Tasks (Score:5, Funny)
For me too! I drive the bus that hits people who have kept crucial organizational knowledge to themselves.
It's a living.