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?"
Check with ISO to see if they have a program for non-profits. This is the type of project that you can't just pull out of a hat. You need an organization that's done this before for other sites.
You aren't going to get people on board by having a techie snooping around.
You have mentioned wiki in your posting. Wiki definetly works, especially inside a controlled environment like a team/company. There has to be a strong management support and each individual within the company has to realize that it's there for their own good. But many tend to hide the knowledge to keep their jobs safe. The only way is to tie the wiki update to their performance review cycle. Based on my experience, mediawiki is good for static documentation. twiki is a nice collaboration environment, but you will need IT guys with perl knowledge to effectively maintain and explore new features.
#include std_disclaimer.h
From "Maverick! The success story behind the world's most unusual workplace" by Ricardo Semler ...
A company wiki can be very effective if people use it. Otherwise, it's just an electronic big-binder-of-crap-no-one-reads and nobody-updates-this-crap-so-it's-useless-anyway.
...." When new hires start, tell them which wiki pages to read, and tell them they are authorized to fix any inaccuracies they find. Try having online discussions in the wiki rather than in e-mail. Summarize important offline discussions in the wiki.
What's really needed is to develop a culture of documentation within the company. Ideally, whenever anyone asks a question that's been asked before, the response would be "It's in the wiki somewhere. Try searching for
When it works, it's really cool.
I agree.
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.
Cogito, ergo sig.
No, I'm merely trying to do as the marketing class always told us, and view this from the buyers point of view. It's not looking so good :(.
Perhaps. But this is only an impediment for the ambitious and confident, and even they can achieve promotions by changing jobs. Besides, we are heading towards a recession, so job security will propably count a lot more than advancement. Let's not forget that security is amongst the most basic needs.
On top of that, since this kind of move could be a precursor for layoffs or outsourcing, it is likely to spread Fear, Uncertainty and Doubt - and as we all know, people confronted by those tend to react by getting defensive and covering their back ("no one ever got fired for buying Microsoft").
Good for the owners, but frankly, why should the employee care ? He's not going to benefit from it. And don't forget that laying off people to temporarily hike up the stock price is a standard trick nowadays; of course it is a stupid move in the long run, but by then the CEO has already gotten his bonuses.
In a way I can't help but think that business gets what it deserves. After all the outsourcing, layoffs to pump up the stock price, and abuses of at-will employment by control freaks, there is no trust left between the employees and employers. That means that whatever one does, the other will interpret in the worst possible way. This, in turn, makes it impossible to change anything, because any change is taken as some kind of devious plot, and sabotaged as such. In the long term, it would be much more profitable for everyone to build up sufficient trust that everyone works together rather than against one another; but that would benefit the future CEO and employees, rather than the ones making the decisions right now, who can benefit more if they screw the future for the sake of short-term profits, so it isn't bloody likely to happen. Which, in turn, really underlines why morality beyond mere rational self-interest is neccessary to have a prosperous society...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
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.
Using sticky notes to flow processes was a big deal to on one particular project I worked some years ago. The project team was given a conference room with a giant glass wall that divided it from the elevator lobby. Most people who used "the fishbowl" hated that wall; they'd close the drapes and get annoyed anytime anyone peeked in. And people did peek in; that's why it got the nickname.
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.