New and Ongoing Project Issues in Laboratory Informatics and Other Systems

In this final newsletter article, as I begin a new full-time position, tomorrow, I wanted to write more about some of the general issues we face on our projects. While these comments are focused on new projects, some of them will remain with the system throughout its lifetime.

I am writing specifically about Laboratory Informatics, but you will find common themes with other types of projects, as well, such as MES, ERP and others.

Implementing New Systems

When you purchase software, it looks like it will be a solution to all your problems. I know this because I have seen the same demos that you have. So, you will then purchase a LIMS, an ELN, an LES and you will think that once you cut that purchase order you are almost finished. Yet, that is barely scratching the surface of the work you will do.

If you are not overwhelmed with all the tasks you need to do, then you are either very early in your process or you are not paying attention.

Recently, I was speaking with a group about planning their ongoing LIMS system maintenance. In asking me, "How do you do this and that and this other thing?," as I responded, they were shocked at how difficult most of the ongoing maintenance tasks are. As they were working to start moving around some of their templates and to plan future maintenance of their templates, they were dismayed to find their work was really just beginning.

In fact, your initial template building is not typically all the work to be done to get your system working. Many groups forget to build-in proper security groups, or workflows, or a variety of other things they find they actually do need before they can make anyone live in their Production system.

Spinning Your Wheels

If you are spinning your wheels on your project, it is probably because you are running into these two issues but do not realize it. I am seriously not kidding, but if you are frustrated at your lack of progress and thinking of firing people, these are probably your real issues:

1. Lack of Business Analysis (BA) and Solution Architecture (SA): One reason groups do not make progress is because they run into a problem and cannot find a way out of it. They might not be able to figure out how to adjust their old process into the new system and make it work, for example. Or, they find a way but whatever they did causes a cascade of other problems or questions and they get stuck, there. You can pretend you are not going to do BA/SA work but that is actually what you WILL be doing. You can pretend all you want but it will not make it go away. Take a course on it if you have to, do a webinar, hire a consultant, but it is serious work and people do only this for a living for this reason.
2. Lack of ongoing and refined prioritization: Most work gets prioritized at a very high level. But there are nuances to this. There is a great deal of work to be done to meet some of these larger blocks of work. Not all the work to meet a priority should really be done, at the beginning. In addition, not all of this is clear until you get further into the building of your templates in your new system. On new project teams, there is often not someone who knows how to manage this type of prioritization. From the higher levels, you usually have to work to educate your project team on this.

Correcting Some Fallacies

There are many fallacies that I hear from people and then they are shocked when their projects cost more and take longer than planned, but it is partly due to misconceptions that I now explain:

• COTS (Commercial Off the Shelf) does not mean "turnkey" and "turnkey" does not mean anything at all. COTS systems are systems you purchase that have purpose-built functionality in them. It does not mean there is no work to do to get them running in your facility. The term "turnkey" is a term that sales people use to get you to buy their system. It has no meaning at all.
• "Hosted" does not mean "Managed Services." When you pay to have your system "hosted" it just means that you are not buying servers and setting them up in your facility. Your servers are just in a different location, basically. But they are still yours to manage. If you do not have a staff to also manage them, make sure you ask to buy the managed services, as well. The "managed services" part is where someone besides you will make sure the work is backed up, security patches are applied, that sort of thing. However, make sure that you do get a list of what that really includes, just to make sure it does mean those items are covered.
• "Paper to Glass" implementations, where you take your paper records and just add them very simply into your new system without reanalyzing your business process does not mean you do no business analysis, at all. You think you have gotten rid of the Business Analyst and Solution Architect by putting your paper system directly into your new software but you really have not done that. Paper systems do not fit into digitized systems so easily. You will still be doing business analysis and solutions architecture even if you refuse to call it that.

One Tip For Completing Your Work

Make sure you run through your entire process as if you were really using your system. Do this with your actual templates using your real user roles. Do this as an end-to-end test. You as a project team have to first do this to see if there are huge gaps but then you have to have your end users do this. They will be able to tell you if you have serious issues in the process.

No time for that, you say? Then, you have no time to implement this system and you should just stop doing it.

A Final Note

I work with quite a few groups where the paper process is entirely bogging-down the people using it. Then, they buy software to try to get rid of some of that paper. Now, they have the growing paper system slowing killing them as well as a new piece of software they are asked to work with.

This is common in any growing company. This is extremely common with the smaller companies who are experiencing quick growth. Many of these companies have the money to spend on the system. Then, it does not get fully implemented and, no matter how much money they threw at it, they will eventually run out of money.

Sadly, too often these systems do not meet their initial promise because of the issues I listed above. There is no good reason this has to happen.

Unfortunately, the people who read newsletters like this one are not always the people pushing these projects forward, either. I could end by saying, "I wish everyone reading would forward this to everyone they know with this type of project!," but those of you who know me already know that I also know that wishes do not solve our problems. With that, I leave you with these thoughts.