By James McMillan and John T. Matthias, April, 2013
For purposes of this article, and as previously defined in the NCSC Case Management Systems Functional Standards, we will refer to “Calendaring” as the act of defining the availability for court events to occur in a future date and time, and “Scheduling” as the act of assigning the events. We also have to differentiate Scheduling and Calendaring from normal court tasks/events in that these events require face-to-face (F2F) personal (well maybe video, V2V?) interaction. So for this article we will be focusing on those events to differentiate from other tasks/event work discussed in Part 6 of this series.
But before we get into the technology issues, let’s quickly discuss the goal of a good calendaring and scheduling system. It is simply to maximize the use of the scarce resource of judicial time and use that time to efficiently adjudicate cases brought before the court. As many of you know the practice of court management has focused on calendaring as one of the key areas of study and innovation in the past. Individual, master, hybrid, and specialized calendar systems have been designed and effectively implemented. And overall the lessons from these various approaches have been included in the subject of caseflow management. (See the NCSC Resource Guide on Caseflow Management for more).
Now back to CCMS design discussion. The analogies most often used for the calendaring function is one of setting up a series of “buckets” or “slots". These buckets represent the amount of work events that a court normally expects to hear during a specific time period. So buckets will come in different “sizes”. Some buckets are set up to hold a specific amount of time while other are designed to hold a fixed number of events. A courtroom would have for example a one hour bucket of time for motions, followed by two hours for hearings in the morning, and a three hour bucket for trials in the afternoon. And of course the buckets will change based on the day of week, or even a full week or month time period (in some places this is known as a court “session” or “sitting”). As you might guess, hearings are usually fairly short proceedings and therefore a hearing bucket with counts as the measure might be appropriate; while a trial bucket might be defined with time parameters, perhaps extending over multiple days.
The “buckets” can control the type of event that can be scheduled in that time period. Calendaring the “bucket” parameters (i.e. the number, type and size of buckets) is often done on a set schedule, such as quarterly or semi-annually, and/or when judicial assignments change. Buckets can be set up for a judge or a courtroom, and may include interpreters, courtroom staff such as a clerk, bailiff and court reporter, and combinations of these resources. But a better practice is to associate buckets with work roles as discussed in Part 3 of our series. This allows for easy association/substitutions when the persons fulfilling those roles change such as when one person is unavailable or when judge assignments change. And roles can also be groups which allow say a judge’s courtroom team to be associated with a bucket. Roles and groups can also be used to define the participants in a master or hybrid calendaring system.
Now the reason for creating predefined buckets is to allow the CCMS scheduling function to automatically search for the next bucket (or buckets) that has time (or counts) available. The search then either automatically schedules the event in the bucket or presents options to the person scheduling the event (this is an important concept to remember for the next companion article). But the search will also need to apply search control parameters regarding the number of future work dates/buckets to examine in the database. This is because automatic scheduling without controls could potentially return a date that violates law (such as speedy trial statutes) and/or the court’s scheduling court rules; as well as possibly being very slow because of an excessive search. If the search fails to find an empty bucket, it must return a message to the user so that an alternative action can be taken. A user might be prompted to examine specific date/time buckets to see the type of matters that are scheduled, and decide to “overfill” that bucket. The system must also allow for this manual override (after all, people are generally smarter than computers). And a "smart" search results messages should assist the user by suggesting the buckets to examine first.
In a large local court, state, or national system the buckets may also be restricted by court type/ jurisdiction, court division, and location. Again, this is a reason to have these factors defined in the court organization part of the CCMS as we discussed earlier in Part 3 of this series.
Last, the issue of conflict of interest checking is often asked as part of the calendaring and scheduling functionality. This depends on whether the case is assigned on an individual or master/group calendar. If the case is assigned in an individual calendar process then the pre-defined conflicts that are associated with a specific judge are normally checked when the case is initially set. But if the case is being heard as part of a master or hybrid calendar system then the conflict of interest checking may need to be done as part of the scheduling function.
So there are the CCMS functionality basics for court calendaring and scheduling. In the next part in our series we will explain why this functionality must be extended and expanded.
Next time, Part 9B, additional needed calendaring and scheduling functionality.
Previous articles in the CCMS series: