Laboratory Informatics Software Selections: Day 2

The conversation

7 comments from 2 people on September 7, 2011. Gloria replied 4 times.

1. September 7, 2011

   John H. Jones

   I find it interesting that you state that there is an alarming number of software project failures. I assume you are not just saying LIMS project failures but software in general. While you characterize it as alarming, I think the term "alarming" may be a function of how alarmed you are prone to get. The longer you have been in the software business the more you find that history repeats itself and you get somewhat immune to the issues that come up time and again. There is always a new clever Dick that comes along who says they know how everything should be done and everyone else just doesn't understand. Speakcing for myself, I have seen and heard most all of this so it does not alarm me that there are so many software failures brought about by folks who are essentially all mouth and trousers.

   Anyway, didn't really mean to get off on the topic of defining "Alarm"...

   I think that some new information that you might provide is what a customer should do to keep from having a project failure. At this point I am going to set myself up for ridicule and derision but that is ok. Project failures (what ever definition you want to use to define that is fine by me) and how to prevent them seems to be the most useful information you could provide.

   So many times vendors and consultants point to project failures and then use the LIMS vendor as the reason for the failure when in reality the failure lies squarely at the feet of the customer. This is a very unpopular tact to take and can be ridiculed and derided at every turn and you will not lack for supporters of that derision. However, the truth many times is not popular so it is not surprising that people keep repeating the same mistakes time and again. If you really want to solve the problem of project failures you must identify root cause and learn from it.

   My argument for focusing on customer problems rather than the vendor is simple. It is a matter of experience. How many LIMS has the customer implemented and how many LIMS has the vendor implemented. People with less experience do not do as good a job as one with more experience. So what can a customer do to make sure they have a successful project or more importantly, what should they not do.

   I would like to hear your opinions in this area to advise customers on what they should and should not do on their side when running a LIMS implementation project.

   1. Gloria MetrickAuthor

      You’ve got a number of points, here, so I’m going to organize my answer in a way that regroups it a bit.

      “Alarm” and Blame: Your assumption is correct – I did mean all of the software industry has a high failure rate not just on the laboratory informatics side. I think I’m reacting differently than you, though, John. As time progresses, I think I’m becoming yet more alarmed. Every time I think I’ve “seen it all,” I’m wrong. As I see more failures, I just get yet more frustrated than before, as well. The reason I get more alarmed and more frustrated is that we don’t seem to acknowledge our mistakes nor learn from them. In almost 25 years in this business and over that in software, generally, and I see that we keep doing the same things over-and-over, again.

      With that said, to your point about who is truly to blame, I’ll agree that we’re reluctant to blame the customers. Customers have a large share of the blame. I won’t disagree with you at all on that point. Let me be even clearer on this point – I totally stand behind your point that customers are not blameless. On one hand, if we’re the experts, we should be able to guide them out of these failures. On the other hand, they need to select the right software, the right people to work with that software and to have the right staff to support the whole thing (the right project sponsor, the right project manager, etc…).

      But where I disagree is where you say that both vendors and consultants blame the vendor. I could be a little sour about this and claim that vendors always blame consultants which is probably why consultants then blame the vendors, but I don’t quite it’s quite this divisive. I’ve worked on projects where people pretty evenly take the blame for their own actions and learn from it, vendors and consultants, alike – true teamwork in action. But I’ve worked on other projects where each faction spends its time looking for scapegoats and trying to dump blame on anyone who stands still too long.

      Some Tips: Here are some tips to follow, nothing I haven’t said in previous blog postings or some of the articles linked from yesterday, but a handful of guidelines:

      1. Software projects will fail unless you work to prevent it. I can’t go into the entire SDLC (Software Development Lifecycle) or SLC (Software Lifecycle), here, but you must properly manage the project, creating buy-in, developing proper communications of deadlines and goals, that type of thing.
      2. Anyone that can’t work in a team atmosphere must be minimized. Realistically, there might be some people that have vital information for your project that must be included at some point to gather that data but who are just not able to work in a team environment. Those people are usually your own. Few people from the vendor or consultant community have information so special that they can’t be replaced by someone else if they can’t play well in the sandbox. If you have warring factions between your software vendor’s people and the various consulting organizations, and if they can’t work with you and your people, determine exactly which ones are causing the problems and have their company do a remove and replace on them. If your people are the problem, see if you can do the same. If you can’t, consider spending some bucks on teambuilding courses and exercises. While I dislike suggesting touchy-feely stuff like this, you’re otherwise on a path to a project that won’t finish or that will spiral out-of-control.
      3. Be “big” and insist all others be the same. This goes back to (2). Everyone MUST learn to be big-enough to take the blame when they make a mistake. The customer must set a good example in this regard because everyone else will tend to follow the customer’s lead with regard to project behavior, to a large extent.
      4. Get rid of the words “always” and “never.” Don’t listen to people who use these words and eradicate them from your own vocabulary. It will make a difference in your attitude and in the way others act. For those people who insist they’re ALWAYS right and NEVER fail, and I’ve said this many times, but they’re either totally egotistical (do they really spend all day in front of a mirror admiring themselves and their ego?) or just so lacking in knowledge that they don’t even know how little they really know, to begin with (a little knowledge being a dangerous thing for them).
      5. Ignore the tools (a bit). First of all, there is no tool in the world that will solve all your problems. Thus, when you do your product selection, whether you’re selecting a LIMS, an ELN, an ERP, or anything else, it will not be perfect and don’t expect it to be. It doesn’t matter if it’s on the spider web, chubby-old client, Cloudy, or whatever the new and hot things will be. With that said, I don’t mean that you don’t need to do the hard product selection task, taking it seriously, with the full complement of requirements and such (see (1)). There will always be gaps and it’s your job to identify and minimize them not to pretend that the new technology addresses them.

      1. Gloria MetrickAuthor

         I'm realizing from re-reading my comments that I use the word "you" sometimes to mean the person to which I'm replying, other times to mean, "you, the person doing the project." My apologies. Knowing that, I hope you can figure out my meanings somewhat better.

         1. Gloria MetrickAuthor

            I also realized I should clarify my use of the word "minimize." When you have an internal person who has valuable information but who can't work with the team, when I say "minimize" the person, I mean their involvement with the rest of the team. Overall, keep in-mind that each of your employees has a spot with you for a reason. Treat them with some amount of respect and humanity, while minimizing the damage they can do to your project.

            I'm bringing this specifically up because this very topic came up somewhere, recently.

2. John H. JonesJ

   I like it. I know all about what you are saying. Unfortunately, I have been there, done that and see these things all the time. I speak from experience and age that unfortunately as a young person in the early 90's I did not know all this and had to learn these things the hard way and I suspect others end up doing the same and thus the repeat of history.

   I hate to sound fatalistic but I think we can expect more of the same next year and the year after even if both you and I write blogs non-stop to encourage folks to learn from our own experiences.

   However, here is a good thought that makes this worthwhile... First we both gain personally from the school of hard knocks, we are willing to share information so others benefit and we benefit from their success.

   I say this so that you are not put out by seeing history repeat itself and then give up on the profession. This is just nature at work and all you have to do is watch the nightly news to know that most everything in this world works this way.

3. John H. JonesJ

   Additional...

   You say: "For those people who insist they’re ALWAYS right and NEVER fail"

   My comment: For folks like that I do not spare the sword. When I have had employees like that, I have taken great pleasure in firing them. The person who is always right and everyone is wrong is what I call the classic loser. They can never win, they can never improve because if they are never wrong they have nothing to learn. Thus a dead end street for these folks. Thus, I have no mercy on them.

   Now speaking for myself, I am wrong so often and many people love to correct me so I get the benefit of being able to learn and improve all the time. I have been worng so much in my life that one would think I would be a genious by now. However, that just shows you how stupid I was in the first place :-)

   1. Gloria MetrickAuthor

      John, I think you'll appreciate this, but one of the many things I learned from my father, the smartest person I ever knew, and I learned this quite young:
      The more experience you acquire, the more you realize you don't know.

      The idea behind this is that, the person that claims to know everything is probably the least knowledgeable of the bunch. But, that is often the person with the best sales potential, I've found. That's life. For anyone that falls for that, it's a buyer beware kind of situation.

      But for those who want to learn, some sad news:
      When people start out buying software in this industry, they sometimes think it's boxed software and that it's easy to buy. Depending on their situation, they might have a big failure and learn that that's not true. From there, they might then realize they need to find out what's really going on. So, I had thought that the way to "save" our industry was to try to get everyone together so that the experienced people would "be there" for those that need their help. But the ones that need help don't necessarily know they need any help. Thus, we can write until the cows come home. Does anyone read it? Do they need it? Do they care? I don't have an answer to that. Sometimes, you write to the world, it goes to the ether, sometimes ends up in the bit bucket, other times in someone's head. It's a crapshoot. But we take it because we gamble on the fact that, if you throw enough balls out, someone will eventually hit one of them (finally got in my baseball analogy in time for the minor league season to end).

Comments are closed. This conversation is from 2011. Ask us to remove a comment