Even though GeoMetrick Enterprises does not supply training services, most of us do eventually have to take part in training, whether assisting trainers to understand a new implementation or in taking training, ourselves. Some training is better than others and people learn in different ways, but some ideas work for very few people, regardless. Here are the ideas that are ineffective in training, but are actually seen all too frequently.
Some of the customers who read these posts are working to do as much of the actual work on their system, as possible, to include LIMS/ELN/LES System Administration, configuration, programming, etc… Others have decided that they don’t need to build some or all of these skills in-house and are asking their software vendors or other outside consulting firms (such as the premier GeoMetrick Enterprises) to do the work, instead. In doing this, while you do avoid having to build the skills in-house, you do not abdicate yourself from the potential issues that can come from this.
In my last post, “Notes on Software Testing Habits,” I ran through a few thoughts about how to look at your software testing habits. Regulated or not, there are many commonalities.
In LinkedIn, I recently forwarded a post by Martin Lush entitled “Don’t Blame the Person – Fix the System!” One outcome for me from that is that it started a variety of side conversations with other people in the industry. One area of conversation that came up is that of testing, as a general topic and, today, I want to share my own thoughts on testing.
There are such a variety of users being served out there, people who need to get work done regardless of their computer skills, that it’s possible that those of us providing applications are expecting too much from them.
Many projects have a problem getting reports produced. In one sense, it seems expensive to hire a LIMS, ELN or LES expert who knows the data but who comes with a rather high rate. On the other hand, getting a cheap resource who knows the reporting tool isn’t an easy solution because it’s so incredibly difficult to teach them these massive databases and how they work. Today, I will tell you the solution to this problem.
Paul Drake was Perry Mason’s investigator. Last year, I had an opportunity to do what I suppose might be considered database investigatory work.
Just the other day, I had an interesting discussion with someone who is using remote resources on their project. We had a bit of a laugh over those people who constantly worry that remote resources might not be doing what they’re supposed to and, instead, goofing-off or, as we say in our industry jargon, “eating bon-bons.” Most projects are pretty savvy about this but what if your project is new to do this? How would you know, short of putting cameras on them?
There are always up-and-coming products out there but, these days, I seem to run into more and more new products. New LIMS seem to abound, for one. Not only are there new products coming up here in the USA, but there are always products coming from other countries that would like to get a foot-hold, here.
In my last post, I talked about failing projects in “Three Reasons Failing Projects Continue to Fail.” But what about the projects that are doing well or at least moping along at a decent pace? This post is about those projects.