When the doomed project started about 11 months ago, we had a very tight, very optimistic schedule that had us publishing an interim rule some time this past summer and the final rule on the deadline of January 1, 2012. After a couple months, we had missed a major deadline and it was clear that we were still nowhere near meeting its goal, so we got a revised schedule that had us publishing the interim rule by January 1, 2012 - not the original intent, but still within the letter of the Congressional mandate. Based on what we had done at that point, the revised schedule was still very tight and very optimistic. As the project went on we missed deadlines by a few days here and there and had new bits added in, so multiple slips in the schedule led to us hoping to have the interim rule out of our building by January 1, at which point it would start review by other departments of government - not meeting the Congressional mandate, but at least we would be able to prove that there was a tangible product and say that it was out of our hands. The ball would be in someone else's court.
That was the case as of two weeks ago or so. After enough such delays, H. is now working on a new schedule. And of course, now the holidays are coming up and people will be out of the office for vacations and stuff. By now I will be surprised if we even get it out of the building in time.
This was mostly inevitable. As I said, everyone knew from the start that a one-year deadline was much shorter than usual.
However, every time we go over a deadline by too much, the team has to explain why and have a meeting and H. has to send several e-mails and put together a new schedule. So I have to assume we would be a little bit closer to done if the schedule had been more realistic to begin with.
Friday, October 28, 2011
Tuesday, October 25, 2011
IMs between myself and a co-worker with a funny name
John:
This is great. I have a question for someone on [the doomed project] about why someone in his department made a bunch of big changes to the rulemaking, and why he did it in a completely separate document that I now have to merge. The team member is away. His away message refers to someone who retired last week.
Funny name:
bahaha
welcome to the [agency], John
-_-
John:
Heh, thanks.
The merge looks like no problem at all, actually - I think I can just make the version with the new stuff, the main version. But that's sheer luck. It's still bad practice. I just think all of it together is funny.
Funny name:
hahah
yep
it's like a parody of itself
This is great. I have a question for someone on [the doomed project] about why someone in his department made a bunch of big changes to the rulemaking, and why he did it in a completely separate document that I now have to merge. The team member is away. His away message refers to someone who retired last week.
Funny name:
bahaha
welcome to the [agency], John
-_-
John:
Heh, thanks.
The merge looks like no problem at all, actually - I think I can just make the version with the new stuff, the main version. But that's sheer luck. It's still bad practice. I just think all of it together is funny.
Funny name:
hahah
yep
it's like a parody of itself
Friday, October 21, 2011
The problem with asking for advice is that you might get it
I've been on three active projects for the past year or so: the doomed project, the blackmail project, and a third, minor project, which was relatively functional and smooth-running, as you may be able to tell simply by the lack of an ominous epithet.
Of course, you'll notice the use of the past tense. The current stage of the minor project has been taking longer than it should for the past several weeks. No big deal, there's little pressure on this rulemaking, but there's a schedule and we're behind it. This is partly my fault - in addition to normal minor mistakes, I changed the formatting of part 12(c) in a pretty big way, but when my supervisors looked at it they pointed out it should be changed back for good reasons, so that's two stages of review right there - but partly other peoples' fault and partly no one's fault as new information has come in.
And then the project manager made a big mistake: she had it reviewed by someone outside the normal process. Whether the idea was hers or someone else's, it was a dumb idea. The reviewer had a few dozen critiques. Most of it was trivial errors. Should be fixed, probably would have been eventually, no big deal even if not. A few were good points; we should be grateful for him catching them. The problem is that he disagreed with my bosses on part 12(c). Now, as the name of the blog says, we writers are low on the totem pole, but still, if we have any domain, proper formatting is it. And besides protecting our turf, there is also an objective reason to handle 12(c) our way. We put time into the "right" and the "wrong" way to underline text, but that's just because there are "right" and "wrong" ways. If we screw that up, and even if it gets by everyone else, it's still very, very unlikely to actually effect what regulations do. The formatting in 12(c), though, really could change the meaning of the regulations.
After explaining the reasons to the reviewer, he suggested doing 12(c) in a third way. The first and second ways were disagreements about how we should print the notice, but the third way would also reformat the table as published in regulations. That would fix some of the substantive problems but create others, my supervisor said. I don't really agree with her. In fact, I've come up with a fourth way to do it that I think would be best of all. It would also change how the table looks in regulations, but I think it would avoid all these issues. The only problem is that it would be more work for me, so I've been describing it as something to do in a future rulemaking rather than here, but even so my boss doesn't seem very positive about it.
However, I do agree with her that this kind of thing is our domain. And agree with her or not, she's my actual boss. So next week I'll probably have to persuade the project manager and the unexpected reviewer to please let us do 12(c) our way, pretty please, and put off any other methods for later. That probably won't be fun. Especially since I accidentally misspelled the unexpected reviewer's name in an e-mail. Twice.
Of course, you'll notice the use of the past tense. The current stage of the minor project has been taking longer than it should for the past several weeks. No big deal, there's little pressure on this rulemaking, but there's a schedule and we're behind it. This is partly my fault - in addition to normal minor mistakes, I changed the formatting of part 12(c) in a pretty big way, but when my supervisors looked at it they pointed out it should be changed back for good reasons, so that's two stages of review right there - but partly other peoples' fault and partly no one's fault as new information has come in.
And then the project manager made a big mistake: she had it reviewed by someone outside the normal process. Whether the idea was hers or someone else's, it was a dumb idea. The reviewer had a few dozen critiques. Most of it was trivial errors. Should be fixed, probably would have been eventually, no big deal even if not. A few were good points; we should be grateful for him catching them. The problem is that he disagreed with my bosses on part 12(c). Now, as the name of the blog says, we writers are low on the totem pole, but still, if we have any domain, proper formatting is it. And besides protecting our turf, there is also an objective reason to handle 12(c) our way. We put time into the "right" and the "wrong" way to underline text, but that's just because there are "right" and "wrong" ways. If we screw that up, and even if it gets by everyone else, it's still very, very unlikely to actually effect what regulations do. The formatting in 12(c), though, really could change the meaning of the regulations.
After explaining the reasons to the reviewer, he suggested doing 12(c) in a third way. The first and second ways were disagreements about how we should print the notice, but the third way would also reformat the table as published in regulations. That would fix some of the substantive problems but create others, my supervisor said. I don't really agree with her. In fact, I've come up with a fourth way to do it that I think would be best of all. It would also change how the table looks in regulations, but I think it would avoid all these issues. The only problem is that it would be more work for me, so I've been describing it as something to do in a future rulemaking rather than here, but even so my boss doesn't seem very positive about it.
However, I do agree with her that this kind of thing is our domain. And agree with her or not, she's my actual boss. So next week I'll probably have to persuade the project manager and the unexpected reviewer to please let us do 12(c) our way, pretty please, and put off any other methods for later. That probably won't be fun. Especially since I accidentally misspelled the unexpected reviewer's name in an e-mail. Twice.
Catching up
My bosses have said that the doomed project is my top priority, but I'm not really sure what I'm can be doing there right now. I think we're getting "close" to big "deadlines", but not as close to them as we were a week ago, since something else was added in. But no one has asked or told me to do anything about that yet.
So without any specific assignment, I spent a lot of my time yesterday cleaning up a spreadsheet, and I plan to do the same today. We created it to collect comments left by reviewers in four different Word documents. (Yes, this was a messy process full of unnecessary work, but it seemed like the thing to do at the time. See previous comments about version control.) I entered all the comments from one document before starting on the next, and didn't worry about any sensible order for them at the time, so that the first comment in the second document I happened to work on was in the row below the last comment of the first document.
But there is a logical way to organize this, so I've been going through and putting them in it. And no, I can't think of a way to use the Excel "sort" function here. So it's pretty mindless work, but it should be a bit useful in a couple weeks. Next time I do one of these I'll be more careful about how I create the spreadsheet, I guess.
So without any specific assignment, I spent a lot of my time yesterday cleaning up a spreadsheet, and I plan to do the same today. We created it to collect comments left by reviewers in four different Word documents. (Yes, this was a messy process full of unnecessary work, but it seemed like the thing to do at the time. See previous comments about version control.) I entered all the comments from one document before starting on the next, and didn't worry about any sensible order for them at the time, so that the first comment in the second document I happened to work on was in the row below the last comment of the first document.
But there is a logical way to organize this, so I've been going through and putting them in it. And no, I can't think of a way to use the Excel "sort" function here. So it's pretty mindless work, but it should be a bit useful in a couple weeks. Next time I do one of these I'll be more careful about how I create the spreadsheet, I guess.
Wednesday, October 12, 2011
This seems familiar
So H. told me this morning that the doomed project might be delayed again. Apparently someone just noticed that something needed to be added to it. When she described the problem to me, it seemed like such a no-brainer. I mean, I don't personally care about this, and I don't have the technical expertise to know how important it is, but given both the general area and other things already in the project, adding this morning's content seems like such an incredibly obvious thing that it's hard to believe it hasn't been discussed before.
The previous paragraph could have been written half a dozen times over the past six months. If I look back at this post in a year I won't have a clue which one it's talking about. And, in fact, last I heard, H. wasn't sure yet whether this morning's issue really will need to be included. So I'll describe it as "operational l__" just in case.
The previous paragraph could have been written half a dozen times over the past six months. If I look back at this post in a year I won't have a clue which one it's talking about. And, in fact, last I heard, H. wasn't sure yet whether this morning's issue really will need to be included. So I'll describe it as "operational l__" just in case.
Tuesday, October 11, 2011
Boundaries
One problem I have is being too open with my supervisors. It's complicated because they all happen to be pretty nice, approachable people, and, as always, the oddities of this job put them in positions much like my own often.
But I still need to remember that they're my bosses. I can't go around saying that I'm deliberately doing something in a way that makes it more likely for other people to make mistakes, or reject proposed options based on the incompetence or lack of care of higher-ups. I've done each of those within the past month. The latter was in an e-mail, and hindsight being 20/20 I'm really lucky she didn't simply hastily forward it by accident.
More generally, though, I've got to remember it because presumably my bosses don't want me to be thinking like Wally in Dilbert. Or at least, they don't want to know that I do.
But I still need to remember that they're my bosses. I can't go around saying that I'm deliberately doing something in a way that makes it more likely for other people to make mistakes, or reject proposed options based on the incompetence or lack of care of higher-ups. I've done each of those within the past month. The latter was in an e-mail, and hindsight being 20/20 I'm really lucky she didn't simply hastily forward it by accident.
More generally, though, I've got to remember it because presumably my bosses don't want me to be thinking like Wally in Dilbert. Or at least, they don't want to know that I do.
Subscribe to:
Posts (Atom)