Slashdot Mirror

← Back to Stories (view on slashdot.org)

Best Practices For Process Documentation?

Posted by kdawson on 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?"

7 of 370 comments (clear)

  1. Tough project by ccguy · · Score: 5, Insightful

    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. Re:Tough project by ultranova · · Score: 4, Insightful

      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.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    2. Re:Tough project by dltaylor · · Score: 5, Insightful

      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.

    3. Re:Tough project by AndGodSed · · Score: 5, Insightful

      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.

      --

      Seven Days with Ubuntu Unity

    4. Re:Tough project by bscott · · Score: 4, Insightful

      > 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!)

      --
      Perfectly Normal Industries
    5. Re:Tough project by torkus · · Score: 5, Insightful

      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.

      --
      You can get rich if you own a politician, but you have to be rich to buy one in the first place.
  2. Too much good advice. by evanyares · · Score: 5, Insightful

    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.