No, no reason for guilt.

Well, it was dream-guilt. Not so logical. I went to bed all paranoid about it, which is not too logical, either.

FWIW, I've been able to deal with the occasional incense burning in my yoga classes by liberal doses of PH-neutral saline nasal spray.

Theo, I'm going to pass this along to my friend with the kleenex up her nose. She'll be glad to have an alternative.

A fair amount of "it's too haaaard. You suuuck" from purported professionals.

Yeah. "This sux." Thanks. We'll get on that right away.

You're so almost out of there. Do they know yet?

Nope. Before I tell them, I'm planning on maximizing my health benefits this month, as well as using the Apple Employee Purchase Plan.

There are many beauties to the nasal saline spray scheme, such as a) damn near impossible to overdose, b) cheap, c) nothing at all like getting regular water up your nose, which is the wrong PH and wrong salinity.

Before I tell them, I'm planning on maximizing my health benefits this month,

Finally getting that third eye added to your forehead?

Seriously, though, it's a good time to get new glasses if you need them. Plus a monocle for the third eye.

as well as using the Apple Employee Purchase Plan.

I loves me some Shrift and her devious ways.

Though considering the shit she's been through at this job, it's hardly devious, come to think of it.

Can you just get that at a pharmacy, Theo?

Question for project-managey and related folks: What goes in a statement of work?

At my last gig, as an integrator, it was what we supplied to the customer saying what we were going to do. List of deliverables in medium-level details. It's what we'd be graded on at the end.

In the PM material I'm going through right now, the SOW seems to be a document detailing what's required, not what (or how) it will be provided. At least two of our divisions here seem to use it that way, although the document they're talking about seems to be a business requirements document to me.

SOW here covers both what is required from vendor, and what will be provided. Dates and responsibilities and all that crap.

For my project management class, we used the PMBOK -- is that what you're looking at? The professor was pretty clear that stuff doesn't necessarily work like they say in real life.

Yup, I've seen and used it both ways.

Dates and responsibilities and all that crap.

In one document? Here (by which I mean my team/division) the people doing the grunt work are handed a requirements document and they generate a design document which will be crosschecked against it. Once that's done, they may or may not do an even more techie document for their own consumption and reference.

But the document written only by the people who need the service is what will be used by the quality assurance people to validate that the service was provided properly.

Slightly relatedly, my training material gave me the words "A tool is a tangible item, such as a software program," all in that order and stuff. Thanks guys. Way to inspire confidence in your mastery of the written word.

eta:

For my project management class, we used the PMBOK -- is that what you're looking at?

This is PMBOK-related. The first class I took was PMBOK and UCLA extension but taught by our guys. So the language matched up. The previous gig knew not of the PMBOK. I'm startled to realise that there are people here using that language, as well as people here who've never encountered it before.

Erf - I've already said more than I ever care to about how our documents work around here. Configuration Management, in the strictest sense, is all a big convoluted blur to me.