Showing posts with label the doomed project. Show all posts
Showing posts with label the doomed project. Show all posts

Wednesday, October 22, 2014

We told them so

We signed off on the doomed project and sent it off to another agency almost two years ago, after I had cut back on posting here but before I had stopped entirely. It got passed back and forth for a while with other agencies and finally published about two months ago or so. Maybe I should stop calling it doomed. But its problems didn't end when it left the building. I'll try to go over a few of the problems it had while I wasn't posting here.

Things went normally with it for about eight months. Normal was still pretty bad, but there's nothing we can do about it while another agency is reviewing it, so normal was good enough. Then one day, a team member's bosses' boss asked for something. This guy was responsible for both XYZ and Operational L__ even though no one else wanted them and they made the project take months longer. Now he was asking to have them taken out of the project. Collectively they were over a quarter of the 400-page document spread out in a dozen chunks. In the meeting where he asked to have them removed, we pointed out as delicately as possible how big a job this would be, how much it would delay the already-late project, and how he could have prevented it a year before simply by not including them. His idea of an apology was a shrug and an "Oops."

Taking notes at that meeting, I slowly got the impression of a situation that would be amazingly miserable for someone, probably not for me, but I couldn't be sure. It was like sidling up to the Grand Canyon on a windy day, and then seeing that it was filled to five feet below the edge with black plastic trash bags. My eyes were bugged out during the meeting, but when I found H. right afterwards and briefed her, I couldn't keep from laughing. I was hysterical, choking out the explanation of the problem. What else could I do?

And then, a few months later, after that was dealt with, the lawyer offhandedly asked me where to find the final draft of a letter. Another requirement for the review that generally should be relatively easy, and done at the same time as everything else. But it wasn't. We just forgot. And the removal of XYZ and Operational L__ made it harder, because we had to go through multiple files in the archive to see what should be listed in this letter. And we had to do all that on a tight deadline, because the rule actually was sort of kind of close to ready.

Thursday, December 13, 2012

It never rains but it pours

For most of the past couple months, things have been relatively slow and easy. My projects haven't demanded much from me other than attending meetings. I have filled in for other writers or peer-reviewed their documents, but either way it's not as stressful and doesn't require as much careful attention as projects of my own do. I took a week-long vacation for Thanksgiving, and then on the first day back, had a medical emergency that kept me out of work for most of the following week. And right now it's the middle of the holiday season. There are holiday parties interrupting work and every project is slowing down because key people are on vacation or are about to be.

Except for those projects that are speeding up, in hopes of squeezing something out before the vacations. Like one of mine. A new project I was assigned to is trying to get things moving, and there's a kickoff meeting this afternoon.

And several projects of another writer's. Not only is he unusually busy at the moment, but he's going to be out for a while due to a medical problem of his own. My boss asked me yesterday if I could fill in for him on one of them. I said I wasn't sure, because of that kickoff project, but I was given the assignment anyway and told that things could be shuffled again afterwards if necessary. So I'm working on that now, and it needs quite a bit of work. It's not a huge rule, but it has a short deadline. I got started on that today, and it's been keeping me busy. Needs a fair amount of work, and it's a type of document for which guidance is lacking.

And then this morning, H. called to tell me about a meeting for the doomed project. It's been outside the building under the review of another agency for a couple months now, but someone just noticed overlap between the doomed project and another one. (I feel a bit guilty about this, because I had helped with the other project briefly, so maybe I could have called the problem to someone's attention earlier.) The two project teams are butting heads a bit about which one should change to accommodate the other. There was a meeting about it. It conflicted with the kickoff meeting for my other project. So I spent a lot of time today trying to figure out which meeting I should go to, and then preparing other writers for the other one.

So after a month of having nothing worth mentioning to do, I get a new project, do a lot of work on someone else's project, and have something go wrong on my most important project, all in one morning. How exciting.

Thursday, August 23, 2012

Rats from a sinking ship

The economist who was on the doomed project from the start has left. I think he's gone to grad school. He got out just in time. The doomed project just got back from the latest review, this time by the department head, and his comments seemed to indicate he wanted to use a different approach on the economic section, meaning throw out and start over from scratch. Obviously, that would be bad. We were hoping to persuade the department head that the economic section only needed tweaks rather than a complete overhaul, and I think we've succeeded. But I'm not sure, and I seem to remember one of the economist's last statements was that starting over would take four months.

I feel sorry for the new guy.

Tuesday, July 10, 2012

Being positive sucks

I meant my previous post sincerely: getting to work was rough, but that e-mail seemed to say that the reviewer had made minor changes and they could be safely rejected if they weren't easy to handle, which would be purely good news. I was feeling good about the doomed project and today in general for a few minutes because of that.

But I began working on his changes, and most of them were as stupid and pointless as ever. There are two recurring issues that I want to ask the lawyer about, because I know what policy we've agreed on between me and her, but program offices just keep on doing it differently over and over and over again. And yet again, this guy was working in a seperate file rather than the main document, which means I had to work my version control magic, and calling it magic sounds totally fair considering how hard it is for these idiots to figure out working in a common document.

And then, one hour later, the lawyer sent an e-mail saying that she'd need input from other people to properly address the edits in that e-mail. She left for the day right after that. So for a while I thought I'd either have to make the judgement call myself to either delay things by a day or reject the recalcitrant office's edits, neither of which is in my job description.

It worked out OK in the end - I found an approach acceptable to everyone who mattered, and we got the project moving - but despite how optimistic I felt during those 15 minutes when I opened that e-mail and wrote the previous post, it turned out to be the only remotely fun time that morning.

Monday, July 9, 2012

Mondays

It was raining this morning, so I didn't bike.

After I'd left my apartment, my girlfriend called me back and asked me to sign something I'd forgotten about. Glad she remembered that; it might have been a real pain.

I tried to go to the ATM on my way to work this morning. My bank has two in my neighborhood, but neither of them worked for me. (I'm pretty sure the problem is the ATMs and not my card or account, but I can't help worrying a tiny bit.)

I might have missed the shuttle from the metro to work just because I wasn't paying attention. It wasn't where I expected it to be, so I just stood there waiting, but after a few minutes I noticed it was just a little ways down the street, like 20 yards. Unfortunately, that one was full, so I had to take the next one. And this isn't even new, they've been stopping down the street for a couple weeks now I think, I just didn't look around much this morning.

When I got to work I realized I'd forgotten my belt and wristwatch. The belt was because of a change in routine; normally I leave it at work, along with outfits for the week, but I'd worn my work clothes home Friday and forgot to bring the belt back this morning. The watch was just absent-mindedness.

So it was a rough morning, and especially rough to start the week with. But when I checked my e-mail, I found a message from a recalitrant office that said they had made minor edits to the doomed project but "I saw or made NO policy changes...  If ANY of my editorialial polishing tempts ANYONE to call for a schedule shift to the right DISREGARD them!!!", and that made it all worthwhile.

Thursday, June 21, 2012

Obstruction

I'm starting to think they're actually trying to delay the doomed project.

The latest review of the doomed project by TMBBs was asinine even by the usual half-assed standard of this place. It's fairly normal that a document might get reviewed more than once by the same level of management even if it shouldn't be needed, but this time two TMBB out of four had a lot to say, not just "oh yeah, one more thing," but "I need this and this and this and this or I'll make you start over from scratch."

That's bad enough. One of them, thank heavens for small favors, at least made his late unnecessary edits in a convenient format and limited himself to that. The other didn't. This TMBB used a format that's inconvenient for me for about a quarter of his edits. It's a really minor difference, but it's still annoying because (a) it's unnecessary, and (b) one such edit is minor, but a hundred add up to a fair amount of work.

Even that, though, would be par for the course on this project, but finally we get to the real problem: a lot of his edits were so pointless that I honestly think he's trying to keep us from publishing this.

In the economic analysis, where we said that this rule offers the option of many industry consensus standards, he said, "Sounds good but is probably a stretch." I wasn't even sure what part he was objecting to, but all I could think of was the use of the word "many." The thing is, when I read his comment I counted documents in the folder of consensus standards, and found 80 there. Some of them have probably been removed from the rule, and I'm sure many aren't relevant to this discussion, but even so, even if only a quarter of the consensus standards are relevant here, that's still 20 documents, almost every one as dry and vague as this. Does this TMBB think it's unfair to describe 20 different options as "many documents"? If he checked everyone one and found that even fewer than 20 were relevant, how many would he call "many?" Hah, trick questions, he doesn't know or care how many there actually are, he just had a feeling that the statement looked like it promised something good, and we can't have that.

Elsewhere, we said that the rule will ensure the existence of a certain fail-safe, and he said, "No, it doesn't. The primary def'n of 'ensure' is 'to secure or guarantee'. While our requirements are intended to provide a reasonable degree of system reliability via component redundancy, they cannot and will not 'ensure [the fail-safe]...'"

Here's the reply I actually wrote: "I'm OK with using 'ensure.' It appears in the [Congressional mandate] and about as dozen times throughout this document, and I think it's commonly used by other teams. I guess we could change this phrase to something like 'This is intended to ensure,' but I don't think we need to, and if we choose to, we should do so throughout the document, except where it directly quotes the [mandate]. Thoughts?"

Now, by the standards of blogging or conversation, that's perfectly civil, sure. But I think in an office, in writing, where the target can see it, especially from someone way down the totem pole to a TMBB, that's as undiplomatic as I have ever got, almost as rude as I can imagine without using synonyms for "penis." I just couldn't take it, and I'm not too worried about repercussions, because objecting to "ensure" really is that pointless.

Either this guy is trying to help us publish the rule and he thinks that parsing the meanings of "many" and "ensure" are really, really important to it, or he's trying to stop us from publishing the rule by any means possible, and at this point the latter seems more likely.

Wednesday, May 30, 2012

Asymptotic progress

This meeting went deceptively well. Of the four TMBB we needed to hear from, one didn't show up and didn't even send anyone in his place. That still left us with three TMBB, plus several support personnel like myself, and we made relatively good progress on the remaining issues. There were more than a dozen proposed edits to discuss, and all but three were approved without a problem, and it was equally easy for the people present to agree that those three were bad and should be rejected. One of the TMBB said he'd have someone get back to us the following week with yet more content about XYZ, but other than that, we thought we were nearly done.

The meeting was even encouraging in a way because I got to hear TMBB acknowledging the same kind of problems I write about here. "We have an internal schism," one said. "We agreed to this text four months ago, and now we've got [middle management] marking it up," another vented. The stuff I'm writing about is not fabricated, and if anything it's downplayed here because I'm too far down to notice some problems. My superiors' superiors are aware of the dysfunction. They just can't do anything about it.

But those three rejected edits were made by the office of the TMBB who didn't show up. And the following day we found that he wouldn't approve of the rule unless those edits were made. Of course! If it seems too good to be true, it's probably not true.

Well, we had another meeting today (almost two weeks, you'll note, after the meeting at which we thought we were nearly done) called by the guy who didn't bother to show up for the first one. We covered the basics. I had a little work to do after the meeting, and I'm still waiting for input on something, but I think we're nearly done.

Wednesday, May 16, 2012

A little thing like success won't stop us

Clearance officially started on the doomed project on Wednesday, May 9. That's good news: we're on the next stage. It's a bit bizarre because clearance is normally when TMBB get involved, but here they've been involved for months, but, whatever, a milestone's a milestone. Normally it would take two weeks or more, but due to the constant scheduling problems, only one week was allotted, so they're supposed to be done by close of business today.

May 10, the WMBD boss scheduled a meeting for May 18 to address issues raised in clearance. This confused both H. and I just because it seemed premature. What if clearance was easy and no changes were needed? Or, forgive that fanciful reverie - more realistically, what if clearance went late and TMBB weren't ready by the time of the meeting? Also, H. was scheduled to be out of the office that day, so she wasn't sure if she'd need someone to fill in for her, and if so, that would be a pain.

By noon Tuesday another problem had become apparent. TMBB have done nothing in the document. One team member has made a few edits - and he made them in an annoying, pointless way that makes more work for me, but whatever, it's easily fixed, it's just stupid - but as far as we can see in the document, TMBB have not even looked at it. Yesterday H. forwarded me an e-mail with a hint about why. At least one TMBB actually said he's going to address his comments at the meeting. So in addition to the problems with scheduling the meeting that were predicted by H. and I, there's one that we didn't see coming: it's an excuse for TMBB to miss the deadline. Thanks, WMBD, that was helpful.

Tuesday, May 1, 2012

Situation Normal...

A peer review should only be started after the team is completely and totally satisfied with the rule, a last-minute check before a document goes to TMBB. Despite the fact that a peer reviewer is well into his review of the doomed project, there is still work progressing on two other fronts. First of all, the lawyer and economist have been making a number of edits to the RA, things that were supposed to be caught before, but weren't, but they still have to be done. And second, SMEs want to change how we handle XYZ again.

The first issue is arguably understandable, considering that the lawyer's and economist's time was compressed like ours, but it's still inconvenient, unfair to us, and not how things are supposed to work.  The second issue is ridiculous. It is really, really not how things are supposed to work. In addition to the same problem of ongoing policy changes during a peer review, there's also the fact that as I've said XYZ is just a side issue, and the fact that their specific approach to it right now seems dumb to me.

I e-mailed my supervisors on Thursday to let them know the basics. I added that this shouldn't affect any of us in the tech writers' office "if it is resolved quickly," but I still needed to figure out exactly how to handle it. I was careful to include that caveat, because personally and off the record I think it's unlikely. Their replies by e-mail were simple and diplomatic - thanks for keeping us in the loop, we'll discuss this in the morning, and by the way there's good news on a related issue.

But by IM, the senior tech writer was much concise and direct. His only message to me was three letters: "wtf"

Wednesday, April 25, 2012

Deus ex machina

Google's policy change may have done what a week's worth of willpower couldn't: got me to stop blogging at work.

We use Internet Explorer at my office. Blogger stopped working properly for me today, and I haven't looked it up but I think that's because Google changed how Blogger works on IE. I might be able to post something from work, but it would be harder and uglier than it used to be, so I'm writing at home at the moment.

Still, I was busy today. My fourth project, long-inactive, became active, so I had to respond a bit to that. And I spent a lot more time this morning being industrious for the doomed project. After I did a fairly detailed edit of the new economic section, I set up the whole doomed project for a peer review. Luckily, I got all that done before afternoon ennui set in.

I also spent a while running in circles (well, "running in circles" in a desultory, all-by-e-mail sense of the phrase) about whether and how we would have to edit a related document - I had forgotten about it for the past month, and early this morning I thought a peer reviewer could do it, then I thought I'd have to, and the last word was that we didn't need to at all. Probably. Well, that's good news.

I've given the economist the benefit of the doubt more than SMEs, because in some ways he's been in the same predicament as me and because he hasn't been the cause of my problems. But after focusing as much as I can on his section, I'm feeling less friendly. His stuff was in a pretty rough shape, and while it's all my job, a lot of the edits were really basic stuff. More to the point, that whole "running in circles" bit was his fault. By now, the only people I can rely on are H., the lawyer, and my fellow tech writers. Us against the world.

Tuesday, April 10, 2012

We exasperate ourselves

A recent story from H. has made me feel better about her job. I'm still worried about her mental health, because she's still in charge of the doomed project and it's still a mess, but the WMBD boss just saw an e-mail trail of a fuck-up that quite clearly wasn't her fault, so I'm pretty sure he knows she's not the main problem.

A round of review on the doomed project ended last week. We got even less helpful feedback than usual. We asked about eight people to approve the rule as is, or give us specific edits to be made in certain places by a definite date. By that date, we had heard from only two people, and one of them just gave us a long, rambling e-mail about the department's stance towards many issues, but even the team's lawyer couldn't tell if it had specific edits for our rule. That's all we got on time.

After the deadline, H. sent out an e-mail to all the people who hadn't answered. She complained to me about a certain reply. One guy was baffled. He said he thought he wasn't supposed to be doing something now, just waiting for other people to finish their part. He cited an e-mail from the WMBD boss on a certain date as his source for that. H. asked for details nervously, in case the WMBD boss had indeed gone behind her back and said that this guy didn't need to worry about it. But no, the baffled guy's source was simply the e-mail asking everyone for input itself. I've reread it, and I don't see a thing there that looks like saying anyone should hold off on anything. It seems he just didn't read it well.

What else could H. have done to avoid that problem? Should she really not use words of more than three syllables?

Tuesday, April 3, 2012

A bad day

Ugh. Today was rough.

I got into work and found two things to work on that had come in yesterday while I was out, because it was my RDO. They weren't actually late or high-pressure, but it's still not fun to get in first thing in the morning and still have stuff piled up because most other people were in the office yesterday and I wasn't. And even if they weren't huge problems, they both happened to be annoying in their own ways.

First there was the latest draft of the blackmail project's document. The RDM asked me to merge it with the main document, a version control issue. (That's never fun by itself.) Because he asked me to merge them, I assumed there had been changes made in the main document while the reviewer had been working, so there would be edits that had to be preserved in both of them. So I opened both documents side by side and went through them page by page and copy-pasted the reviewer's changes into the main document. However, I should have started by checking whether I needed to in the first place, because the only changes were the reviewer's. I could have just archived or deleted the old version and saved the new one with its name. So that was frustrating.

The other thing waiting for me was the economic analysis on the doomed project. The economist is a much better writer than some SMEs, but it's still daunting and depressing how much work I'll have to do with it. I had thought I was done with basic formatting and this kind of word choice work, but oops, no, here's another 50 pages of it.

And H. had an idea to help the doomed project along: for me to make a spreadsheet summarizing the remaining issues and assigning them to specific people who can actually do something about it. My attitude is that nothing can help the project (hence "doomed"), so regardless of outcome I'm leery of this just because it's unexpected work for me. But I can't ignore the assignment, and we should do something to look like we're trying to keep things moving, and I admit that this might actually help. So I started designing the spreadsheet.

In the process, I kept the "redesigning the axle" problem fully in mind and I was very careful about what we wanted and how to do it. I've run it by H. and the lawyer more than once. I wanted to do something I didn't know how to do, so I wound up using the help guide and asking two people before I found an approach I liked. I made most of the spreadsheet write-protected so there would be no ambiguity about exactly what we wanted. In previous spreadsheets we had multiple columns that were blank in most columns, which made them harder to read, so I'm putting everything relevant into one column and laboriously typing in explanations of what's going on. This spreadsheet covers all the bases. It is foolproof, or as close as anything can be in Microsoft Office. This spreadsheet is a fucking magnum opus.

And I guess I may ultimately take pride in my work today if it winds up making a difference, but that's unlikely, and it's still a lot of back-and-forth and dealing with knotty problems at the moment, and now that I've finished designing the spreadsheet I can look forward to filling it in. Again, not fun.

Friday, March 30, 2012

Fractal problems

There was a meeting yesterday. For whatever reason, the department head wanted to recognize every project team that has published something this quarter as part of a rulemaking project. Seeing a parade of present, active projects, one thing about them jumped out at me: there was quite a bit of overlap with the doomed project.

There were at least two projects with basic goals that overlapped heavily with the doomed project. And these are not trivial issues that the doomed project covers in a paragraph or two. Operational L__, the huge thing added from scratch relatively late, has a rulemaking project devoted to it. So does the general issue of closing the loophole. As for how big that is, it's the thing discussed here, the issue that contributes one phrase to every single section. I have the sense that there were even more overlapping projects than that, but I wasn't taking good notes.

I've mentioned that a "kitchen sink" approach for the doomed project has been one of the big problems with it from the very start. What surprised me yesterday was learning just how unnecessary a lot of it is. When SMEs claimed that certain things like XYZ really need to be done in the doomed project, I took them at face value. Apparently operational L__ and the loophole really don't need to be here, though. Which is funny, because the closing the loophole sounds like a no-brainer even to a non-expert like me, but if there's a whole other project to address it, we shouldn't have to do that here. I'm sure that the responsible department would argue that it needs to be in the doomed project because the doomed project is scheduled to be finished before the loophole project, and that might have been true if the loophole were the only other extra in the doomed project, but considering how fast it's going now...

Friday, March 23, 2012

Work-to-rule is tempting

Two days ago the WMBD boss declared that, as H. put it, it was "Time to stop the music." He asked that any more requests for revisions "or anything to this effect" to the doomed project be referred to him, instead of addressed by me or the lawyer directly.

This fits what I've been calling him. He hopes this will prevent unimportant changes from further delaying the project. He's even said he's "just trying to protect" me. I really doubt it will help overall, though. He has little authority over the substance of the rule himself, so he won't be telling anyone, "Sorry, there's no more time for that change, it'll have to wait until after publication." I'm pretty sure I'll eventually have to put in the document whatever SMEs ask me to put in, whether or not they run it by WMBD and their own boss first. Anything kept out of the document at this stage is going to be put into it at the next one. At best, if another "hamster wheel" situation arises, he might deal with it more directly, but he's not in a position to notice that before they've gone around twice anyway.

So the advantage is the possibility of preventing one type of problem. The disadvantage is the certainty that every edit now has at least one additional layer of review. Call me a pessimist, but I already have an opinion about how this will work out.

Fortunately, we're being intelligent about it so far and interpreting the instruction loosely. It first came up at all this morning. A SME e-mailed me a request for a correction. One number had been mistyped, literally only one character, and I checked that he really was just reverting it to the previous correct version. According to instructions, I should have forwarded that to WMBD or just told the SME to contact WMBD and not done anything else with it myself, but that seemed a bit too ridiculous even for me. Instead, I made the change, e-mailed WMBD to check on it, left the change tracked pending his reply, and accepted the change when I heard from him an hour later. The lawyer has said she expects more minor wording changes soon and suggested e-mailing WMBD once for all of them.

We'll be fine as long as we don't have to take him seriously.

Wednesday, March 21, 2012

The squeaky hamster wheel gets the grease

A couple months ago the senior tech writer asked me why the doomed project was going around in circles. About another project that question might make me defensive, but about this one I could unabashedly say I didn't know, the Program offices just keep doing more things. I then told him, unofficially and sotto voce, that I had two guesses: either the people who need more time don't dare stand up and take responsibility for the delay in front of everyone at a meeting, they instead do things late and screw up everyone else's schedule; or different offices aren't communicating with each other, so they each want different things and don't find out about the conflict until the project is at a stage where everyone is involved. Either way, problems that could have been simple become bigger and more time-consuming because they were mishandled.

Obviously, the previous post is an example of the second problem. I'll bet it's also part of the first too, though. I can't remember if the TMBB from the Training office said a word in the March 9 meeting. I guess he must have, because I can't think of where else the specific "one paragraph" comment would have come from. But if he had any opinions about that or anything else, I don't remember them. Maybe the problem is him not communicating with other offices, or maybe it's his own subordinates not communicating with him, I can't tell. And it's much harder to think about something that's not there but should be than it is to think about something that's there but shouldn't be, so it seems like no one else is noticing this. H. and I know that the lead SME and the Training SME mishandle things because we're get e-mails from them that make things worse, but the Training TMBB just sits back and lets things happen.

If the squeaky wheel gets the grease, that guy should have squeaked at that meeting.

Tuesday, March 20, 2012

What I call "doomed", the lawyer calls "the hamster project"

A constant problem with the doomed project is the dysfunctional relationships between the office in this agency that cares about the deadline and everyone else*. The latest big problem is similar to that: a dysfunctional relationship between two offices that want different things.

One requirement was relatively consistent from the start of the project: XYZ operators** had to take a training course from TI, an independent training organization. Around February 16, the Training office changed that to summarize the training course, but not explicitly mention TI. Both versions of that part happened to be about 10 pages total, including the discussion and stuff. That was one of the last changes before the latest review of the document by TMBB. That review ended February 29***, and in it, the Human Element in Design office changed the training requirements back and required TI again. On March 9 we met with TMBB to resolve that and other unclear issues. In that meeting the Training office asked to change one paragraph of the TI requirement and like almost everyone else they said they'd have it ready by the following Monday, just one business day.

In fact, we got it the Monday after that - two days ago, seven business days longer than they said. They reverted all 10 pages. And we still don't know what the Human Element in Design office thinks of this because the important people have been out so far this week.

After February 29 I had no real opinion on this. Hey, I'm not the expert, it's all the same to me as long as I get the time I need to do my work. But at that point there had only been the original version, the new version, and back to the original. By now there has been the original version, the new version, back to the original, back to the new, and potentially more, all taking longer than we were told it would. This is really, really stupid.

* For example, see here.

** "XY operators"? "XYOs"? Whatever.

*** Well, that was the deadline, but some responses came in late, of course.

Friday, March 16, 2012

I can't tell if I'm incompetent or everyone else is

Fairly often when SMEs give me text to put in a rulemaking document, I have half a dozen comments or questions per page about relatively basic issues: "I've changed this from passive voice to active voice." "This is unclear, do you mean that people are not allowed to use that equipment, or that they are not required to use it?" "These two paragraphs are almost completely redundant, so why not just combine them?" And, of course, "Stop using 'shall' when you mean 'must', you illiterate jackass! You're supposed to be writing a regulation for modern laymen in the general public, not a period piece set in Georgian England!"

Ahem. I don't actually say that last, of course. But I think it. And I do raise the issues or make the changes on my own. When the SMEs reply, the answer is usually (paraphrased) "Don't blame me, I just copied that from an international standard/a previously existing regulation/another current rulemaking."

Then I sit and feel nihilistic about inconsistency for about a minute before making my changes anyway.

Why? Well, wometimes the SMEs are wrong about where it's from to begin with - they copied and pasted more than they intended or less or from chapter 89 instead of 98. It's easy to pin the blame for mistakes like that. It's a harder to handle problems like using a vague advisory guideline as an iron-clad requirement or just plain bad writing, though.

For example, yesterday I got curious and actually read a document that the doomed project uses as a resource, and even considering how standards change over time, I was struck by how much I wanted to edit the document. Big chunks of it are outdated, because it was written 20 years ago about a technological issue, and vague even considering the age. The document in general is a non-binding guideline, and we want to make its guidance mandatory, and sometimes that's harder than just changing "should" or "shall" to "must". And it's mostly in the passive voice. I guess that might make sense for the writers of an advisory document, who don't care who is doing certain things as long as they're getting done, but our agency shouldn't be as unconcerned about it. Same for times SMEs have used our own previous regulations as a template - sometimes it should be smoother, and sometimes if I'm reading it correctly it just plain doesn't work as written.

It seems to me like most of the documents we use as resources either would be OK in some contexts but definitely not for us here and now, or make me wonder how the authors ever got away with it in the first place. Did style guides and plain language standards really change THAT much over the past few decades, or am I being too picky, or what?

Tuesday, March 13, 2012

Plenty of time to do it wrong

I remember a maxim from a poster in a school I saw once as a kid: "If you don't have time to do it right, when will you have time to do it over?" That principle doesn't seem to apply here.

Just before my vacation there was a flare-up in the minor project because one guy wanted to reconsider this yet again. As I mentally rehashed the rejected alternatives, I had second thoughts about one of them. I had said way back then that I'd like to handle the table a fourth way if only we had time, but it seemed like it was just days from being done. Doing the table the fourth way would take at least a couple days and probably more than a week - there might have been resistance to it, I just had a general idea of the fourth way and would still have to figure out details, and we definitely would have had to redo the discussion of the rule's changes. Considering that we thought the table was one of the last sticking points, I rejected the fourth way because we shouldn't hold everything up just to get this one thing just right.

Well, that was October. If I or my project team had been more realistic about how long things would actually take, we could have definitely got that table just right by now.

And even though this great example of a certain problem - can't do something quite right now because we think we're almost done, so we settle for a "close enough" approach, but then the project keeps going for months - has come from the minor project, something like this has happened probably literally dozens of times in the doomed project. Either that exact situation happens, or the reverse, where we just have to do something big just right even though we're supposed to be almost done. It's on my mind because several times this week I've seen the deletion of discussion or reg text in multiple pages at a time, and thought "I wish I hadn't worked so hard on that." Why did we make sure every i was dotted and every t was crossed and everyone on the team approved of that stuff if someone was going to throw it out with a shovel?

Wednesday, March 7, 2012

Dilbert is a documentary

I've been meaning to change the names I've given people here simply because I think it would improve my writing, but in one case I should do it because calling someone "the well-meaning-but-dumb boss" is becoming less and less accurate. Because he's getting more and more like Dilbert's pointy-haired boss with every day.

There was a meeting three weeks ago at which we set the current schedule for the doomed project. Among other things, we decided we need team members' bosses' bosses to review the document again soon, and the vague, noncommittal feedback we have often received is unhelpful. We wanted every proposed change to be in the form of text ready to use, not just comments saying "this should be stronger" or "a new definition of this would be helpful". Part of the reason for that is deadline pressure; the doomed project has never been leisurely, but sticking to schedule seems even more important right now than it used to. Now, WMBD was in the room and agreed with everyone else about all that. Those ideas might not have been his originally, but I'm completely sure he didn't disagree.

The review happened. J. the substitute tech writer started organizing feedback while I was away and I finished this morning. I would have finished earlier, but one copy didn't get to me until today. (We're still missing one more, in fact, but we had to stop waiting sometime.)

The WMBD boss included eight comments of his own, and not a single one of them was text ready to use. One of them, for example, tentatively suggests creating a table to go into detail about something instead of briefly summarizing it in the text, while another comment simply asks "Isn't this a big loophole?" about a certain requirement. He also had a bunch of updates directly in the text and it looks to me like every one of them is nonsubstantive. Nothing that changes what the document does or even how it does it, just how it looks. Now, I admit that that kind of thing wasn't specifically discussed in the meeting, but given the deadline, it seems obvious to me that any changes should be limited to what's absolutely necessary to keep things simpler.

This is, let's recall, H.'s boss. This is the person in the building who cares the most about the timeline. He agreed that the review should be kept simple and concrete feedback would be helpful, both of which would help the deadline. But apparently he either doesn't know what that meant or thought it doesn't apply to him. Christ, what an asshole.

Tuesday, March 6, 2012

Ever thought about what "SNAFU" means? I mean, really thought about it?

Back at work. Rested, relaxed, invigorated. On top of things. Taking charge and making progress. Tackling nitpicky problems with a fresh eye.

Hah.

While I was away the blackmail project moved more quickly than I expected and another writer had to review it a bit. Yesterday I spent more than half my time on the blackmail project and the minor project. The doomed project needed more work and is the higher priority, but I could catch up on those two relatively quickly before moving on to the big job, so I did - signed off on the peer review on the blackmail project, and went to a minor project meeting and made certain changes as requested.

Still working hard on the doomed project. Sure enough, it was a busy, important time for the project while I was away. As I predicted, though, the higher-ups reviewing the document didn't finish by Wednesday as planned, so that made things a bit easier for J., the backup tech writer. In fact, they still haven't finished. Of seven reviews, we have only six, one of those came in today and was still in a rougher state than we expected. So I've done all I can and am working on cleaning up side issues while we wait.

But what can you do about it when a higher-up doesn't do their job? I can't think of anything, other than making sure your own ass is covered and working around it as best you can.

(In fairness, no doubt the people in question wouldn't see these problems as not doing their jobs. No doubt they'd say some problems were unavoidable technical issues no one should be blamed for, and some weren't their jobs, they were just favors or not even issues they were aware of. But now I'm violating my resolutions against either extending too much goodwill or being too long-winded or both. So, hell with it, the latest problems with the doomed project are all the fault of the people whose reviews were late and/or incomplete and they should feel bad for it.)