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?"

5 of 370 comments (clear)

  1. Re:Tough project by ccguy · · Score: 4, Interesting

    Improving the process = making it more efficient = making it require less manpower = layoffs. Again, no incentive to cooperate, and every incentive to sabotage.
    See? That's exactly why an expert is needed to sell this to the staff. You need them to see the equation Improving the process = making it more efficient = people is more productive = we can produce more = we can make more money = we can give better bonuses.

    You aren't going to get people on board by having a techie snooping around.
  2. Re:wikis by dazlari · · Score: 4, Interesting
    I work in the IT department of a largish retail company and we have over the last 6 months undertaken a wiki implementation; at first as an internal trial and then to roll out to the great unwashed. We're using Dokuwiki (php based) which is quite easy to install an manage and has a great active on-line community which certainly helps at the outset. Take time to understand the wiki software world fairly well; use the The WikiMatrix to help you discover and choose.
    Some tips:
    • Start with only one area of the business and get it done well. News will spread and everyone will want to be on board.
    • Only deal with one individual from each part of the business. This centralises control and keeps some focus. If it's small and that means you then all the better.
    • Certainly do not keep information on the wiki that is likely to go out of date any time soon. Wiki's are best at creating lots of relatively static documents that can be easily corrected and added to. You don't want to be changing minute critical details on the same pages constantly, such as keeping contacts, products, or business transactions. That is crazy! That's what business databases are for and they're far superior for many obvious reasons.
    • Look to similar on-line wikis for structural concepts. Wikipedia, Wikibooks are good starting points. Link to the "empty" documents you want to create later as part of the early structural creation process.
    • Avoid utilising extraordinarily special wiki features too often as they often become cumbersome to maintain and will scare away many novice users at which the page may be aimed.
    • Be sure and test the wiki features out with several browsers!
    • Add the documents that are immediately usable first; don't just add them for the sake of completion. This will save you time and increase the return on time invested.
  3. Re:Tough project by cammoblammo · · Score: 4, Interesting

    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.

  4. Re:Tough project by CrazedWalrus · · Score: 4, Interesting
    Absolutely agreed.

    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?

    • Extreme pain when someone goes on vacation
    • Every time a particular issue comes up, that person has to drop what they're doing and go work on it, even if it isn't really their job description anymore.
    • Very little confidence that we're doing the right thing when that person is away.
    • Ludicrous amounts of time spent investigating something that a person could have told us easily.


    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.

  5. Using stickies by BenEnglishAtHome · · Score: 4, Interesting

    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.