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?"
It's really hard to get people to write this kind of stuff. A wiki will work well for some people - developers and IT types particularly - but I've had mixed joy with non-technical types. I don't think it's the technology that's the problem, it's lack of desire to undertake the task and, in some cases, a wish to feel 'indispensable', which this process is trying to reduce. Some people find that very unnerving.
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
The "Hit by a bus" thing I often see when people are either sick or on a holiday and nobody is able to tell what is going on, which leads to frustrations by people depending on certain input.
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.
Don't fight for your country, if your country does not fight for you.
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!)
However realistic your observations might be in light of modern corporate "greed culture" (which is different how, from 19th-century "greed culture"?), your pessimistic attitude and lack of treatment of a core criterion betrays the fact that you've never worked for a non-profit.
I own an IT consultancy that has worked for somewhere between 40 and 60 NPOs in the last several years, among other clients. Call it our "social mission". In contrast to the fundamental jadedness of your diatribe*, people working (not volunteering: working) for NPOs are typically 1) invested in the mission, 2) invested in the mission, and 3) invested in the mission. There's not too much ego going on, there...at least not below the Executive Director level. These people are, by and large, dedicated to the organization and, I suspect, would be more than willing to participate in a documentation initiative. Of the few NPOs we've kept on as clients -- WE have to make a profit, even if they don't -- most don't seem to experience resistance to process documentation. And it's especially crucial in the case of an NPO, where they can't necessarily afford to send more than one person to project management training, or pay for more than one "basic bookkeeping" course at the local community college. We've traditionally worked mostly with domestic violence/sexual abuse organizations, and the brave souls who work at them burn out like crazy. You wouldn't believe the turnover. Whatever knowledge or competencies the organization acquires over time must survive the coming and going of staff, and luckily, the staff generally knows this.
I guess it comes down to this, really:
1) process documentation is a necessity of business continuity (I'd be remiss as a consultant if it weren't included in my operational continuity plans for clients);
2) don't put the original poster off what it a worthy and crucial cause (especially since s/he works in IT at an NPO -- there will be enough challenges coming up, thank you very much);
3) start your own damned business, if you don't like how you've been treated by your employers.
* Dude: I've been laid-off, too, by the Big National ISP That Ate the Little Hometown ISP Where I Worked(tm), so I know what it's like to write "thanatopsis documentation".
I'm a guy named Bob.
Oddly enough, I'm also a consultant who frequently does process mapping, though my rates aren't all that reasonable any more.
There's no great trick to process mapping, and rarely any resistance or fear from employees if it's done properly. The key is to approach it hierarchically, make sure you get plenty of overlap in your descriptions of activities or procedures, and keep the document live so changes can be documented and errors corrected.
I generally try to start with functional groups which contain locations, locations which contain equipment, then equipment which requires activities. The main point, which may not be obvious first, is that context is king. There tends to be a lot of self-similarity about business activities, and without the context, important details will almost certainly get lost.
"I've got more toys than Teruhisa Kitahara."
The world and his wife has already said it, but wiki's are an absolute godsend. My previous company took me and my partner on due to having a terrible IT outsourcer who charged them a fortune and provided shit service (whooda thunk it, eh?) and one of the first things we added was a wiki. When you're rebuilding an architecture from the ground up, you don't have the time or inclination to write huge tomes of docs, but you do have time to scribble notes in a wiki whilst package XYZ is installing or you're waiting for seven gigs of data to copy over a shoffy broadband link.
We eventually settled on Zope/Plone, and it made future IT maintenance an absolute breeze. Universal search of the object database meant finding a particular scribble was a piece of piss. Fine grained permissions mean we can safely add all of our backend IT stuff (architecture docs, ISP details, support contacts, machine names, the works) so that no-one else can see it. Web based means it's available throughout the company and usable over minimum bandwidth, inclduing GPRS on my blackberry. The ability to add a "comments" box to the end of every type of page object was an utterly superb idea, as was the inbuilt version control for file attachments.
Compare and contrast to my current company (who bought out the one with Plone); documentation is an absolute fucking nightmare. We're forced to type it in a very particular format in Word in such an arcane template that one wrong move re-numbering the mis-numbered bullet points can make whole sections just vanish (I've exponded more expletives over word than any other program in history - fine for quick letters, anything more complicated and it always seems to crumble to pieces); screenshots in word look absofuckinglutely terrible, and some docs are little more than a catalogue of screenshots from installing and configuring each stage of the app (useless IMHO because they're practically impossible to edit - no-one goes through it when reconfiguring, removing the obsolete screenshots and putting in new ones), unless you happen to live in one of our sub-domains, whose normal.dot is such that screenshots that take up the whole width of one of my domains' pages do no appear to exist on their computer (that's right, a completely 60 page blank document weighing in at over 15MB, as far as they can tell).
On top of the dogged insistence that Word be the holy grail of all document formats, each project team has their own documentation area and since there's alot of "architects hand this to ops who hand this to apps testing who hand this to helpdesk who hand this back to ops who then forward changes back to architects who then hand it down to..." going on, there's a veritable starburst of word documents all over the SAN, all pertaining to different sections of the app with about 80% overlap, much of it mutually contradictory, and since all depts use different (and manual, hence arbitrary) version numbering schemes you essentially just have to talk to practically everyone who's worked on that project to figure out WTF is going on. Since the documentation is in such a state, no-one bothers updating it, to the extent that when it's time to reinstall $app on a different server, you find the name of the database has changed and have the task of tracking down the one DBA who knows which box to look at. The few projects that do have "universal" documentation (typically because they're either small or under the helm of someone who laid down strict rules of where the docs should go to begin with) do so at the expense of permissions - they're typically available to normal users if you know the right path to put in to your run: dialogue.
Have pleaded and pleaded for a saner document management system, Plone was thrown out for the time being for being UNIX (!), at the moment they're trying to integrate the current docs in sharepoint. The words "fuster" and "cluck" spring to mind, although not necessarily spoonerised.
With a wiki and a remarkably small amount of self-discipline you can avoid the doc
Moderation Total: -1 Troll, +3 Goat
The main weakness with using Sharepoint as a knowledge repository is that the MOSS search functionality is extremely limited. The search used is the MS developed search, not the search that is used on their OS's or on MSN. When creating a knowledge repository or Knowledge base always ensure that you use a platform that allows you to integrate a search engine.
The message is brought to you by someone who has been struggling (badly) with a Sharepoint based knowledge base for the last 8 months.
Just you're average nitpicker.