Here’s a dirty little secret:
You know those standard operating procedures that took so long to create and that you forced everyone to read? Of course you do! And assuming you have loyal employees who do what they are asked, the procedures were probably read, boring as they may be. That’s the good news. The bad news is that nobody (including the author) remembers exactly what those procedures say.
My first experience working on a software medical device came in 2002. My previous employer, an exciting venture of the dot-com era, failed to provide me the millions of dollars that I expected. Still somewhat fresh out of college, I was hit by reality: Those 100,000 shares of stock weren’t going to be worth anything, and I would continue driving a 1998 Dodge Status for a few more years.
Faced with my first humbling experience in the unemployment line, I was eager to accept the first job that came along, and soon enough I found myself working on a blood bank project performing software quality assurance. I’m not sure what was more humbling to an arrogant young software developer: The unemployment line, or being forced to write test scripts. But it was a job, and being one of thousands of software developers looking for work, I took it.
On day one at my new job I learned something bizarre: The software we wrote would be audited and controlled by a set of standards defined by the FDA. “The FDA,” I asked, “as in The Food and Drug Administration?” Yep. That FDA. I was told to sit in my cubicle and read something called the CFR, focusing specifically on parts 11 and 820. It was long and boring and strange sounding, and I was annoyed. I yawned incessantly as I forced my way through it.
My next task was to read a bunch of Standard Operating Procedures (SOPs). Upon completion of reading an SOP I took a test answering a few simple questions about the SOP. It was graded and signed and placed in a permanent file somewhere as proof that I knew the SOP. At this point I promptly forgot what the SOP said.
My job was simple. I was to review use cases, write test scripts for those use cases (both manual and automated) and run the scripts. When I finished one task I moved on to the next (that task being whatever my boss told me to work on). Soon enough the SOPs I had read during my first few weeks of employment were a distant memory. I had no reason to revisit them.
But perhaps I should have. Remember how I signed a test saying that I read and understood the SOP? About 6 months into my employment, it came time for an internal audit of the project. The purpose of this audit was to perform activities similar to those which might occur during an actual FDA audit for a 510k. I was pulled into a room with the auditors and interrogated.
The auditor asked me the first question, “So Matt, when you do your were, how do you know what to do?”
The question seemed odd, but I responded politely, “Uh, well, I guess I do whatever my boss tells me to do.”
The auditor continued, “No, what I mean is, how do you know what you are supposed to create?”
I began to squirm a bit, “Um, because my boss tells me what to do… I read the use case and requirements, and write the test.”
This was not going well.
The bizarre questioning continued for an uncomfortably long time, until finally the auditor gave up and told me that I could return to my cubicle. For a brief period of time, I was relieved. Then the project manager caught wind of my inarticulate question and answer session.
I was in trouble.