Listen to this podcast
Hi everyone, it’s Amber Shao, founder and CEO of AduroSys, a laboratory data management software company. Welcome to AduroSys podcast. I’m joined today by our special guest Gloria Metrick. Gloria is the Principal Consultant at GeoMetrick Enterprises. She has been implementing LIMS for mostly large pharmaceutical companies as well as companies in the consumer goods and energy industry. Gloria has won numerous awards including “Best Laboratory Software Implementation Company - Midwest USA” by GHP Magazine just as one example.
Amber: Today we’re going to talk about a topic that’s always been at the forefront of my mind, presumably on your mind too when it comes to implementing software for a lab. When a project starts, the first thing we discuss is user requirements. It’s important to understand what the lab wants, what the processes are, what features needed in the system and review the requirements in an actual document. Basically every lab software implementation needs a user requirement document.
Gloria: Well, first of all, if you don't write it down, people don't know. There are people who have great memories and even they don't remember every detail about everything you've discussed with requirements. And by writing it down, it gives everybody something to look at. And that's always helpful.
But as far as gathering them goes, the reason it's so important just to gather them at all is it helps clarify what you need. It's going to illuminate what it is you really need so that you can get through all the different types of software you're looking at. So as you're doing this, you can go out and and look at all the systems that are available on the market, and it's so confusing. If you start with your requirements, it's easier to narrow down what it is you're going to be looking at when you go to buy something. Also, in our industry, we commonly work with what's called a COTS system, which means Commercial-Off-The-Shelf. Those systems are different from custom systems where you just say, here's what we want and we'll write it from scratch. But when you're buying a Commercial-Off-The-Shelf system, you're going to want to see what the gaps are between what you really need and what they offer. And you'll be looking at each product to make that determination to see which ones have the fewest gaps. Requirements will help you do that.
So requirements are going to help you understand what you need so that you can ask the right questions as you're going out and try to find systems and eventually implementing them. It's important when you're writing them to to put dates on things because you're going to refine these documents. The dates help people put the changes into context. And actually, as you go out and look at products in the world that you might be buying and implementing. You start to refine some of what you've done. You start to understand what's available, what's not available, and that will change your requirements. Documents a little bit, too. So putting dates on things helps people remember. Well, we went out, we started looking, and then we made these changes. The date just refreshes people's memory.
Amber: If the system is for a regulated lab, the user requirement specification is absolutely required as part of the software validation. So how does this affect the requirement the gathering?
Gloria: So overall, I'm going to I'm going to say that the level of documentation you do for any project is based more on the size of the project than whether it's regulated or not. But that said, when you regulate it, there are specific documents that are required. There might be specific formats you need to meet. So you're going to need to look at what your regulations state in order to determine what you have to do to support the project. So when you're doing requirements for a non regulated project, even though I wouldn't say they look that much different, maybe not different at all. But, when we're talking about, say, the FDA, we're talking about creating a test matrix against requirements. And so there might be some formatting and other types of issues that will cause. So you do need to keep that in mind when you're doing requirements based on some sort of regulation.
Amber: According to research, as many as 70 percent of the software project fail due to poor requirement management. That's an astonishing rate. So let's talk about what we can do to manage the requirements better. First of all, what are the key elements in the user requirement specification?
First of all, you need to document, not details so that you can understand what the users need. And when you do this, you need to write it in a way where those requirements can stand on their own. So if you take a requirement out of that document to send to somebody to say, here's what we're talking about or to a vendor to say, here's a feature we need. If they can't read it all by itself, then it wasn't written properly. And I get a lot of these where people will send me a requirement to and I write back and say, I don't know what this is referring to. So you need to keep that in mind that each requirement has to be able to be read by itself. On the other hand, this is not an as-is or a to-be-processed. This is just meant to ask for features so don't put so many details in that you're talking about the steps that the software should take. That's going to restrict the software you buy or build. But it's just not appropriate for this type of document.
Now, with that said, once you've written everything up, that doesn't mean you're done. You need to come back and look and figure out what's the highest priority to you. You need to go through and rank everything, because not everything might necessarily be in scope. My suggestion is to only use a three point system. Number one is we have to have that. Number two is we really need it. And number three is well we would be nice to have. We probably could live without it. When you get more when you get more granular than that, it just complicates things and creates too many great areas. Now, keep in mind that all documents are living documents. So this document is going to change. I don't mean that you shouldn't do sign off and versioning and document control. But what I mean is that that doesn't mean that you will never change again. So as you go along, it needs to be managed with change management. Even if you're not regulated, you should be using change management to keep track of what you're doing. And once again, if you're not regulated in your small projects, you're going to be doing less different steps for document management.But it's still helpful to do at least a little bit to help people understand what points to the project these changes are being made.
Amber: With that point made, we know requirements are not static. Part of good requirement management is to establish change control. I find it's much easier to start a requirement document, but harder to maintain and update it. Yet updating as the requirements change and expand is absolutely crucial. What is the best way to maintain an update requirement documents.
Gloria: Even with all the fancy software for document management, I tend to find that most projects use Microsoft provision marks or Google Docs suggestion marks. That's one example. And then as people make changes, you can see who has made which comments. People can talk about the comments and what changes they want to make. And, of course, you should be doing document versioning and routing. And when I say that, I don't mean you have to buy a document management system. So if you're a small project, a lot of times people do a saving on the document and put a new version number on it and then they email it to everyone. And that's all they do for versioning, where we get to the really huge projects and they have big software workflow, plans that manage all of this and track it. So it once again depends on the size of the projects. But everybody who needs to see any changes to the document and some of the changes might need discussion, specific people might have to approve some of those. They might need to sign off on it, but always save all versions to reference. And once again, make the change dates obvious so people have a frame of reference. But when you're doing all of this, put timelines on it. So if you are versioning a document and rerouting it, whether it's with e-mail or a document management system, be clear what your day expectations are. Now, I understand that we all get busy and things will come up that might prevent people from finishing the documents and the changes in the timeline you've given. But if you don't give timelines, it means that they don't have a timeline. They can do it, whatever. And that's not sufficient. Your project will go off track if you do that.
Amber: We talked about what goes into the requirement document and how to maintain it. But before starting the actual conversation around the requirement, we also need to get the right stakeholders because more often than not, requirements come from more than one person. What are some of the steps users should take in preparing for a good requirement gathering?
Gloria: A set of requirements is going to have quite a few stakeholders that are involved and not every stakeholder needs to be involved in every part of the requirements document. For example, if you've got people who need statistical information, it's different from the people using the software to run the lab. But you do need to think about all the people who are going to either directly use the system or get some sort of output from the system and make sure that they're included in some way.
When you do this, you need a commitment of their time. Once again, the people who are running the lab with the system need to be give a pretty big commitment of their time. And as we tend to say, if you're doing a LIMS project, you need to commit 100 percent of your time to the LIMS project and one hundred percent of your time to your regular job. So, yes, people will be stretched. But once again, it varies by each person's needs. As far as what they're going to need from the system, and you're going to have people like business analysts, project managers, the end users, managers. As they go through this process, they need to understand how to deal with these Commercial-Off-The-Shelf system projects differently than a custom project. So there might be a learning curve as you're going through requirements as well. But there needs to be a point person on both sides for the requirements. So there needs to be somebody from the software vendor. If there's a software vendor involved at this point, there needs to be somebody on the customer side involved, but there needs to be people that are responsible for pushing the project forward on each side. And in this case, making sure the requirements move to their end point. Before you do this, make sure you do plenty of technical preparation. If you're going to have a place to put your documents, you need to set that up ahead of time. If you're going to be doing any part of this remotely, you need to make sure all your teleconferencing tools are working on everybody's machines, just any sort of technical detail like that for document storage or routing. And when we're talking about regulated projects, some of this might require having validation people to give me some suggestions. So do all of that ahead of time.
Amber: Thank you for discussing the topic around the requirement with me, Gloria.
Gloria: You're welcome, Amber. This is such an important topic for people. I hope that the listeners are getting a lot of information about what sorts of things they can do to get ready for this.