It’s not uncommon within specific software communities for there to be what we call “vertical” resources. I’m one, myself – a person trained to be able to handle the entire project, from project management, to business analysis to development work. There are specific reasons these resources exist and, as my customers tend to like, some benefits, as well.
People get into arguments about what programming language is best to use for laboratory software projects. Some people argue for C#, others for Java, and we get into heated discussions about which languages are “real” programming languages and which should be dropped to the bottom of a deep ocean. In the end, for most projects, it doesn’t matter.
I’ve worked for, with and as a project manager, and for and with managers, as many of you have. Among them, some have been great, others horrible, many mediocre. What brings this to mind is that I was having a conversation with someone not long ago who was talking about their project manager and just making some general comments, neither positive nor negative, but merely descriptive. In hearing the comments, I realized both that the person had no idea what a project manager actually does and also that their project manager doesn’t actually do project management. As an aside, I’d been reading “The Spy and the Traitor” and realized that story is relevant to this (which I will get to later in this post).
In the last post, I talked about how micro-consulting can be useful for customers. While there might be advantages in using the largest firms, there are just as many disadvantages. One disadvantage is that using the larger firms can be more expensive. Here are three reasons why a micro-consulting firm is less expensive.
These days, it seems as if we can get micro-anything-we-want. We can get micro-greens, micro-brews and micro-distilling, just to name a few. In any case, I knew that micro-roasting (of coffee) was a “thing” but I was quite surprised, the other day, when I ordered coffee and each bag I received had information not just about what coffee was in the bag, but it said it had been specifically brewed for me (it had my actual name on each bag) and gave the date and time roasted.
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.