Showing posts with label Driver Coding. Show all posts
Showing posts with label Driver Coding. Show all posts

Sunday

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.

.

.

Saturday

Workload Drivers - Changing discovery, updated drivers?




Question: We understand that applicable drivers may change during the life of a case. For instance, at the beginning of a case, we may have a good faith belief that a client is an armed career criminal, but further investigation assures us that he is not, and so we remove that driver once our investigation is complete.

Does this idea of change apply to the discovery drivers?

Answer: Yes. Drivers may be added or removed at any time during the life of the case. If the driver is no longer necessary to explain what is requiring the time entered in defenderData, it should be removed. As you note above, once you have eliminated threat of an ACCA  enhancement, that driver should be removed.

Discovery can and will change during the life of the case. When that happens, it is important to update the drivers. For example, if there is a “data dump” of a terabyte drive on a fraud case that previously had a thin paper file disclosed, one would want to immediately update the discovery drivers. Those updated drivers will help explain the resources devoted to the defense, as the team bills to the case.

.

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.