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?"
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.
You aren't going to get people on board by having a techie snooping around.
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
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).
From "Maverick! The success story behind the world's most unusual workplace" by Ricardo Semler ...
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.
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.
Yes, they did. How one books a meeting room varies from company to company. If it's written down, you don't waste time trying to find the tribal guru of meeting rooms to strengthen your meeting-fu.
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.
No, I'm merely trying to do as the marketing class always told us, and view this from the buyers point of view. It's not looking so good :(.
Perhaps. But this is only an impediment for the ambitious and confident, and even they can achieve promotions by changing jobs. Besides, we are heading towards a recession, so job security will propably count a lot more than advancement. Let's not forget that security is amongst the most basic needs.
On top of that, since this kind of move could be a precursor for layoffs or outsourcing, it is likely to spread Fear, Uncertainty and Doubt - and as we all know, people confronted by those tend to react by getting defensive and covering their back ("no one ever got fired for buying Microsoft").
Good for the owners, but frankly, why should the employee care ? He's not going to benefit from it. And don't forget that laying off people to temporarily hike up the stock price is a standard trick nowadays; of course it is a stupid move in the long run, but by then the CEO has already gotten his bonuses.
In a way I can't help but think that business gets what it deserves. After all the outsourcing, layoffs to pump up the stock price, and abuses of at-will employment by control freaks, there is no trust left between the employees and employers. That means that whatever one does, the other will interpret in the worst possible way. This, in turn, makes it impossible to change anything, because any change is taken as some kind of devious plot, and sabotaged as such. In the long term, it would be much more profitable for everyone to build up sufficient trust that everyone works together rather than against one another; but that would benefit the future CEO and employees, rather than the ones making the decisions right now, who can benefit more if they screw the future for the sake of short-term profits, so it isn't bloody likely to happen. Which, in turn, really underlines why morality beyond mere rational self-interest is neccessary to have a prosperous society...
Forget magic. Any technology distinguishable from divine power is insufficiently advanced.
Quote: "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."
I've always looked at this from a different angle. Something that is hard to replace is going to be a constraint in the future and is therefore a problem that needs to be resolved. Usually we apply that reasoning to software and hardware, but you can apply it to people. If it's going to be difficult to replace you, then I guess we cannot give you career opportunities such as a promotion because the business will suffer if we reassign you. Or, to perhaps take this to an extreme, retaining a person who is working to make themselves irreplaceable is perhaps an escalating commitment to a bad decision to have hired them.
I suppose the irreplaceable part is the manner in which somebody does it. For instance, a person who is really good about determining roles, documenting processes, and is successful in engineering things such that the business can survive without them is somebody who is truly a competent professional and the business is truly fortunate to have them. A person with these features should have a prominent career within their organization. They're not irreplaceable because the business must have them. They're just of a high enough quality that replacing them with similar quality will be difficult.
Sorry to have rambled.
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?
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.
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.
Use Ontolica for your search. Free, plugs into SharePoint.
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.
We're doing a number of things to combat it. Culturally, we can't get anybody not in IT to document anything at this point. We're going to roll out a Mediawiki fairly soon. It's intended for another process but, I hope it will be able to take on this role as well. I've been messing with them a lot documenting some of my projects and its a great tool for documentation. I also work for a non-profit that has a little turnover problem. A wiki is a great way to give the organization some form of continuity. It works well except for the problem people have been pointing out a lot in this discussion. Getting people to use it is very difficult.
I think the main hurdle to adoption is that people don't want to learn markup. Even though the markup is quite simple, it's still a resistance factor. Everyone else that has bothered to learn it has made amazing strides in centralizing their department's documentation. A wiki is sure better than a folder with a bunch of Word documents in it.
A simple training session may just give it the kick in the pants it needs.
Bullish Machine Tzar
I concur. I own my own business and happily reward our employees when they exceed the expectations that they and their managers set out each year, as I think all employers should.
At the same time, improvement is EXPECTED. I will not pay anyone the same wage to continue doing the same task at the same rate for any reason year after year. To maintain their pay, employees should be expected to demonstrate improved performance, or employers will (and should) seek out employees that will. This should be a fair level, of course, and it should be equally applied to all employees, but the notion of entitlement that some people display (oh I have this job, so I should never be expected to do more than what I did on the first day) is patently ridiculous and saddening.
Think about it - do a businesses' customers expect more for their dollar every year? Do shareholders expect growth year after year? Of course!
STASIS = DEATH
If you're a capitalist in this system, failing to constantly improve guarantees your doom. If you're a worker in this system, don't fool yourself - there is no job security - always be improving or be replaced by those who will.
Bryan "BJ" Hoffpauir
Never underestimate the power of stupid people in large groups.