Yesterday was apparently the day of Stupid Mistakes in my office. At least, it was the day of Liz Having To Deal With Stupid Mistakes.

We have these processes in place. When we generate a document, it has certain formats. An internal title page that gets signed by the project manager. Another page which collects the signatures of all the various reviewers (author, technical manager, QA, etc.). Then the official title page and body of the document. It's a standard template.

Our documentation manager decided to make some changes. Among them, he changed the template so that the pages that get signed are now separate files from the main document. Which seems like a small enough change, except that:

- The customers who are used to one format are now either going to be receiving two files instead of one, which is going to probably complicate their system; or they're going to suddenly stop seeing those first two pages, which will confuse them, causing all kinds of ruffled-feather-smoothing on our managers' parts.

- Someone's got to pay our our documentation folks to make the changes to the templates. The projects themselves won't pay for it. Reorganizing our documentation system isn't part of any contract we have.

- Some of our contracts do specify, however, that we will use our approved CMMI Level 5 practices (if you don't know what that means, your life is much simpler than mine) to produce our deliverables. Those signatures were a big part of those practices, so it's actually important that those customers see those first two pages.

- One of our multitude of processes that we have in place is a process for updating the other processes. The documentation manager skipped over it entirely. It involves getting the approval of an office governing board whose job is to consider the impact of the changes.

Impact. It's all about impact. The documentation manager has the authority to make a change to their system so that the dates on the documents now matches the date the document is delivered, rather than the date the document was sent out for managerial approval. That's an interior change, and it doesn't really affect anyone.

But the other change has quite a bit of impact on the rest of us - and it's extremely visible to the customer. It may turn out to be that the benefit of this change outweighs the costs in time and money. But the documentation manager can't make that decision by himself.

He made these changes while I was out of town. I spent about two hours going back and forth yesterday morning between the manager who found out about the changes first and sent out an e-mail asking why they were made and the documentation manager. (Who couldn't articulate to me why they were made and had to call in the tech writer who was actually the impetus behind the changes.)

Finally, the whole thing got escalated up to the head manager's office, and he told the documentation manager to 1) put things back the way they had been until the change had been approved; and 2) to from henceforth use the change process.

Then I was given two documents to review. I was already feeling ornery from the whole mess about the document template change, so I went over those documents with a very grouchy fine-tooth comb.

The document that's actually a deliverable had the wrong document number on it. Our document numbers indicate a number of things about the document: Date, project, type of document, document version number, etc. That document had the correct date, but wrong project number, wrong document type, and wrong version number. I almost sent it back to the tech writer without continuing the review. There were acronyms that weren't spelled out, either in the body or the acronym list. The numbering had been messed up. They were using JPG-format pictures for line drawings.

The other document had other problems... See, we have this internal document. Our System Development Plan. And every individual project has its own SDP that spells out its own take on the overall SDP. They track together, paragraph number by paragraph number. There are lots of places in the main SDP where it just sketches things out and then says, essentially, "This will be detailed in the project's SDP."

I was feeling ornery. I got out my copy of the SDP and went through it paragraph by paragraph. I found a lot of places where the main SDP said, "This will be detailed in the project's SDP," and the project's SDP said, "There is no project-specific information for this section; refer to the main SDP." Am I the only one who sees a problem here?

I got out the Statement Of Work (the document on which the contract is based) and found that the project's SDP was missing several requirements.

Ornery. My red pen, it bled profusely.

And I wonder how many of these glaring mistakes I've let slide in the past. I think I have to stay ornery about these things. It's not enough to blindly make sure that all the sections are there. I've got to make sure they actually match the project, and match our other documents.

Everyone hates the QA. QA is picky and pushy and insists that verbiage be precise rather than friendly and has arguments about whether the tester is allowed to skip a step in the test script if he's already tested that thing a hundred times before, and about comma useage, and about whether you have to go through the tedious change process even though you think the change you want is pretty minor.

That's me. I'm the bad guy.

I'm going to start keeping a mustache and black hat in my desk drawer.

--Liz