Buddy Holly, and then Linda Ronstadt, sang enthusiastically that “It’s So Easy” (in their case, to fall in love). Lately, leading EDC vendors have been singing the same song about implementing their technologies. Unfortunately, both of these songs are very misleading.

The pitfalls of falling in love I presumably do not need to tell you about. The potential pitfalls in implementing EDC, on the other hand, apparently need some re-iteration. Listening to EDC vendors today, one would conclude that EDC is as easy to adopt as a mildly complex desktop tool like MS Project¢â. This is the worst kind of déjà vu, reminding me of the mid-1990’s, when EDC technology and vendor support was very immature, and yet EDC vendors would routinely tell their prospective customers that EDC was “simply an electronic CRF”, that their software interface was “intuitive”, that study startup would accelerate, and that study closeout would be “overnight”. The failure of EDC in the 1990’s to deliver these features, at least as perceived by pharma customers, was a huge contributor to the derailment of EDC progress in that decade. It would be a great disservice to pharma clinical development if the EDC train derailed again.

Yes a lot has happened in the past decade. Technology and vendors are stronger. Sponsors know what the abbreviation EDC means, and are modestly more aware of what EDC implies. But the fundamental change which EDC triggers, which indeed can and should extend far beyond making the CRF computerized, is only recently being realized, conceptualized, and the implications understood.

I am not sure why “easy EDC” is becoming such a popular marketing pitch. Are the vendors frustrated at the pace of EDC adoption? Are their investors impatient? This would be ironic, since EDC adoption is finally taking off. Do they think this will overcome a major selling obstacle? This too would be ironic, because misleading the customer is the best way to create a selling obstacle, as the ¡®90s proved.

Clearly some of the very small EDC vendors are using this approach to try and break into the market, differentiate themselves from more capable vendors, and try to appeal to biopharmas with low budget or low tolerance for complex reality. This is understandable as a time-honored marketing tactic. What is more distressing is to see market leaders — capable vendors working on a large scale — who now want to “move to the next level” by assuring customers EDC is not as hard as they may think.

When vendors say that implementing EDC can or should be easy, they are thinking about it from their own perspective, naturally. So they would say that these things should not be complicated:

-learning the tool (by which they mean training the sites and monitors in the software interface)

-following a checklist of technical steps to set up a study, or derive an report

-setting some software switches (yes, query writing has gotten easier)

-writing a SAS export routine

-basic aspects of how staff roles change, or that the time for study startup has to be planned more carefully.

These are all good things to learn and maybe one can learn them quickly.

But implementing EDC is much more about things that no seminar can “transfer knowledge” about:

-governance of the EDC change effort (who’s in charge, who has the money, how conflicting interests among CDM, clinical operations, IT and others get accommodated, etc.)

-the business model and budgeting (there are so many ways to “buy” or “rent” EDC technology and support services, including these days “EDC monitors”, plus there is the question of who should be paying: is this coming from the study budget, is it a capital expense, etc.)

-support issues across the board, for the site, monitor, patient (in the case of ePRO), IT, study manager, and more

-examining the cleaning processes in your company and long-entrenched roles (this is so diverse than no standard seminar can begin to address it specifically)

-raising “site consciousness” (responsiveness to site needs, workflow, usability) which is nearly non-existent in most companies

-”change management” in the classic sense of attitude changes and acceptance of new roles

-and coping with the tough personnel problems that come from change which is not (never will be) universally embraced.

Let’s look at just one example in more detail, an example that points the diversity and detail that has to be coped with in implementing EDC – data cleaning choices. Even though we are all in the same business, and trials are nominally the same from a data processing standpoint, sponsors vary enormously in their policies and approaches to data cleaning. For instance, sponsors vary by how they define the role of the monitor in data cleaning: it runs the gamut from on-site data scrubber to completely hands off. Sponsors using EDC, therefore, vary accordingly in what they allow their monitors to do with the EDC software – some take advantage of the ability of monitors to review data online before a site visit, while others prohibit it! Sponsors vary notoriously in their source data verification policies (100% of datapoints, or a subset). From trial to trial, even within the same sponsor, teams have different styles of querying the data, from complex queries to simple. And teams differ in who queries the data (data managers, monitors, statisticians, physicians) and when (early and often, or late in the game). Sponsors also vary widely in how standards (for CRF design, data structures, common questions) are applied – by whom, how rigorously, and why.

With all this variation, it is not enough for any third party to say either “this is the way we do these things with our tool” or “decide all that later, let’s get started”. For a study team who is conscientious, or rigorous, or conservative (pick your adjective), this drive for simplicity is misleading and sure to ultimately generate disappointment.

It’s not that there is anything wrong with vendor-driven quickie seminars about EDC-induced process change. Just getting vendors to admit there is process change around EDC adoption, and that there is more for sponsors to consider than purchasing software, is definitely progress. The value added in such seminars, assuming quality content, is unquestionable. It is the assertion of sufficiency, that all the issues will be covered, that EDC has been “made too complicated”, which is so dangerous, and simply inaccurate.

Why does this matter? Why can’t EDC be simple? The answer has at least two levels:

– The Clinical Development process overall is not simple now. Perhaps it could be, and EDC will make it simpler, but you have to get from here to there, and understand the path. Ample experience at sponsors over the past decade shows us that teams and staff will stumble, duplicate work, maintain unnecessary work, and even unwittingly resista change without careful re-design of roles and processes, participation of those needing to change, agreement on how/when to change, and some trial and error.

– Secondly, over-simplification of EDC matters because without careful preparation, the resulting unnecessary inefficiencies, delays (or lack of time compression), and other expected benefits will result in widespread disappointment at the failure to deliver the promised impact (speed, reduced resources, higher quality with less effort, etc.). And this is deadly. Because biopharmas cannot afford to sit out another decade without widespread clinical development innovation, of which EDC is only one piece among many.

It’s easy to fall in love, and it’s easy to believe that putting a CRF page up on a computer screen should make clinical trials equally simple. Some day it will be, but it won’t be tomorrow. Saying it doesn’t make it so, only hard work does.

There can be over a thousand people in a big pharma’s Clinical Development department, and yet the most important people in the process are not on our payroll. It can take 8 years to bring a drug through clinical trials, and yet the most important events in the timeline are not in our control. We may have hundreds of offices in dozens of office buildings, and yet the most important office is not on our campus.

The missing pieces in each case are our Sites, without whom no clinical research is possible. Some biopharma research departments with an inkling of this problem have cited “Site satisfaction” as a strategic goal by. But in fact, almost all sponsors find a way to consistently aggravate our critical partners – to bite the hand that feeds us the information we cannot live without. One particular way we aggravate Sites is by demanding they use underperforming technologies which we are ill-prepared to support.

While we know that a happy Site, like a happy employee, is more likely to recruit faster and more correctly, record data more accurately and on time, and think more favorably about the trial Sponsor, most sponsors do not consider the Site as a seamless extension of the clinical trial workflow. If we did, we would be involving them in each step of the process we follow in evaluating, selecting, designing, implementing and supporting site-based technology tools.

It’s not about clever

What do we give our Sites of more lasting memory that our logo’ed paperweights at the Investigator Meeting? We give them mistrust and hostile contracting. We try to be clever in our contracting and our patient volunteer advertising. Meanwhile we take the Sites’ nurses and phone lines away. We pressure them to perform, without the support to enable them to succeed. We make them use our flawed software tools, and fail to train them properly. In sum, we make them make up for our poor management. We dwell on the negative (chronic under-enrollment and dirty data) without regard to how what we do as sponsors directly affects Site performance.

It’s about trial management excellence
Trial management excellence includes a number of important components, including building close professional relationships with principal investigators, communicating our plan and delivering on what we promised, creating a service orientation toward our Sites, and ensuring the tools that support these actions (EDC, CTMS, IVRS, ePRO, etc.) are helpful and not burdensome. Let’s look at several of these items and how technology can and cannot support Site Satisfaction.

Relate Locally
While we often spend long hours, appropriately so, trying to improve our ability to manage globally, what we mostly fail to do is relate to our Sites locally – to build an effective and knowledgeable personal relationship. Several biopharmas are beginning to speak about “territory management” as a task of their regional monitoring networks. This term, borrowed from salesforce management, represents an excellent concept: regional monitors should get to know the physician pool in their region, to be proactive in identifying potential future investigators. Even if they get to know specialists in areas they don’t “need” yet, you never know when your company will enter that therapeutic area, and these physicians can refer them to others they can use now.

Another term borrowed from salesforce management is more unfortunate: “IRM” (Investigator Relationship Management). This phrase is adapted from “CRM” (Customer Relationship Management) and refers as much to technology used for this purpose as it does to a strategic operational concept. While the metaphor of IRM to CRM is superficially useful, it is another clever idea taken too much to heart. The key to “IRM” is an intelligent human connection, not a new database tool. As soon as technology enters the picture (and of course there is a place for it), the tendency is to rely on the tool and forget the human connection. IRM, as a technology, in practice ends up objectifying the Site and further mechanizing what should be a personal relationship. To be effective, IRM technology needs to be subservient, even invisible, to the effort of sponsors to build effective, creative Site relationships.

Professionally Manage the Trial
Trial management skills across the industry are modest at best. One key to Site Satisfaction is to demonstrate professionalism in the timeliness of achieving milestones and responding to issues. Another is to minimize those protocol amendments! Both of these objectives can be helped or hurt by technology, depending on how we use it.

A CTMS (Clinical Trial Management System) can be used to greatly assist the trial manager in understanding trial progress and problems, and in timely communication with the Site. But many “CTMS” applications are focused completely inward, on what the biopharma enterprise needs, without including the Site’s needs in the equation. A CTMS, or other application, which provides immediate and direct access by Site personnel to critical trial conduct data, and which is easy for the Site to use to supply information to the sponsor, is truly enabling of trial management excellence.

Similarly, the best goodwill created between Site and sponsor, over time, by repeated use of EDC, is consistently undermined by the annoyance of repeated protocol amendments. These changes have always been irritating to Sites, expensive to sponsors, and often avoidable. When using EDC, the amendment is additionally annoying. This is how good trial practice is directly related to the Site’s perception of the technology they are required to use.

Provide Tools that Work
Too often, we inflict, rather than empower, our Sites with technology tools. We select these tools totally without regard or consultation with Sites, choose vendors because of price or through suboptimal selection processes, and then send the software out to the Sites and good luck to ¡®em. Clinical Operations staff (those directly interacting with our Sites) also often feel as if they are a victim of information technology, something inflicted on them from the CDM or IT department, or from an individual executive who leaves the implementation to others. In both cases, the fault lies in software tools being driven by those furthest away from the point of use (Sites and monitors). Reverse that fact and application quality (and Site satisfaction) will rise.

All parties – sponsor side and Site side – also can be victims of the software vendors. Despite the fact that it is 2005 and the third-party clinical research software industry is now 20 years old, we still find some vendors who are quite unprepared for the responsibilities of supporting clinical research, including providing knowledgeable and timely support, software that is predictable and reliable, tools that provide some benefit for the lowest level user, and applications that are scalable to our ever-expanding trial load and complexity.

Create a Service Orientation
A fourth key element of trial management excellence, and thereby Site Satisfaction, is for Clinical Operations and Data Management groups to have a service mentality toward Sites. We need to think of the Site as our customer, someone we serve instead of someone we berate. This single, yet dramatic change of thought, would be a remarkable exercise for our organizations to go through. What we have decided is important or critical in our daily work would change dramatically. A customer service orientation, for instance, would never allow a data cleaning process that helped our backoffice offshore entry clerks, but interfered with a study coordinator trying to get through her clinic day.

These shortcomings in how we employ technology, rather than the functions and features of the software, are the key to trial management excellence, and to satisfying instead of aggravating our Sites. Sites are critical to the success of our trials, but we treat them like vendors instead of scientific partners. While there are many poor Sites, there are an equal proportion of poor sponsor trial managers. Trial management excellence, and the properly designed and supported technology tools to support excellence, will ensure we don’t go hungry biting the hands that feed us mission-critical patient experience.

Ronald S. Waife is President of Waife & Associates, Inc. and can be reached at ronwaife@waife.com or +1 (781) 449-7032.

Judging from the inquiries we have received in the past year, biopharma companies both experienced and naïve are looking beyond traditional clinical data management systems (CDMS), or even CDMS plus electronic data capture (EDC). They are looking to something new, which may be a new dawn over the mountaintops of data processing in clinical trials. Or, it may look like Wyoming after the strip miners have left.

I am talking about the much misunderstood phrase, “clinical data warehousing” (CDW). And like any other clinical IT initiative, CDW has been hijacked by technologists, and/or a lack of follow-through from the sincere business–side visionaries who leave the job of implementing innovation to others.

To briefly set the scene, we know that CDMS have been used to store clinical trial data for several decades now. Although this was the first area in clinical development to be widely computerized, many other uses of computers have since developed, and thus we have a plethora of individual, or “silo’ed” applications: trials management systems, EDC, electronic patient diaries, document management systems, and more. This multiplex of applications has also been a common development in other industries and even other sectors of biopharma companies, and one solution in recent years to try and pull these threads together is to build a common place to store the data generated by these applications – a “warehouse”.

It’s not the warehouse, it’s what you get out of it
Casting this change in terms of a “warehouse” places the technical emphasis on data storage, which while technically important, is totally subservient to what you need the data for, to how you are going to use it. Yet most people start with designing the shelf space and forgetting about the aisles and the doors needed to get the data out, and more so, where the data is going to be sent and why. This is not to say that the warehouse architecture question is trivial, but rather than it is premature until a dozen other questions have been answered by the business first.

Getting the data out is often called “data mining”, which mixes the metaphor immediately, and gives me permission to mix the metaphors for the rest of this column! Tools (or building blocks) for data warehousing and mining have been around for years, and successful data mining in healthcare has been used for a decade in health claims analysis and even pharma marketing. The key point is that mining data does not have to happen in a warehouse; indeed successful (i.e., meeting a business need) mining can be done on the databases you have right now, even those scattered about the enterprise.

You have to ask why
So the first question we ask our clients inquiring about a CDW is “why?”. It should be the first question asked of every new process or technology change, and yet at least half the time it is never asked: instead we start from a new technology or process fad, and look around for a reason for it much later. Even in this column, instead of talking about all the possibilities of CDW (which we will later on), I want to talk about why one would do warehousing in clinical development first.

Exploring this question with clients has often revealed very limited perspectives on what the felt need really is:
“I wish I had better reports from my clinical data.”
“I wish SAS export was easier, or earlier, or more direct, in the trial flow.”
“I wish all my documents were in one place.”
“Everybody else is doing it so I think maybe we should too.”
In other words, people are very much in need of better reporting, which may mean some data mining, but is unlikely to mean something requiring the sophistication of a data warehousing effort.

As I write this column, the scandal surrounding the FBI’s huge new software tool that doesn’t work is making the news. The following quote from an FBI spokesman sums up the data warehousing dilemma beautifully:
“The Investigative Data Warehouse, while perhaps a useful tool, does not manage case workflow and does not substitute for an effective case management system. Consequently, the FBI continues to lack critical tools necessary to maximize the performance of both its criminal investigative and national security missions¡¦”
You need to change only a couple of words and this could be some pharma’s sad CDW story three years from now unless it’s done right and done well.

Dawn on the Mountaintop
So now let’s look at why a clinical data warehouse may be a terrific idea for biopharmas if done correctly. We have proposed for many years that acquiring applications in individual actions, without regard to each other, may maximize the value to a very narrow function but is costly to the enterprise and highly inefficient. In addition, the dominance of CDMS orientation has a) held back EDC adoption for years, b) distracted clinical development personnel from the importance of trial management also, rather than only data management, c) and has kept an entire profession (data managers) from seeing above the trees.

For any biopharma examining how they do data management in 2005 (and many companies are), it is very appropriate to be considering an “EDC + repository” strategy rather than a traditional CDMS. The extensive traditional CDMS functions have little or no usefulness when an effective EDC “front end” is applied (assuming the EDC tool is working well). But how should the “back end” repository be architected, what should we expect from it, and what else can it do?

Some of the repository architecture guidelines come from work being done by CDISC and is also influenced by regulatory compliance issues, the guidelines for which are also in flux. But staying above the “data model” level for the moment, what some kind of repository does is begin to enable the “write once, ready many” paradigm that technologists have preached (and some industries have come close to) for many years. In clinical research, this means significant efficiencies on both the trial management side (how many times do you enter the investigator’s address today, and how do you know it is correct?) and the data integration side (getting central lab data, ePRO data, drug safety and CRF data in a location, or reportable, so that an integrated view is available for the human mind to collate). Once you start thinking this way, the best benefit of CDW is to break down the acronym silos of CDMS, CTMS, EDMS, EDC, EPD, IVRS, AES.

The Path to the View
So if we want to get the mountaintop, which path should we take? Some CDMS vendors will say they can offer it all to you, so “stay within our world”. Other choices may be more productive sooner, but are by definition innovative and therefore riskier — risky not being a usually appealing word to pharma operations. As we used to preach about EDC for years, however, if you wait until it isn’t risky any more, you will be far behind your rivals. We see this now in EDC, with earlier adopters flying ahead of those who waited (although some early adopters are no farther along than they were in the mid 90’s). Finding the sweet spot between “bleeding edge” and “failing follower” is always the challenge.

One thing is clear: the path begins with understanding why, before any vendor walks in the door, before the project itself gets the wrong name. Maybe what you really need is simply better reporting from the databases you already have. Maybe you need a more innovative approach to analysis. And just maybe, you need (and almost certainly can benefit from) a new approach to clinical data processing.

For clinical operations folks, there are two important implications to prepare for:

Changes like this will be a new distraction to you and your colleagues

You need to be proactive and get involved in these decisions: don’t let Informatics or CDM do this in a vacuum, which continues to happen way too often.
A new day will dawn when data processing is re-invented and the silos torn down. Our approach so far seems to be to build more buildings on the farm instead, with only a steam shovel available to tear the sides off when we need to get something out. We need to avoid strip mining the future by first considering the reasons behind business change.

In keeping with this month’s issue on Best Practices in clinical trial conduct, the editors asked me to reflect on Best Practices in clinical development process, as seen in real life situations. Being somewhat of a non-believer in Best Practices (who’s to say any practice is “best”?, and why is someone else’s “best” necessarily best for you?), I did conclude that I could cite a number of “pretty good” process examples which are worthy of emulating by other companies. All of the following are actual examples; the company identities have been omitted to protect their competitive advantage. If we were giving Best Process Practices Awards this year, here are the winners.

Merging Boldly

Mergers are rampant in our industry, amongst companies large and small, and as far as most investors can tell, they run smoothly, even if they don’t produce dramatic improvement in the flow of new drugs. But as anyone who has been inside a merger knows, the operational impact can be devastating, and at the very least, highly disruptive. Merger failures include poor understanding of where the strengths lie in the new organization, missing the opportunity to make real operational improvements, trying to keep people happy without regard to business effectiveness, keeping unproductive functions alive, and so on.

One company took a different approach. They decided to act swiftly to analyze strengths and weaknesses in the merged operations, and where necessary, create a new organization chart with re-articulated roles and responsibilities before any final management changes were announced. The analysis was rapid but intense, and informed with extra-company experience. Major re-assignments were made, even of line managers, and in some cases new units were formed for tasks the new company would be much in need of. Instead of the usual post-merger behavior, where a company just looks at the management players and leaves the rest up to them, often resulting in years of slow, distracting upheaval, this company sought to get as much change as possible accomplished quickly. And not change for change’s sake, but change that was incisive and potentially transforming. An excellent approach to exploit the operational opportunity mergers present.

Investing in Change Governance

We have written before how critical it is to govern change effectively – that there must be empowered leadership, with money and executive backing, and an infrastructure to handle the myriad of tasks necessary to make process improvement successful. Too often in clinical development, we retreat to leaderless teams or matrixed relationships; major change is cast as an “initiative,” which leaves individuals and managers free to choose whether they will commit. And without resources, both human and monetary, even strong visionaries cannot succeed.

A large pharma introducing a major change in clinical development made a significant investment in change governance this year. They wanted to move quickly but knew this change was mission-critical and high stakes. They created a new department, which would operate globally to manage this multi-year process transition. It is a permanent unit, with permanent members formally transferred in. Former line operations staff are now fulltime change agents. Top executives are fully informed and committed to its success. The department is fully budgeted and is resourcing ahead of the curve of need, instead of behind – in itself a major accomplishment at most companies. They have sought to staff all the roles necessary for change management, from study team mentors to investigative site trainers, and they expect to achieve successful, compliant process change in much less time than most of their big pharma peers. The investment in governance is paying off.

Learning from Mistakes, Sincerely and Concretely

Many clinical development groups routinely talk about “lessons learned”; they properly seek to understand what went right or wrong with a project or particular trial, so they can avoid repeating past mistakes and remember to do again what they did right. Unfortunately, such efforts are usually little more than one long meeting, a flipchart pad full of observations, and a bunch of action items that individuals are supposed to remember for next time. Too often, the “learning” dies on the spot. There is no formal means of documenting the discussion, no one keeping track of actions taken, and no protection from that learning just walking out the door in the head of a departing employee. Worse, the learning is often incomplete: messengers of bad news are afraid of being shot, or the attempt to seek information may not be cast widely enough. Equally common is that the lessons are articulated too vaguely, in words and opinions too familiar to be truly heard or acted upon.

One biopharma with many lessons from a just-concluded pivotal trial decided that learning as usual was not enough. Instead they used a formal exercise designed to comprehensively analyze and document what they had learned about this trial’s conduct. They looked for “root causes” of problems they encountered, which enabled them to identify broad but meaningful themes whose improvement will have wide impact on future trial conduct. These root causes are actionable, not theoretical, and provide a foundation for a diverse set of clinical operations process improvement steps.

Measuring the Vital Few

We have written many times that measuring our performance can be so useful to companies understanding where and how to devote process change energies. As we have described, those companies who get “metrics religion” often go into overdrive, and end up with a vast array of data, and pages of reports, which managers ignore and staff resent. Another flaw in most companies metrics programs is a focus only on time intervals (last patient visit to database lock, for example), which are determined by too many contributing variables so as to make correct conclusions impossible to derive.

An international biopharma has demonstrated that in one area of their operation, clinical data management, they can apply metrics for resource planning, performance monitoring and technology assessment without falling into either of these traps. By focusing on the “vital few” metrics which are both reasonable to collect and have operational significance to know, they have been able to minimize the practical burden of performance data collection while increasing the usefulness of the results. As importantly, they are focusing on the units of work which best describe operations, rather than abstract time intervals. Using units of work translates much more accurately into management decision-making.

Knowing It’s Never Too Soon for Compliance

Emerging biopharmas who are just beginning to see their first drug candidate approach Phase III usually continue the pattern of operations which got them there: use a lot of CROs, focus on the science, and ignore clinical development or postmarketing infrastructure. They follow the same philosophy they followed through discovery: I’ll buy that next piece of equipment or hire that next person I need the day I need it and not a moment sooner. That strategy can work in discovery, but having the organizational infrastructure for a successful submission and postapproval support is not something one can buy in a moment – it takes time, anticipation, skill and practice

Just such an emerging biopharma has demonstrated visionary practice in its small clinical group as the company gets close to submission. They have instituted a broad and deep review of their clinical SOPs and fleshed them out in the many areas where they were thin. These SOPs also serve to ensure that their clinical program is robust right now, as they expand the scope of their candidate’s indications, instead of continuing to rely on outsiders’ standards. And they have also recognized the importance of creating a legitimate pharmacovigilance function, with the appropriate tools, so that they are prepared to handle internally the safety monitoring needs an approved drug will require. In both cases – SOPs and pharmacovigilance – the company was able to internalize a compliant infrastructure at modest cost with many long-term benefits.

Using the Right Reasons for Vendor Selection

My last example for the year’s Pretty Good Practices is a company who has gone about technology vendor selection more efficiently than most companies do, because they focused on the right reasons for choice. Instead of spending months of intense effort to develop, define and document the functional requirements for a clinical IT software application (i.e., how should the commands appear on tab 12), they recognized that this would be reinventing the wheel. Clinical IT applications are so well defined in purpose and use that developing functional requirements for them de novo is akin to specifying how a word processor should work.

This company instead focused on business requirements: that is, what did the company need from the software and its vendor, rather than how the software should look or act. They focused on the imperatives they were facing, the skills of their staff, and the financial and time constraints of their particular development program at this point in time and the foreseeable future. These characteristics are not the same among all biopharmas; indeed they can vary greatly. And having identified what was important to them, they found specific, meaningful differences amongst the products and vendors that a functional review would never have revealed.

Four Common Qualities

There are common elements in these Pretty Good Practices: boldness, speed, simplicity, honesty. These are qualities sorely lacking in most pharmaceutical development operations. When you see them, good things are likely to follow. Whether or not the specifics of these stories apply to your company at this moment in time, these qualities will always serve you well.

For many years now, it has been fashionable to work on corporate processes by encouraging a “customer-vendor” relationship between departments. I have probably been as guilty of this as other consultants have been. In listening to the problems facing clinical development departments recently, however, I have come to realize that this concept is either mis-applied, mis-understood, or simply a mistake. Unless great discipline is exerted on all sides, “customers” are poorly served and “vendors” are exploited.

You are My Customer, I Suppose
The original concept of treating each other like we are each other’s customers is drawn from many good intentions. And it converges from many process improvement philosophies and techniques. At my company, we use a “voice of the customer” technique, for instance, which emphasizes this style of thinking. TQM (Total Quality Management) teachings of various flavors use this terminology. Process Mapping – the visualization of complex workflows – is sometimes presented in this fashion: Who is your customer? Whose customer are you?

In many ways, talking about each other as customers is not unlike the Golden Rule: treat your organizational colleagues the way you would want to be treated. Using terms like “customer,” “vendor,” and “service” puts a warmer face to “inputs/outputs,” or talking about “deliverables”.

The customer orientation as a corporate process concept was long overdue when it first appeared. Most corporations – pharmaceutical companies among them – desperately needed to overcome the detrimental effects of “silos” (departments with their blinders on), eliminate the pointing fingers of blame, and get people to see the interdependencies they share in a complex organization.

Examples of such poor relationships at pharmaceutical companies were (and still are) legion: between clinical operations and clinical data management, biostatistics and medical affairs; regulatory affairs and product marketing; investigative sites and monitors (CRAs); chemists and pharmacologists; informatics and everybody; and so on.

But there are problems with this kind of language and way of teaching process improvement. For instance, if everyone is everybody’s else’s customer, is anybody “making” anything or are we all just “buyers”, expecting to be served? In fact, not everyone is a customer of someone else. Sometimes, for instance, people are other people’s bosses. Sure, you can treat your boss as a customer, but it may be more important to follow her leadership rather than think about delivering her a service. Sometimes our colleagues are simply sources of money, or information – neither customer nor vendor. And sometimes, we have nothing to do with each other, but if the mantra of customer-vendor is too ubiquitous, the corporation may be insisting that these folks develop a time-wasting connection in the blind pursuit of popular jargon.

Happy Customers, Missing the Boat
More importantly, there are two fatal flaws in the everyone-is-a-customer approach. First, even given the legitimacy of the concept, the true “customer” of our work may in fact be at a much higher level than who we are trained to serve. For instance, the customer who is worthy of that name may not be the next person in the handoff chain, but rather the Clinical Development function as a whole, or your biopharmaceutical corporation, or the regulatory agencies, or even the patients you hope to help. Unfortunately, the customer focus approach almost exclusively encourages a pragmatic, heads-down, make-the-next-guy-happy mentality. This may not actually help your organization at all, if the focus should be at a much higher plane.

Secondly, there is the mis-use of the concept of “service”. If we have customers, it is assumed that we are supposed to “serve” them. This is where the customer concept can get really deadly. When we start to think about “providing a service,” and then turn this into “being of service” to our customers, if we are not careful we can end up being “subservient”. These words all sound pretty similar, but subservience means being a servant; it implies that the customer is better than we are, or more importantly, subservience means the customer’s needs are more urgent than ours. It doesn’t have to be this way, but when we overlay the customer focus superficially and without diligent rigor on age-old interdepartmental rivalries, that’s what we end up with.

Let’s look at some clinical research examples:

Clinical Data Management takes the customer focus philosophy to heart and concentrates on serving the clinical study manager. In doing so, they are forced to choose between losing their carefully built-up standards, structures and efficiency, for the sake of serving the study team with flexibility.

Monitors focus on sites (their customers) to such an extent that they allow consistently poor site performance in enrollment and data quality for the sake of “satisfying” that Key Opinion Leader.

Clinical operations is intimidated by their site ¡®customers’ into paying them more to use EDC (electronic data capture) — a tool which will in fact lower site workload if everyone sticks it out to the end (and uses the right tool to begin with, with the correct processes).

Biostatisticians give their physician customers in Medical Affairs everything they ask for, despite what this does to the timeline, or despite the fact that the data may not yet be properly cleaned or of sufficient volume, or despite the fact that the questions the physicians are chasing are taking the company’s eye off the ball.

Clinical operations tries “serving” CDM, and in trying to meet CDM’s stringent view of data cleaning, ends up with an inefficient monitoring schedule and that classically unnecessary task: 100% SDV (source data verification).
In fact, having customers and serving them are not inextricably linked. It is possible to be customer-focused and yet not be subservient to your customers. “The customer is always right” does not mean that the vendor is always wrong.

Customers as Equals
The other way of looking at this, at preserving the idea of “customer” without the idea of “subservience,” is to see each other as equals, not servants one to another. After all, if everybody is somebody’s customer, we are equal. And equality brings several characteristics into play which are very healthy for a corporation: mutual respect, boundaries, expectations with limits, and a common multilateral goal, not a linear production line goal. It allows the Clinical Development department to focus above the level of the next handoff, and to focus instead on the plan, the submission or the patient. And it ensures that each profession can determine which of its values are corporate-critical, and hold onto them, while, yes, “serving” the needs of other professions within clinical research.

How do we get to be equals? Good will and strong leadership are certainly essential, but human behavior and entrenched practices often require a little extra help to change. Fortunately there is a well-established concept in this regard: the Service Level Agreement (SLA).

SLAs are an invention of our service economy, and while they have been used in many industries for many years, the concept is not widely applied yet in pharmaceutical companies, especially in Clinical Development. An SLA looks very much like a contract. It spells out responsibilities, timelines, expectations, deliverables, authority, change procedures and problem resolution. As such, it documents what one may have documented in a Process Mapping exercise or similar, but does so in the language that societies have developed over centuries to bind people to a common purpose.

Initially, people often react badly to this concept. Why do we need a contract when we have worked together for so long? Why don’t you trust me/like me anymore? Spiteful behavior can ensue: “well, if you’re going to write that down, I’m going to write down this!“ “If you want this done on time, how about you doing this for me on time!” And as petulant as these sound, this is exactly the point. The SLA becomes a tool to generate an open dialogue that, without it, simmers below the service. The SLA’s formality uncovers flaws, resentments, or missed expectations that were never articulated otherwise.

In the end, by going through this process, you may not need the formal document – the process of trying to write one may be therapeutic enough. But because we are so increasingly interdependent across Clinical Development, and indeed across all pharmaceutical company departments, the documentation of how that interdependency will be managed to the corporate good, and to the successful treatment of patients, may be necessary, at least for a few years, until old habits die off, and mutual respect and understanding become second nature.

When your waiter tells you “I will be your server tonight,” he or she represents in fact a range of products and services, a range of outputs — the chef’s creativity, the cook’s execution, even the delivery truck that brought the raw materials. And you have your responsibilities as well – to arrive at the restaurant on time, to know what you like, to treat the staff well. The delicate flavors, the perfect ambience, a lovely wine are all the result of a combination of lots of people providing you a terrific meal, plus your ability to be ready to enjoy it. They are not your servants, and you are not burdens for them to bear. And as equals, server and served, customers all, we can go home well satisfied with a meal, and a job, well done.