Here is the 4th, and for the moment last, part of the Employee Performance Evaluation chapter. Since posting the last two sections, all of this chapter has been significantly updated, so I’m refreshing all four sections. I also am posting a pdf of the complete chapter. The format is a bit rough, but readable. Here are pointers:
Archive for March, 2007
I just posted the third part of the Employee Performance Evaluation section (actually, it will probably turn into a chapter, since the total, including an un-posted section, is about 12 pages long when rendered into pdf). There will be a fourth part, which should finish up this topic.
As always, comments are welcome, either on this page or at the bottom of the section.
I’ve just posted the first two parts of a section on Employee Performance Evaluation. This is less than half of the full section, but I think the two main sub-sections are readable as is. Because this is pretty long, I’ve posted it in two parts:
I expect to post at least two more parts within the next week to finish this section (or maybe Chapter, it’s getting long).
I just posted a new section titled Living with Technology. It’s somewhat different from previous sections. It’s a set of guidelines that I’ll fit in somewhere in the larger technology section. It’s not as complete as some of the other sections I’ve posted, but I think it’s worth a look.
Since this is just a start, I’ll be glad to add other guidelines; just drop them in a comment.
Here’s a link: Living with Technology
I’ve been working on a section about gathering requirements when you’re acquiring technology, and it occurred to me that this might be another place where a Wiki could be useful.
The basic idea would be to use the Wiki as a place to gather and prioritize “raw” requirements and carry on a discussion about them.
I see several benefits:
- You keep everyone up-to-date on what you’re doing, so there’s no excuse for anyone to complain about requirements being developed in secret.
- You’re less likely to miss an important requirement.
- You get a broad-based view of priorities.
- You start the buy-in/change management process early.
I see two potential downsides:
- It may be harder to get negative comments unless you provide an alternate, private mechanism for people to give input.
- You run the danger of channeling people into a “Group Think” situation, where alternate opinions get buried or never spoken. That might argue for starting the Wiki only after you’ve gathered an initial set of requirements through interviews or other more traditional processes, and for providing a private mechanism for comments as described above.
Has anyone tried using a Wiki for writing requirements? Comments on your experience or thoughts in this area are welcome.