LIMS Upgrade Project – Letter to Self
Dear Me,
It has been a long road but the LIMS upgrade is finally complete, up and running, and validated. As I look back on this journey, I wish that I knew then what I know now. This project would have gone so much quicker and easier if we had taken the time to reflect on our true goals, review our needs and processes, and do some essential planning at the outset.
When we first started realizing that our LIMS was getting a bit “long in the tooth” and we were having difficulty satisfying our needs in an efficient way, we naturally assumed that the answer to our problems would be solved by upgrading our LIMS. We watched a couple of demos highlighting the fixes and new capabilities available in the latest version of our LIMS and our LIMS vendor assured us that everything would be great once we upgraded. We didn’t even pause to think that maybe we should take a breath, really analyze our needs, and explore what other solutions exist today that might be better for us.
We do much more collaboration both internally and externally today compared to when we first implemented our LIMS. Were there other solutions that would support our business and science goals more efficiently? Maybe we needed an ELN or LES in addition to the LIMS or perhaps we could replace the LIMS altogether! Maybe a newer, single platform, modular software solutions would be a better fit? But we never did check out the possibilities. We just forged ahead.
In blindly forging ahead we missed yet another opportunity for improving our lab and organization. We didn’t take the time to review and then optimize all of our laboratory workflows and data flows before re-implementing them. Why did we just assume that our processes and procedures had not really changed over the years? Even more troubling, why did we assume that we even still did all those workflows anymore? I guess we were just in a rush to get the upgrade done and have all our LIMS issues resolved. Unfortunately, by rushing ahead we ended up re-implementing a bunch of workflows that were not really being used or did not really match how work was currently being done. By the time we got around to user testing and found out that most of these workflows were not useful, we had already spent tons of time and resources re-implementing them. Now we would have to go back, reanalyze our workflows, work together to optimize them, and then implement them anew.
Another key thing that I wished we had done from the outset of our LIMS upgrade project was to more fully explore and then implement some of the new features and capabilities that the new version of our LIMS offered. We had briefly seen some of these when we sat in on the demos and several of these were very intriguing. In fact, we noticed that a couple of them were functions that we had developed ourselves through customizing our LIMS. However, as we continued to rush forward to get the upgrade done, we relegated these to be looked at and possibly implemented “someday in the future”. I wish that we had chosen the top 3 new capabilities and elected to implement them because we all know deep down that “someday in the future” really never comes!
Speaking of customizations, we were always told that the LIMS API was a standardized interface that was designed to be unchanging. So if we followed the rules provided by the LIMS vendor and used the sanctioned API calls, syntaxes, and naming conventions, all our customizations would seamlessly port to future versions. We, of course, assumed this was fact. We found out that maybe this is one of those “alt facts” we hear so much about these days. It turned out that when we went to rerun these customizations, they crashed! Evidently the LIMS API was not as unchanging as we were lead to believe and the underlying architecture and table structure of the new version of our LIMS is slightly different. So instead of a “clean port it over and it will run” scenario, we were confronted with the need to go through each customization and repair the issues that were uncovered.
The good news, however, was that since we ended up having to spend all this time and effort reviewing and fixing our customizations, we were able to determine that some of our customizations were now standard functions in the new version of our LIMS. So instead of fixing those customizations, we replaced them with the standard functionality that was now supplied by the LIMS vendor.
Now if only I could locate Marty McFly and Doc Brown, maybe I could get them to deliver this letter to myself before we started our LIMS upgrade project. Or, if we had engaged some experienced LIMS consultants, we could have really had such an easy time with our LIMS upgrade and our ROI would have been so much better. Oh well, lessons learned…
If you could start your LIMS upgrade project over again, what would you tell yourself to do differently? Do you have other LIMS upgrade lessons learned beyond the ones stated here that you can share? Did you involve Subject Matter Experts (SMEs) in your LIMS upgrade project? If not, did you wish you did?
Comments