In the last blog post, I wrote about complaints about the Labware LIMS. Today, I write about a search term that found my blog: “problems with labware lims implementations”
The major problems you find with LabWare LIMS implementations are the same problems you find with many of the “big” LIMS implementations. If you get into this major category LIMS that takes the bulk of the LIMS market share, what the products tend to have in common is that they are extremely flexible and powerful. This is a recipe for disaster and for quite a lot of money going down the drain quite quickly in the hands of the wrong resources.
For example, the Thermo Fisher Scientific Sample Manager product has gotten something of a bad rap as a product that is almost impossible to implement without spending a fortune and ending up with an implementation that’s a nightmare to maintain for the long-term. And for those of who you think the LabWare LIMS has that same reputation or who could name any of the other major products, you will notice the same factors in the projects that lead to these reputations.
First of all, as any expert knows and will tell you, you won’t have an implementation of these types of products without writing code. Whether it’s called “programming” or “scripting” or “configuring,” it’s still the act of writing code. And, the more of it you write, the harder the implementation becomes to manage and maintain. Small implementations usually do alright because there’s less to manage but when you get to large implementations, this is where it gets hard.
Also, not all large implementations fail. We hear about the ones where people spend hundreds of thousands or millions of dollars and there are quite a number of truly notorious projects that the industry knows about and can pick apart in a project autopsy but we seldom focus on the ones that succeed to learn what is “right” with them.
The ones that succeed usually have good resources with strong project management. They have great communication. Their resources are either highly qualified or they get excellent training and mentoring to become highly qualified. There are other factors, too. But take away any of these and the project starts to falter. For example, poor resources that are unqualified and not properly trained make for poor projects regardless how well the project is managed. One significant and important factor that is bad is enough to kill an implementation.
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/
We are going live today with our migration from STARLIMS v9 to v10. We’ve had a very successful 5-year run with v9 and see many things in v10 that will improve our operations even more – not least of which is expansion to other sites globally. BUT…
Code/scripting/customization/not-out-of-the-box is part of a STARLIMS implementation as well. As we’ve been preparing for this migration, it’s become painfully obvious that “works” and “usable” are not synonyms. Creating forms, designing custom tests and calculations, generating need-specific reports, all of these require dedicated effort, commitment to completion, management support, and vendor-consultant-customer cooperation. It’s a sophisticated dance in all but the most simple of environments – and those are still using the Microsoft Excel LIMS.
Net comment: I concur that one failed component of the project effort can be enough to bring the whole down. Each specialized role (admin, developer, manager, IT) needs to deliver well for project success. I’ve been blessed with 2 (soon 3) successful LIMS efforts – but it’s been a lot of sweat and dedication on top of the talent that’s made it work.
Fully agree,, People have a greater influence on the project than the actual system.
In this context I recommend the book Death March by Edward Yourdon. It is a good review on handling projects that have a significant potential to fail.
Best regards,
Johann
I would qualify the statement that having your key components for a successful LIMS implementations at the start is important.
If you start with poor or unprepared project management, even if you bring in a wizard that saves the implmentation, you will still feel that it was unsuccessful. At the end of the day, the status of a large project implementation is somewhat subjective and subject to our emotions.
Same thing goes, for example, with estimates. Take two identical projects, and tell the first project owner that it will take 6 months, and tell the second one 18 months. If it takes 18 months, the second project owner will feel it was successful, whereas the first one will feel it was not – even if they were absolutely identical and all other aspects worked out.
Some of this comes down to “expectation management” which is integral to proper project management. It is too often ignored. However, it’s also difficult for a project manager to do this if the sales team creates inappropriate expectations.
Thus, the challenge for large services groups is for Sales to work closely with Services to properly manage the customer’s expectations. In a small company like mine, it is merely down to a single person so there is no coordination on this issue – that single person properly manages expectations or totally messes it up. But in the larger companies, which I’ve both worked for and observed, over the years, this remains one of the great challenges for them, since there are two teams, Sales and Services, where the ball can be dropped in a major way.
While I agree with Ed, that the project manager who gives the better estimate and sticks with it with end up with satisfied customers and a better reference site, customers should be aware that when they take the lowest bid, that is not always the wise choice nor the way to a lower project cost, nor should they consider that the highest bid is going to bring the best result. Instead, select the services vendor with the best track record and the outcome will be a more predictable project cost which can be properly budgeted-for.
We are about to implement StarLims 10. I would love any advice from anyone with experience in this matter. The fact that the system is super configurable gives me cause for concern. Any help gratefully received
Lyn, the most basic advice starts from the fact that this is a software project. Depending on the size and complexity of the implementation, you will probably need a project manager, business analyst, implementation specialists, etc… If this system will be validated, you will need validation experts starting right now. The goal will be to manage the project to keep it reasonably close to the budget, but still get the maximum of needed changes to it to make it usable to your users. This means that you’ll need to gather requirements, prioritize them, negotiate them with regard to getting the most possible within budget, risk management, etc…
Validated or not, proper testing is always required and, for long-term maintenance, the people doing the implementation need to have good documentation and other implementation practices so that they can document what they’ve done, properly test it, etc…, all part of a software project.
My best advice is to take the term COTS (Commercial Off-the-Shelf) with a big grain of salt. Truly, this isn’t a “from scratch” project where you start with a blank slate, and don’t treat it that way or you’ll end up changing too much of your system. However, you must treat it as a software project, but one where you are adding to what is already there.
With regard to testing and possibly validation, remember that “configuration” can be complex so it sometimes does need to be tested. Lists need to be proofread, but anything that exerts control should be tested and validated (when applicable).
If this is the kind of advice you were looking for, you might want to search this blog for advice on things like business analysis and project management. Also, my web-site has a few articles on that topic that might be helpful to you, as well at: http://www.geometrick.com/resources.html#SelectedArticles
Gloria Metrick
GeoMetrick Enterprises
http://www.GeoMetrick.com/
Stakeholder management matters a lot too. If the LIMS creates lots of work for the scientists, and benefits only management, then the implementation won’t go well.
It’s worth looking at this classic paper, which coined the term “counter-implementation”:
Information systems and organizational change by: Peter G. W. Keen
Commun. ACM, Vol. 24, No. 1. (January 1981), pp. 24-33, doi:10.1145/358527.358543