Workload Drivers - When should I be coding Workload Drivers? As soon as they are known, or can I wait until the end of the month?

Question: Do I have to code the Workload Drivers as soon as I become aware they apply, to get “credit” for the driver during timekeeping?

For example, assume I open Jane Doe’s case on August 1, but don’t code any workload drivers to her case. I bill time to Jane Doe's case during the next four weeks, but I don’t get around to coding the drivers on the case until the end of the August. Will any of the time I entered in August, before I coded the drivers, be appropriately weighted?

Answer: No, time entered before a driver is coded won’t be appropriately “weighted.” Workload Drivers should be coded before time is billed to the case.

If the Workload Driver isn’t selected before the time is billed, that time will not be appropriately weighted in the study. The key concept is that the drivers help explain the time resources the office is devoting to the case. If the driver isn’t coded to the case, that association between the workload driver and the time billed to the case cannot happen.

Before the fall data collection periods begin, every case should be fully coded and reviewed for accuracy with all of the workload drivers. As new cases come in, they should be promptly coded with any immediately-obvious drivers (i.e., citizenship, remote detention, remote court, etc.) As drivers change during the life of the case, those changes should be promptly coded into the workload driver tab. Contemporaneous coding of drivers will make for accurate explanations of the resources devoted to the case.

dData has the capacity to “backdate” drivers – and that backdating is entirely appropriate. There is a small box with several ellipses next to the individual driver on the Workload Driver tab. By clicking on the box, you can force enter the effective date of the driver, and backdate it. 

From a practical perspective, however, we'd emphasize that this backdating process is slow  -- there are unavoidable lags in the dData system every time that backdating box is selected. Multiple that little lag over hundreds of cases and thousands of drivers, and it can really slow the process down if you are backdating every driver on every case.

It is much, much more efficient to code drivers contemporaneously, as soon as the driver is known.

.

.

Are there suggested procedures for coding Workload Drivers?

Question: Can offices who have already gone through Workload Driver coding offer some suggestions for this project?

Answer: Puerto Rico, Colorado / Wyoming, Arizona, and the ND Cal have all completed workload driver coding for all cases open in July. Many other offices will have their coding completed in August. From these experiences we suggest the following tips:

• Assign a Legal Assistant or Paralegal to be the “Driver Driver.” That person can interview every AFPD or AFD in the office, and prepare hard-copy sheets with all applicable drivers for every case. We will be distributing an Excel sheet with the drivers replicated, as seen on the dData Workload Driver screen, for these interviews.
• We recommend that the Driver Driver, and other support staff, code the drivers in dData instead of attorneys. Better quality control, and more efficient: it allows the attorneys to focus on the substantive driver decisions. 
• Manually tally the number of drivers selected on the hard copy sheets. There is a numerical tally in dData for workload drivers assigned to a case. Those figures should match – a quality control feature. 
• There is a box for “no driver selected” in the Workload Driver tab of dData. Make sure to check that box if no drivers are selected.  Without that box checked, there is no way to confirm whether the case was actually reviewed.