Pharma IT: GSPs

Break Down the Wall Between QA and IT

These groups can collaborate by forming cross-functional teams and learning to speak each other'S languages

Many business crises bubble up to the executive suite in slow motion. In many cases, they brew for years before they come to a boil. Unfortunately, by the time they're visible, a great deal of damage may have been done. In the biopharmaceutical industry, we are accustomed to problems caused by blockbuster drugs coming off patent when their hoped-for replacements have failed to navigate Phase 3 clinical trials and reach market. With the cost of a new drug reaching Phase 3 clinical trials nearing $1 billion, such dislocations can cause a severe financial crisis.

But the causes of other crises can be far more subtle and insidious. One of the most difficult to recognize and ameliorate is the organizational disconnect. Nearly everyone in business has experienced at least one, although they often chalk it up to politics: a poor manager, a coworker with personality problems, and so forth. There are certainly plenty of problems like these in every corporation. But an organizational disconnect is not really linked to individual personality conflicts-those manifest later. It usually has its roots in two separate groups that are supposed to work together, but that, because they have different goals, responsibilities, and cultures, often end up on opposite sides of the same issue.

Take, for example, the well-known disconnect between sales and marketing that plagues many companies. Sales people want high quality leads that help them bring in revenue. After all, that'S how they're judged. Marketing wants to generate those leads, but it does so by understanding customer needs, positioning the company'S products and services appropriately, and then branding those offerings in customers' minds. It'S a complex exercise not often appreciated by sales. So it'S not surprising that two groups that should be working in harmony often find themselves in conflict.

Another familiar disconnect that came to a crescendo in the 1990s was between information technology (IT) and other areas of the business. IT was often focused on the latest and greatest technology. Business wanted applications that would give a competitive advantage in the marketplace. IT did not understand the language of business, while-for their part-business managers often failed to understand the complexity and risk inherent in developing game-changing technology. Instead of cooperating to achieve shared goals, the two sides often found themselves at odds, fighting while critical enterprise projects ran far over budget and sometimes failed completely-at a cost of millions.

In recent years, biopharmaceutical firms have found that they, too, confront an organizational disconnect: the one between their quality assurance (QA) and IT teams. As in prior disconnects, the QA and IT departments fail to recognize that, ultimately, they share the same goals. Without a common understanding, the two groups often clash over responsibilities, accountability, and agreement on the extent of regulatory exposure.

Companies sometimes get the bad news about QA and IT when the company fails an inspection, which leads to costly remediation and even drug recalls. But early signs of the QA/IT disconnect can usually be seen in the high cost of IT compared with other industries. Earlier this year, Alinean (an IT investment analytics firm in Orlando, Fla.) published IT spending metrics on 21,000 companies operating in 37 industry sectors. It found that overall IT spending averaged 3.3% of revenue in 2006. Yet a 2004 study of big pharma conducted by Alinean for Baseline magazine found that their IT spending ranged from 4.7% to 5.7% of annual revenue per company-in some cases twice as much as other industries. Numerous other surveys point to the same truth: Pharmaceutical firms spend more than others on IT. The traditional explanation is that IT costs far more in pharma because these firms must comply with Food and Drug Administration (FDA) regulations. But that begs the question: Why can't regulatory compliance be an everyday part of the business? Must it always turn into a fire drill?

Joe and Team Fight Disconnect

Every department-sales, marketing, QA, or IT-has its own unique personality or culture. IT professionals love technology-the newest software, the most powerful or adroit hardware. That'S why they entered the profession. But, while they are excited by hot solutions and systems, they generally tend to be allergic to process and documentation, not to mention the adoption of standard operating procedures.

Consider Joe, an IT professional and team supervisor with three reports, all of whom work in a specialized area. They could be qualifying hardware and validating software in a server consolidation effort, or they might be managing those same infrastructure systems 24/7 once they are released to the corporate data center. Joe and his team are highly educated and speak in a language replete with an alphabet soup of acronyms describing technical protocols. And, because they are often viewed as a cost center, their responsibilities escalate continuously while their budgets remain flat. In short, Joe has to do more and more with less and less. As he and his team are pushed to the breaking point trying to meet project due dates or keeping balky systems running far past their obsolescence, they begin to practice a form of triage that is common in many IT environments.

Often, the first thing to go is good documentation and, with it, adherence to corporate policies and standard operating procedures (S" p. 48). As the documentation grows increasingly cryptic, only Joe and his team really know what it means. If they leave, the company will have little or no institutional knowledge about its IT systems. Or-worse-imagine an FDA inspector reading their materials during an inspection. It'S easy to appreciate the problem with this approach. Joe will have to serve as a translator, and that'S not going to go over well. At the very least, the inspector is likely to cite the biopharm for noncompliance and insist on corrective action (i.e., rework) that must be performed to remediate the situation.

Many companies encourage their IT departments to adopt best practice methodologies like the IT Infrastructure Library (ITIL), CobiT, and Six Sigma or to use Project Management Institute practices to ensure that project rollouts run smoothly. But that doesn't mean professionals like Joe and his team have the know-how or time to implement these practices. Indeed, it'S not surprising if Joe comes to feel that process and documentation are irrelevant as his team rushes from one crisis to another, dousing fires along the way. If your only choice were to let critical systems crash or become a process maven, what would you do?

GSP AFFECTS THE WHOLE BUSINESS

Developing a good systems practice (GSP) requires more than adopting a standard, best-practice approach to managing IT systems (both infrastructure and applications). GSP requires QA and IT to meet with customers on a regular basis to ensure they are meeting agreed service levels and that these are accomplished in a way that maintains compliance. Each quarter, senior and operational QA and IT managers should meet with a sponsoring senior business executive. This meeting should focus on strategy, infrastructure, application needs, capacity planning, consolidation opportunities, and, of course, compliance. The meeting is all-important because it provides IT an opportunity to play a proactive role in supporting the business. GSP enables IT and QA to position themselves as proactive players supporting manage-ment'S business strategy. At its best, GSP reporting provides a high-level overview or executive dashboard to management that enables business executives to collaborate with QA and IT in a way that fundamentally changes the relationship among all three parts of the organization.

Joe'S predicament is all the more bitter because many of his compliance procedures come from two QA departments: one in the business and one in the IT department itself. Both interpret corporate policy into standard operating procedures designed to mitigate regulatory exposure. Why is Joe bitter? Because no one in either QA department really knows how to qualify, validate, or manage systems against a risk-based analysis that identifies critical systems and is comprehensive yet economical. Joe is frustrated because QA often asks him to do things that are unnecessary while ignoring the critical issues needed to comply. So he either has to do both or engage in a running battle until he convinces the powers-to-be that they're missing the point.

QA Battles IT

Of course, every war has two sides and two stories to tell, and the QA/IT disconnect is no different. Like Joe, Judy is a well-educated professional with more than a dozen years of experience managing QA teams throughout the organ-ization-first in manufacturing, then in drug distribution and labeling, and now in IT.

Judy does her best to translate corporate QA policy into something Joe and his team will understand, then trudges into the computer room to confront her longtime nemesis. She knows the drill. Joe will fidget impatiently at the conference room table while she goes over a book of procedures she wants him to follow and document during his server consolidation project.

Business people sometimes get the bad news about QA and IT when the company fails an inspection, which leads to costly remediation and even drug recalls. But early signs of the QA/IT disconnect can usually be seen in the high cost of IT compared to other industries.

She suspects half the steps she'S insisting on may be unnecessary make-work-Joe has explained it to her time and again. But Judy is constrained by two key issues. First, she is unfamiliar with a risk-based analysis that would allow Joe to tailor the company'S QA procedures to address the concerns of FDA inspectors. Second, she does not agree with her counterparts in the business department as to what actually constitutes compliance in the eyes of FDA inspectors.

Judy is IT savvy. She'S adept with Excel and expert in crafting PowerPoint presentations. But if her desktop goes down or her software malfunctions, she'S at a complete loss. And she knows that dealing with desktops is a far cry from managing data centers or consolidating thousands of servers running advanced software. Judy is painfully aware that she and Joe don't share the same language or culture, even though-in the end-she'S confident they share the same goals. They both want to comply with FDA regulations in the most efficient manner possible, they never want to fail an inspection, and they desperately want to escape the combative, crisis-oriented atmosphere to which they seem perpetually doomed.

Compliance Procedures For QA, IT

Biopharms must comply with the FDA'S IT regulations covering electronic records or those governing the validation and qualification of software and hardware systems. They must also comply with the myriad rules that control manufacturing systems and drug marketing, labeling, and distribution, as well as financial systems if they are publicly traded. As a result, a large biopharm can have numerous QA groups spread throughout the organization, each focusing on vastly different issues.

One danger in this scenario is that as people move from one group to another, they begin to apply QA practices inappropriate in their new domain. A common mistake made in many biopharms is to apply manufacturing compliance processes to the governance of IT regulations, even though manufacturing and IT have little in common.

QA "grew up" in manufacturing and helped develop the Good Manufacturing Practice (GMP) guidance documents that ensure quality in drug manufacturing. It was a signal achievement, and it is understandable that QA would want to transfer the same principles to IT operations and projects. But manufacturing and IT are completely different disciplines, particularly in the biopharmaceutical industry where drugs are made in batch mode but IT systems run continuously. Try to merge the two, and you will find much is lost in translation.

DOCUMENTATION AND COMPLIANCE ARE KING

Reliable documentation and record keeping provide the key to avoiding failed inspections. Nearly all IT practitioners admit documentation is not on their list of favorite things to do, no matter how much their managers complain. But QA professionals depend upon it. Sound documentation is the cornerstone of regulatory compliance. Without it, IT professionals are often forced to remediate systems again and again, essentially repeating the same work they could have completed in the first pass.

So how do you get IT practitioners to document their work and systems at a best practice, good systems practice (GSP) level? The best way is to show them, usually through small wins at first, how their workload gradually diminishes as they adopt and repeat GSP and other quality-assured project management processes and procedures. Good records and reliable audit trails will enable them to move on quickly to more interesting challenges.

IT needs its own quality management paradigm. For example, it would be far better to develop an ITIL-based good systems practice to manage IT infrastructure and to adopt and modify Project Management Institute methodologies to manage projects like validation and qualification in FDA-regulated environments. It'S important to note that, while there are several excellent best practice approaches to managing or deploying information technology, virtually none has been optimized to meet FDA regulations. It is high time individual companies-and the biopharm industry as a whole-begin to develop a set of IT best practices designed to meet their unique regulatory and compliance challenges.

Resolve the Disconnect

Did Joe and Judy ever stop bickering and learn to work collaboratively, meeting each other'S needs? Surprisingly, the answer is yes. It wasn't easy for Joe to admit that process, documentation, and standard operating procedures were not only important but also in his best interests. It meant giving up some long-cherished beliefs and behaviors, not to mention the cowboy mentality with which many IT professionals are afflicted: the "Stand back everybody, I'm here to save you, and it'S all black magic" approach to managing IT systems and projects.

Joe realized this approach was unsustainable. He and his team were working ever-longer hours, and as their morale suffered the quality of their work-as measured by indisputable quantitative benchmarks such as systems availability, projects delivered on-time and on budget, and audits passed-was clearly falling.

But that didn't mean Joe had to accept Judy'S over-the-top approach to compliance, with all its make-work that had nothing to do with true compliance. IT systems and projects could be managed with far less work, if only Judy and her organization would listen.

For her part, Judy was more than willing to sit down with Joe and his team, bringing in others as needed to work toward developing common protocols that could address the interests of both sides. Judy even went so far as to recruit a champion, a senior business executive to whom both QA and IT ultimately reported p. 47). He agreed to provide the top-down push to support their grassroots effort. Indeed, this executive had long been concerned about the high budget allocations and diminishing quality of IT, not to mention the fear that someday the company would fail a critical audit and suffer severe financial penalties. He would provide corporate cover and chair quarterly meetings with the QA and IT teams as they developed state-of-the-art compliance and operating procedures that eschewed the nonessential while adopting or developing best practices that saved time and money.

Like any change, the first steps were the most difficult. Joe sometimes still chafed at what he called "all the process talk," and Judy worried the IT cowboy was still lurking behind every corner. But, with weekly meetings, each group began to understand the other and gradually learned to collaborate, ultimately adopting and developing a set of best practices for QA and IT. Judy didn't miss the daily fighting. And Joe and his team learned that, in time, standard operating procedures and sound documentation cut their workloads so much that they could get home most nights. �