A good number of court IT projects fail. I share my list as to what and why in this Court Tech Bulletin post for the end of February 2017.
---
1. Failure to understand the total court information environment. Registry/docket books look easy to automate as do file folders. The problem with looking at those systems individually is that there is a failure to understand that they work together in a symbiotic relationship with one another along with scheduling, task management, financial tracking, and document creation and management. I initially thought of the “five bubbles” model back in 1988, I believe that they are still applicable in creating a framework.
2. Failure to communicate. Fear of change is significant in judicial systems. Therefore, any project team that is introducing new technology must over-communicate what and why the automation is needed.
3. Failure to address the needs of the judiciary. There are have been literally hundreds of projects that have benefited the clerical function and even the public, but not judges. Why? Fear? Lack of imagination? The technology is here and has been proven. It is now time that all parts of the court organization including judges benefit from IT.
4. Cost. There is sometimes just not enough money available to do the project correctly. So the project timeline is extended so that by the time the system is complete it is either obsolete or no one remembers what it was supposed to accomplish. I have also seen projects narrow the functionality so much that the system fails to meet the court’s operational needs.
That said, I have also seen projects fail to use a strategy of adjusting by using less expensive approaches such as open-source or by borrowing existing systems from other courts. Not invented (or purchased) here is a conceit that courts sometimes cannot afford?
5. Poor acquisition strategy. In 2012 we ran a CTB article on this subject in cooperation with my good friend and Federal Magistrate, Curtis DeClue. We share it again here.
6. Lack of time for implementation. New systems come with a steep learning cycle for the court organization. Therefore, in our experience , t takes a minimum of two implementation cycles to get the system right. The first cycle is used for orientation so that judges and staff better understand what the system can do, and how it does it. Ideally the court then runs a second implementation cycle is done to take advantage of that knowledge and make the system sing.
7. Vendors as a business failing. I don’t have an answer for determining whether a vendor will fail as a business? I have worked on projects that have done all the due diligence reviewing financial reports, performed reference interviews, reviewed the technology with experts, and still the vendor has failed. If someone has a good way of addressing this, please share below in the comments section.
8. Not asking for help from courts and experts who have done it before? Judges and court staff are great at sharing their experience. But I often find that courts sometimes seem embarrassed to ask for help. Don’t be!
So that is my list. Please share if you have items to add in the comments below. I know that everyone will appreciate it.
Poor or non-existent project management methodology - which of course leads to most if not all of the issues listed.
ReplyDeleteExcellent point. Thank you for writing.
DeleteLast but not least is wanting to recreate the existing system and process without looking at efficiencies and process re-engineering.
ReplyDeleteExcellent! Thanks Robert for the input. - Jim
ReplyDeleteAs usual, Jim, good stuff. I think you've delineated things very well, in particular the communication and judiciary aspects. Communication is always a keystone yet I'm consistently surprised at how it's lacking (and not just w/i a court itself). As for the judiciary, if you don't get the judges on board, that can be some tough sledding. Thanks for the post!
ReplyDeleteJim, a good list of reasons. As Court Administrator, I've been involved with local projects that were quite successful with a lot of staff and judicial input and an understanding, cooperative funding source. I've also been involved with 3 statewide projects. One was very successful in that it replicated a "local approach" to system development and roll-out. The other two were home-grown from the bottom up that tried to provide all with everything they said they wanted/needed but the one-size fits all result meant it was too sophisticated for the smaller courts and something less that larger, more advanced courts already had systems generally meeting their needs. Add in many of the factors you've listed (funding, functionality, vendor issues, selling the product and the need without good communication, user acceptance if not involved in the development, process change without necessarily being seen as process improvement, etc.) in varying combinations were factors in less than stellar roll-outs. The states will remain name-less.
ReplyDeleteGood thoughts Jim. I would also add the following:
ReplyDelete9. Inconsistent development methodology. There is always more than one way to implement a project. Each methodology will solve some problems better than others and vice versa. Too often, projects switch methodologies because it solves one problem, then switch to solve another. This always leads to inconsistencies and incompatibilities that drag a project down. Pick a development strategy/methodology and stick to it.
10. Try to build a system that does everything for everyone. At best this system does nothing well. At worst, nothing at all. There is no one size fits all.
11. Not tailoring the solution to the problem. A project that solves a judge's case management problem will likely not solve a trial court administrators organizational management problem. You might be able to make it do so but, then see #10 above. Another way to put this is don't try to make an organizational management project solve a judge's problem. It won't and the judge won't be happy. And vice versa
Jim, I appreciate your comments. My experience is that it is difficult to change culture if the system isn't a benefit to all users. Acceptance is much more viable if productivity is improved. Running parallel for long periods of time can also be cause for giving up on the CMS, especially if the electronic record is not authenticated as the original. Good comments!
ReplyDeleteThis is fantastic. Thank you all for your comments.
ReplyDeleteThis is a great discussion. Here is one thing that I did not see mentioned directly: We refer to it as "crossing the mutiny chasm". Almost any new technology will have a period, usually right after go-live where mutiny is possible. The period usually lasts about 90 days and it is caused by several factors: 1) users don't want to change, 2) users are inefficient because they're learning the new system, 3) the system is new and most likely has some flaws/bugs. The primary way to avoid mutiny is to prepare for it, have strong leadership that will stay the course, and to take an aggressive approach to resolving issues and helping users.
ReplyDeleteThis comment has been removed by the author.
DeleteObtaining and nurturing engagement from all stakeholders during the planning, development, and testing portions of the project are important to avoid these types of problems. People will champion the system if they have been part of the process.
DeleteAs regards funding, the courts – like most public entities – are generally limited by a very strict budget, as well as constrained by governmental rules regarding “lowest bid” contracts. Unfortunately for us, most of the design industry these days is geared towards “agile” approach to development, where costs are known to balloon unexpectedly. While this poses no significant problem to startups that can always go back to the VCs for another round, court projects are usually better off with “waterfall” IMO. However, since we are not savvy enough regarding the technical process, it is difficult to plan all phases in advance. Furthermore, the inclination to modify the product after initial consultation can doom the efforts by extending time & costs. One solution which we successfully implemented for a particular project was to allocate a portion of the budget for an outside agency to draft a business plan for us, which we then used as out model to contract development.
ReplyDelete