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?"
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) Avoid being hit by a bus.
(2) Refer to 1.
liqbase
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.
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
You could come up with new ways, of course, but why rock the boat. Just go with the tried and true way of handling these things in American corporate culture; Mandate all employees must stay away from buses.
To accomplish this is quite simple:
1. Create new management positions and dept. to determine and create new compliance metrics for appropriate bus avoidance.
2. Create committee to determine and define best practices for avoiding buses.
3. Hire PR firm to create awareness of above policies and create slick training videos to introduce employees to anti-bus methodology.
4. Create HR sub-department in charge of enforcement and compliance to metrics with appropriate disciplinary board and/or retraining.
See. Simple. Problem solved.
My approach to documentation tends to be:
1. Put on to-do list
2. Procrastinate
3. There is no 3
Don't know if this qualifies as "best practice", though...
Everything that we do on the process control network (big Pharma) is documented in Standard Operation Instructions. ...
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.
we've had similar issues. I've found that once you have the process documented it's a good idea to get someone other than the author to run through it. We do this by rotating people on and off the various tasks. This means that after a year or so the entire team knows how to do any one job, all the processes are documented and well optimised and if anyone's hit by a bus we can move on. Of course it also means we can sack anyone without cause for concern but if you're good this won' be a worry for you! See if you can get a senior manager to run the jobs of the mail room clerk or something similar for a day!
--
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
1. A document control specialist who understands what does and does not go into the vault. 2. The vault, software to manage the documents, something like Carmen http://manedge.com/index.asp. 3. The discipline instilled into all to trust and use the system. 4. Good backups.
I think you work at the same place as me, except we're not a non-profit. Well, not intentionally.
Confucius say, "Find worm in apple - bad. Find half a worm - worse."
Like you I have found the big bang, write it all down approach never works. Try this...
When something "happens" its an "incident". This is logged - drill it in that nothing gets done unless its logged in "the system". The incident in the system describes the problem or event or required change.
You use incident tracking software for this. Think bugzilla as an example if you are a development team, but it could just as easily track help desk style issues (the internet is down, my password isnt working etc).
Everything that happens to that incident is logged in the tracking software. Once a solution is found it is recorded in the tracking software and the problem is closed.
Then when ever a new incident happens new staff can then search through all previous incidents to find solutions. And certain incident solutions can be highlighted as common solutions or knowledge base articles if they were for a major change.
Also spot checks can be done by you or relevant leaders/management to confirm that the staff that solve problems are recording what they did (much more easy that checking they updated some large process file).
Over time your incident history and knowledge base will grow to be a reliable resource of your organisations IT knowledge.
(There is a couple of things that are missed in this process, such as "test in on test system" first and "only implement production changes in quiet times", put these can be written on a massive sign in the office. Then anyone who doesnt do these basic things can be fired for negligence).
Sharepoint is a system to control flows of documents, like a web filesystem for Office documents. It's supposed to grow in a planned way, that means you can't grow new structures. And if you want a Wiki you will have to get another one because the one in Sharepoint is not usable, it doesn't help you write good structured documents just to get a web page going fast.
Now... You aren't looking for tech solutions, but when it comes to that beware, that there is such a thing as adopting too early.
1. define your goals! democracy or not - procedures should be centrally managed but influenced by everyone?
2. define you tools/methodology/language - make it easy to understand and update by everyone!
3. run it like RFC's go: make a draft and ask for comments - centrally manage what is acceptable and what isn't
4. make it structured, indexed and easily available for people to see
5. make each procedure as short and simple as you can
6. define exceptions...
7. go step by step - don't try to do everything at once
Something like a wiki should serve you fine if you define stuff in advance...
From "Maverick! The success story behind the world's most unusual workplace" by Ricardo Semler ...
I've seen it where every process was documented - including those that were just common sense.
Did they really need a process to document how to arrange a meeting that had steps like "book a meeting room" and "invite participants to the meeting" plus a diagram showing the meeting with participants as an input.
I just imagine a guy sitting by himself in a meeting room wondering why he was all alone, checking the process manual and saying "Rats! I forgot step 37a - invite participants! At least I remembered step 62c so now all these cookies and all this coffee are just for me!"
----------------------------------- My Other Sig Is Hilarious -----------------------------------
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.
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.
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!)
We use Plone for our intranet and it rocks. We have instituted a policy that knowledge such as processes go in there. It's FOSS and has lots of add-ons.
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.
1. You're a new hire and not the CEO. Proceed carefully.
2. The non-profit's management may be perfectly content with what they have now.
3. Non-profits usually don't have time or money to burn.
4. Getting many non-IT people to contribute to a wiki or to use Sharepoint to document their stuff may instantly make you the most hated person in the office.
I used to work for a company that had a rather big department devoted solely to processing the IT docs we authored into an incredibly strict format. I got used to the insanity of it all. I can't tell you the number of times we needed to refer to these documents, likely never.
Then, a few years ago, I switched to a big company that descended from "oral or unorganized documentation" crowd but which had different factions who did things their own way depending on the individual in charge. At first I was pissed at the lax and fractured way I perceived them to be doing things. My career would have ended very quickly if I tried to manhandle everybody into what I thought was a "Is This Good For The Company?" type of philosophy. I learned to adapt.
Oddly enough, there is a new layer of bloat within my company (record profits + 2% raises = more bureaucracy) trying to get the IT crowd on the same page, so-to-speak, about everything. To say they're hated and despised is to put it mildly. What do they say? Those who can't teach, teach gym. Well, the IT equivalent of that go into this sort of job.
Be careful, man. Tread lightly.
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
If this post has confused you, I apologize in advance. This is a soft skill that is hard to explain in one paragraph on /. (see my sig for further explanation).
I'd highly recommend staying away from things like SharePoint and LiveLink. I've used both, and in both cases they get high disorganized and information becomes extremely hard to find. I'm on a project now that uses LiveLink and when asking a question, a lot of people will just go "it's in LiveLink" or "go look in LiveLink" - only LiveLink is so chaotic that it'll take you far longer to find it (if you even can find it) than for someone to just give you the real answer to your question. Same goes with SharePoint.
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.
Truth is like the sun. You can shut it out for a time, but it ain't goin' away. - Elvis Presley (source: imdb.com)
Whatever other steps you take, please be sure that your process documentation is published and announced to people in the company and even go over it in a presentation to all staff. Nothing is worse than a committee or working group creating a bunch of process documentation for processes that maybe never existed and then never telling anyone about the documented process until they violate the process. I just went through a year of hell with newly created and documented processes that sat in an obscure network share and were never told to anyone until an offense against the process was performed. Then it was roadblock after roadblock because "this is out of process". Inevitably, my response would be "do you mean a documented process? because I've never seen it documented or been told that it had been"
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.
I develop software in a medical device environment, so we're ISO 9001 certified, follow FDA good manufacturing practices, our own quality system, etc. The only reason it all hangs together is there are people whose job is Quality Assurance. People who audit everything, and if we don't follow what we're supposed to then we get dinged: have to go to remedial training, have to sit through even more meetings discussing why we screwed up, and have to revise the procedures yourself if they aren't right. So the path of least resistance is to document, do it the way its documented, and pass the audits. This takes massive management commitment to keep in motion. We joke it's the CJO's(chief jailable officer)problem, but they don't think it's that funny. It's part of the bottom line. So in your case, unless you have commitment, enforcement, and punishment it just ain't gonna happen. I was in a company once that went for ISO certification from scratch. It took over a year to get there, a great and dogged commitment on the part of management, and a good chunk of resources to implement. Of course, it was for a government contract. What system is the best, how to capture knowledge, etc. are all sorted out in the planning meetings after the commitment is made.