I was looking at my blog statistics for two days ago and discovered that someone found my blog by using the search term “labware lims interview questions” and wanted to address this more specifically. Let’s discuss the types of questions you’ll ask. First of all, by using the term “interview” we’re talking about interviewing people to bring onto your project. You could, of course, just contact me, Gloria Metrick, a LabWare LIMS expert, and make it easy on yourself. 🙂 But supposing you don’t want to take my word for it or have other reasons to interview other people, here are some thoughts on how to get started on this task.
Since the LabWare LIMS is considered a COTS (Commercial Off-The-Shelf) with “configuration” but is not boxed software (such as buying MS Office, for example), some of your questions must relate to this. Falling in this category are its competitors, SQL*LIMS, many of Thermo’s products, StarLIMS, and even products such as PE LabWorks. Of course, there are a multitude of products that fall into this category, for various industries, and meant for different installations. And then, outside of LIMS, various ELN products follow this model, as do some of the other types of software.
With regard to people like the Project Manager, while it’s ideal that this person has experience with managing a project with this software, but they should, at least, have experience with laboratory informatics software installations of this size.
As for the others, you need to find people that specifically know the software. Additionally, for those people that will work with this category of COTS software, here are some points to consider:
- They should have worked on exceptions-based projects, before. That is to say, you’re neither building software from-scratch nor are you installing boxed software. There are many skills specific to this type of project.
- One specific skill is that people who configure/script/customize/program these systems need strong software development skills on top of a strong knowledge of the actual software.
Those of us that implement these systems, true to our type of people all over the world on all types of systems for all types of uses – we don’t like to document things. For us, the fun part is getting the system working. We will make many excuses. Here are a few:
- This is all self-documenting, so no-one needs to write this down.
- Even though this looks like programming code, it’s just configuring, so no-one needs to write it down.
- Well, okay, it really might need to be written down, but don’t use the expensive resources to do this – you’re wasting that person’s time and your money by doing this – push all documentation off onto the cheaper people.
When we say this to you, I give you permission to laugh out loud and right in our face. As for the last excuse, well, that might apply to some of the test scripts, because you actually can find some ways to leverage your use of cheaper resources if you plan this and train them well, but the system documentation is actually more cheaply done by the resources that do the work. Sometimes, in protest, they do a sloppy job and it ends up costing you more. Be ready for this. Make it clear to them you won’t put up with this. Be clear that mistakes and misunderstandings are one thing, but if it looks like they’re just being difficult that it comes our of their pocket not yours and make this agreement ahead of time.
On top of these skills, you want people who know the software you’re going go purchase or are enhancing. Business Analysts, people doing data loading, programmers, testers (including validation testing), script writers – these people should all have experience with the product involved. Script writers, testers and data loaders must have some familiarity with the system and good learning abilities in order to learn any parts of the system they haven’t used before, but those people configuring/scripting/customizing/programming the system need a deeper knowledge.
So, you’ll need to find out what you’ll specifically need from these people. If you’re working specifically with the LabWare LIMS, as an example, you want people that worked with the areas of the system that you’re implementing. Some areas, such as Stability, Dissolution, Instrument Interfacing – these are all big pieces to implement. You want to prioritize that, if you need one of these areas implemented, that it’s probably a higher priority than getting someone with experience in some of the areas that are smaller. Also, by knowing one area of the system, a person often does know other areas, too. For example, to work with LabWare’s Stability module, a person also has to understand Lot Manager. Well, I’ll say this, instead – anyone who doesn’t understand LabWare’s Lot Manager has no business working with the LabWare Stability Manager, for one.
But you get the idea. If you’re working with StarLIMS, there will be specific areas you’ll be interested in, Thermo’s Watson will drive-out different questions, etc…