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 30, 2012
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.
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.
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.
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?
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?
Thursday, March 15, 2012
The dumbest request of the day
A recent e-mail had three comments on the blackmail project. One was moderately interesting and helpful. Then there was this, and another one that was much simpler than this but roughly equally important.
If I hadn't thought of the "find" tool in Microsoft Word, checking that could easily have taken an hour in a document like this. Fortunately, I did think of it. I found four places in the 50-page document with three spaces in a row. Two of them were intentional in legal jargon; that's just how that specific jargon is normally formatted. One more was at the end of a paragraph, so it doesn't affect things at all. I found one sentence which actually had three spaces between it and shouldn't have.
Yup, that was a good use of my time, all right.
recommend the tech writer double check spacing between sentences. Seems there may be places where there are 3 spaces vice 2. But hard to tell.
If I hadn't thought of the "find" tool in Microsoft Word, checking that could easily have taken an hour in a document like this. Fortunately, I did think of it. I found four places in the 50-page document with three spaces in a row. Two of them were intentional in legal jargon; that's just how that specific jargon is normally formatted. One more was at the end of a paragraph, so it doesn't affect things at all. I found one sentence which actually had three spaces between it and shouldn't have.
Yup, that was a good use of my time, all right.
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?
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.
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.)
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.)
Subscribe to:
Posts (Atom)