Today was a test of the workload management system.
***
The workload management system consists of two data repositories, one a project list and the other a time log. Projects or smaller tasks on the list are logged, as are some standard or ongoing tasks, breaks, etc. that do not need to be on the project list. All time worked should be logged.
The task list is reviewed and updated at the beginning or the end of each week, or both. This consists of removing completed tasks, adding new tasks, and reprioritizing tasks by adjusting due dates. In addition, tasks are added as soon as they are requested, and the list may be reprioritized on the fly. This aspect of the system facilitates the LIFO or "last manager screaming" method of prioritization favored in many organizations.
***
An unplanned though not completely unexpected Important Project greeted us today, of course an emergency situation with a hot hot deadline. Today is Monday, and also the last day of the month, so a natural deadline for anything with accounting implications.
When do you need this done?
The first of the month.
Tomorrow. Great. Would've been nice to know a little sooner.
No, the first of this month.
Huh?
Today's the last day of the month. So when the end-of-month stuff happens we need this month to reflect the new changes.
(and then) Will that take long?
Considering that nothing about these "new changes" were important for the entire month they were supposed to have been in effect, it did not seem the question was literally calling out for an accurate estimate in response. Nothing had been requested, discussed, or even mentioned up to now.
This is a good test for the workload management system's reprioritization ability. This case is not the classic interruption, but a large-scale interruption with many managers aligned with the potential to scream in concert.
My company has a history of this kind of sudden event. The dedicated lifelong employees continue to validate the process by putting up with the inconsiderate expectations of their superiors makes it work, time and time again. That kind of selfless sacrifice is the kind of thing I'd like to see automated.
The events unfold something like this.
Someone in the silent middle of the hierarchy is assigned to coordinate the ad-hoc team. Although that person bears primary responsibility for getting it done, the group knows this accountability is equally each of theirs. The dialog above or something like it takes place, a meeting is convened, the project is tersely complained about, quickly planned and the crucial tasks are split up.
From there, other work is put aside. Complete focus is placed on executing the project. One "emergency project" like this can derail days of previously planned activity. And there can be more than one such event at a time. (If that happens, "last manager screaming" can literally determine priority.)
The workload management system handles these events just like all other LIFO priority events. Because events are prioritized by due date, setting a tight deadline puts an event immediately near the top of the queue.
In addition to the weekly review/planning session, the event list should be updated as soon as time permits after significant changes. The impact of a "surprise event" is such that immediate review of the list may not be possible. It might be important to see a quick report of items with upcoming due dates to ensure you're aware whose requests are being pre-empted. Aside from that, no activity should occur outside the "emergency" unless absolutely necessary.
Because of this, the functionality of the system shifts from providing an immediate view of prioritized projects to storing a queue of projects for later execution.
It is most important that time is still recorded, though that function tends to accrue nearly all non-break time to the Important Project. Time recording that notes small bits of time put to other projects during the course of the emergency are better than those not recorded, but the disruptive nature of the event needs to be represented and can easily be documented by charging time in large blocks. This also reflects the attention that should be put to the Important Project.
When things return to normal, the workload system should be reviewed, requestors sent status updates, and due dates adjusted. This helps pick up where you left off.
***
The three asterisks refer to Herb Caen's "three dot" separators, but they are only separators.
***
The workload management system consists of two data repositories, one a project list and the other a time log. Projects or smaller tasks on the list are logged, as are some standard or ongoing tasks, breaks, etc. that do not need to be on the project list. All time worked should be logged.
The task list is reviewed and updated at the beginning or the end of each week, or both. This consists of removing completed tasks, adding new tasks, and reprioritizing tasks by adjusting due dates. In addition, tasks are added as soon as they are requested, and the list may be reprioritized on the fly. This aspect of the system facilitates the LIFO or "last manager screaming" method of prioritization favored in many organizations.
***
An unplanned though not completely unexpected Important Project greeted us today, of course an emergency situation with a hot hot deadline. Today is Monday, and also the last day of the month, so a natural deadline for anything with accounting implications.
When do you need this done?
The first of the month.
Tomorrow. Great. Would've been nice to know a little sooner.
No, the first of this month.
Huh?
Today's the last day of the month. So when the end-of-month stuff happens we need this month to reflect the new changes.
(and then) Will that take long?
Considering that nothing about these "new changes" were important for the entire month they were supposed to have been in effect, it did not seem the question was literally calling out for an accurate estimate in response. Nothing had been requested, discussed, or even mentioned up to now.
This is a good test for the workload management system's reprioritization ability. This case is not the classic interruption, but a large-scale interruption with many managers aligned with the potential to scream in concert.
My company has a history of this kind of sudden event. The dedicated lifelong employees continue to validate the process by putting up with the inconsiderate expectations of their superiors makes it work, time and time again. That kind of selfless sacrifice is the kind of thing I'd like to see automated.
The events unfold something like this.
Someone in the silent middle of the hierarchy is assigned to coordinate the ad-hoc team. Although that person bears primary responsibility for getting it done, the group knows this accountability is equally each of theirs. The dialog above or something like it takes place, a meeting is convened, the project is tersely complained about, quickly planned and the crucial tasks are split up.
From there, other work is put aside. Complete focus is placed on executing the project. One "emergency project" like this can derail days of previously planned activity. And there can be more than one such event at a time. (If that happens, "last manager screaming" can literally determine priority.)
The workload management system handles these events just like all other LIFO priority events. Because events are prioritized by due date, setting a tight deadline puts an event immediately near the top of the queue.
In addition to the weekly review/planning session, the event list should be updated as soon as time permits after significant changes. The impact of a "surprise event" is such that immediate review of the list may not be possible. It might be important to see a quick report of items with upcoming due dates to ensure you're aware whose requests are being pre-empted. Aside from that, no activity should occur outside the "emergency" unless absolutely necessary.
Because of this, the functionality of the system shifts from providing an immediate view of prioritized projects to storing a queue of projects for later execution.
It is most important that time is still recorded, though that function tends to accrue nearly all non-break time to the Important Project. Time recording that notes small bits of time put to other projects during the course of the emergency are better than those not recorded, but the disruptive nature of the event needs to be represented and can easily be documented by charging time in large blocks. This also reflects the attention that should be put to the Important Project.
When things return to normal, the workload system should be reviewed, requestors sent status updates, and due dates adjusted. This helps pick up where you left off.
***
The three asterisks refer to Herb Caen's "three dot" separators, but they are only separators.
posted by rich solomon at 4:56 PM
0 comments
