One of the things I really encourage my staff to do while they work here is to create complete procedures manuals for their jobs. We're talking about full documentation with step by step instructions on how to accomplish their tasks, complete with screenshots where applicable. And while many new staff members may find this a little strange, they quickly realize the worth when they can pick up a manual from their predecessor and start to work through their new job. So far I don't think I've had anyone who has dismissed the value of these documents.
The concept also plays into other areas in our systems which probably won't come as a surprise to anyone:
- If someone is sick, a co-worker can pick up for them while they recover,
- When training, it takes less time to re-familiarize yourself with the material to show the person,
- Often time you can let the person work through stuff on their own without impacting your time, and
- In slow periods there are always manuals that need to be updated, so there is less pressure on your time trying to find someone meaningful work to do.
I'm also sure you could come up with a few more points, but I figure those are enough to keep the motto of "Document It" alive in my workspace.
There are, however, some dangerous drawbacks that can come in to play here, and these typically surface when someone leaves the organization. That list includes, but certainly isn't limited to the following:
- Procedures that have changed, and the manuals not updated to reflect those changes,
- Multiple copies of procedures being left in the manual,
- Not being able to find the appropriate manuals, and
- People "going through the motions" in their job without ever really understanding what they're doing.
The last one is, of course, the supervisor's job to identify and resolve, so I'm not going to focus on that at all right now. I'm more interested in the first points.
We recently had someone leave us. She'll be missed, of course, but my team has really bonded and pulled together to make things happen. Fortunately in many cases we were able to simply pull the book off the shelf and run, but there were a couple that gave us pauseâ€¦
We naturally rooted through binders and other files and ended up coming up with multiple procedures in some cases, or not all in others. Then the question surfaces on which is the correct procedure, or if any of them are. In our case it wasn't always obvious, so we had to spend time working through them to tell. Naturally this kind of defeats the purpose.
In the cases where the procedure is out of date, (either because it subtly grew over time, or radically changed and new documentation wasn't yet prepared,) it needed revisingâ€¦ but where was the original document to make those changes? Was it stored in a common folder, private folder, semi-privateâ€¦ who knows? In some cases these procedures had been written by a former staff member and their binder was divided up between people when they leftâ€¦ so now we have procedures that may be stored anywhere on our network.
This got me thinking about how we organize and store our manuals, as well as updates. We could use one specific folder on our network, but then we get into issues with naming conventions and finding the documents within the subfolders as well. "No," I thoughtâ€¦ "the perfect solution would actually be a Wiki!"
A wiki, by its very nature is a collaboration tool that allows shared editing, complete with versioning and rollback features. This would be great for us, as we could store the entire set of procedures in one common place, share it among all our accounting staff, and let them edit the entries if they found that they were out of date. (Of course we'd encourage them to keep them up to date, but let's face itâ€¦ we're all human.)
I figured this would be an easy slam dunk, actually. We have Windows Sharepoint Services 3.0 (WSS3.0) installed on one of our servers, although we've never used it in earnest. I installed the default Wiki template that comes with WSS3.0 and gave it a runâ€¦
It SUCKS! I mean REALLY sucks!
The whole point behind this, to me, is to make it really easy to create rich entries. It looked good at first, when I went to edit a page and saw the nice editing toolbar:
So I started typing away, then went to insert a picture:
Wtf? I was seriously hoping for a Browse button, not to have to hand type in a URL. Not to be discouraged, I tried to paste the picture directly into the text, but it was a no-go either. The route you have to go for each picture you want to insert is:
- Snap the shot
- Save it as an image
- Navigate to the Sharepoint Image Library
- Upload the picture (and optionally name it)
- Copy the link to the picture
- Navigate back to your entry
- Fill in the appropriate URL info
- Hope it works when you click OK. (My test did not.)
Doesn't that seem just a little awkward? I need to put this into the hands on non-programming type folks. I think the concept of the Wiki has a LOT to offer us, but the implementation here is brutal!
When I'm blogging to WordPress from Word I can just write up the document in Word, complete with pictures, and just publish it. It auto-magically uploads, resizes and embeds them for me. Sweet and simple. Why can't this be the same? Or can it?
Despite my searching for over an hour, I have not been able to find another Wiki template that works with WSS 3.0, or a webpart that will allow for easy picture uploads. If anyone knows of one, I'd love to hear about it. I'm not above actually paying for them either, but I'd prefer to take them for a test drive first, as I've committed to my staff that we won't go this route unless it is user friendly. They don't want to become programmers, and they shouldn't need to.
Our requirements are actually pretty simple. We need:
A simple text editor capable of:
- Basic formatting such as Bold, Italics, Underline, Colors
- Controlling font size for headings
- Creating hyperlinks (without having to hand write HTML code)
- Adding pictures in-line with text (without having to do the dog and pony show I described above)
- A decent search engine
- A Simple method for linking new pages into the Table of Contents
- It to work with Windows Sharepoint Services 3.0 (WSS3.0)
Bonus points for:
- Being able to author the initial copy in Word
- Workflows for approval of new/edited entries
- RSS for updated entries
If anyone has any thoughts on this, I'd love to hear them.