Best Practices For Process Documentation? 370
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?"
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
Build a collection of SOP books (Score:3, Informative)
Those cover everything from installing and configuring a server, to user management, backup and recovery procedures, Policy implementations,
The idea is that all procedures have to be validated in order to be allowed to use them, and if you have to deviate, you have to write a deviation report, and possibly ammend the procedure.
The plus side is that everything on your system is documented, and can be trained by others.
The downside is that it is a lot of work to make procedures for all normal operations.
But if there is a major problem and you have to replace a server and bring up the network at midnight, it is comforting to know that it has been done before, and that whatever you have to do is documented.
check the documentation (Score:2, Informative)
Comment removed (Score:4, Informative)
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!)
Don't forget Plone (Score:3, Informative)
This takes a culture shift that must be implemented with a mandate from upper management. You can start by placing all of your processes/SOPs in the intranet to lead by example.
Re:Tough project (Score:4, Informative)
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".
Re:Tough project (Score:4, Informative)
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.
Re:Tough project (Score:2, Informative)
Here, fixed that for you.
Sad as it is, this seems the way it actually works. For years workers in Germany have refrained from wage raises (which in real is a decrease in income, taking inflation into account) in order to "strengthen and support the land's economy". At the same time managament wages were raised by several hundert percent.
Wiki. CMS. Wiki. CMS. (Score:4, Informative)
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
To start with... (Score:3, Informative)
Additionally, management looks at SharePoint and LiveLink as a form of RCS, but people will typically not using the versioning side - i.e. go to a document, select add version, upload new version - when uploading new versions of a document - they'll just upload a new document, perhaps with a different name that you may or may not recognize as being a new version of some document X. This only adds to the problem of disorganization I mentioned above.
That said...it's a really touch job to figure out and do. If you need an RCS like system, then I'd suggest looking at using Subversion via webDAV mapped as drives to people systems or something similar - but you'll still have a problem with people not doing versioning right.
I've also been in the proverbial "someone was hit by a bus" situation (the person left for a vacation and died; not sure what happened, but it wasn't a bus) and had to pick up the pieces. Fortunately it was just software and the code was fully available (after a time), but even so it took us a full cycle to fully understand what was going on and create our own documentation about it (e.g. adding more comments to the code, writing stuff down for consideration for the next version, etc.) so it wasted a lot of money, but we couldn't avoid it.
Unfortunately for you, you're at a non-profit which means funds to do anything like this are even tighter, and any hit in finances will likely kill your project first unless management is really 200% sold that it will save them money in the long run, in which case they'll prioritize whose functions you have to document so that they can eliminate those positions - which will only lead to less help from any of the employees. (Even more unfortunate for you it's highly likely you'll hit this kind of scenario in the near future given the economy and 2007's 6.3% inflation rate.)
So take a breather, think things through and I'd highly recommend starting with upper management with the documentation process, and then working your way down - start with at the top, add the key employees, and end with the employees that have high turnover. (They'll likely have good info already and will feel the most vulnerable, so leave them till last.)
Good luck - you'll need it.
Re:Sharepoint weakness (Score:4, Informative)
The message is brought to you by someone who has been struggling (badly) with a Sharepoint based knowledge base for the last 8 months.