“Begin with the end in mind” is one of those classic business phrases which is no less valuable for the number of times it is ignored. Clinical research sponsors are guilty of often fatal forgetfulness of this key concept when planning the development, implementation, and use of new software applications or major organizational change.
Clinical research sponsors generally start an organizational change or a software acquisition not with the end results firmly planted in their minds, but with some “stimulus” having been applied to their backsides: a department is complaining that everybody else gets new tools except them; the competition changed its outsourcing model so the firm’s executives think it should too; someone met a smooth-talking salesperson on an airplane; a vendor just announced an upgrade and it won’t support the old version anymore; the firm just hired a new vice president and she prefers vendor “X” over vendor “Y.” While some or all of these situations may justify change, they do not in themselves sufficiently define the “why” and “what.”
Starting Isn’t the Hard Part
Sponsors may also start from some business trigger which gives them the illusion that the end is in mind: we need to save headcount, so let’s use electronic data capture (EDC); or we’re frustrated with having multiple overlapping and out-of-date investigator databases, so let’s buy a clinical trial management system (CTMS); we just acquired Teeny Biotech and we don’t have anyone in-house in its therapeutic area, or our new translational medicine executive says we’re going to have a flood of pharmacogenomics data coming in, so let’s get one of those “data warehouses.”
What’s missing from these situations is sufficient consideration by the company of what the strategic benefits and daily operational impacts will be, what the software’s users will have to change to use it properly, and overall what will the benefit be two years from now? What is the tie-in between the initial impetus—the needle in the backside or the business trigger—and the actual output the change will provide?
This disconnect is particularly critical in enterprise software projects or major business acquisitions, because we all know that the cost in money, time, headcount, and disruption will be high. The benefit therefore must be high as well, or the cost reduced, to be in line with the diminished (and realistic) results. The good news is that analyzing a potential project’s end-user benefit compared to the initial impetus need not be fatally time-consuming, which is the usual reaction to the suggestion; however, it can save large amounts of wasted time and money.
We should recognize that it is very easy to fall into the disconnect trap. For instance, let’s consider the situation where clinical operations becomes frustrated about the multiple investigator databases being used. The complaint is forwarded to the information technology department (or worse, a naïf goes to a booth at a trade show), and the answer comes back: there is no “investigator database fixer” product out there, but there are these CTMS packages and boy, they do everything. Before you know it, you are installing a multimillion-dollar application over multiple years, you’ve doubled the amount of training everyone has to go through, and you have all this rich functionality, and no one can or wants to use it because it’s not relevant—neither to the original trigger or to the actual user circumstances.
I would suggest that even a good understanding of how the end-user works, and what he or she needs, is not sufficient in today’s business environment. We have fewer and fewer in-house staff, we are narrowing our “distinctive competencies,” we have uncertain economic and reimbursement conditions, and we have unrelenting competitive pressures. All of this mitigates against expensive multiyear infrastructure projects unless we do more to predict and understand the future end-user business need. What should the future identity, purpose, and constitution of our business look like, and therefore, what changes and tools do we need to get there?
Even for projects where the pain and the solution appear more clear and pragmatic, we are usually missing a robust and detailed visualization of how a tool will be used, and without this, we will misconfigure and misspend our time and money. For instance, how does a shift to outsourcing change who the users are for a CTMS, document management system, EDC, and similar programs? How useful are e-tools if the “back end” of the workflow stays “paper-minded” in its policies and procedures, reflected in unchanged workflows, double-checks, and review practices?
And Vendors, Too
The developers of software used in clinical research are equally guilty of forgetting the context of how customers use their tools. Vendors have great opportunities to add significant value to their customers by helping sponsors see the possibilities that their tools open up, and by knowing the clinical research business as deeply and broadly as possible. This knowledge should translate into more focused and anticipatory designs, creating more powerful and efficient tools. Too often, however, vendors and contract research organizations see educating their clients as a danger to future sales, and try to over-simplify change.
Typical software development—even the industry-specific kind we in clinical research usually encounter—tends to chase after customer-driven enhancement requests that are often shortsighted for all the reasons cited above (responding to the “needle in the backside”). The result is needlessly complex software with features even the requesting sponsors may forget they wanted! More damaging than needless complexity is that the effort to chase enhancements takes money away from the literal “end”—the output, reporting, and visualization of information (which is all a tool is really good for).
This irony plagues each aspect of the research software universe. Vendors may see the whole gamut of functionality possible, but as professional engineers, they see and build it linearly (they begin at the beginning and end with the end). As a consequence, they inevitably run out of time and money before they reach the output function (reporting).
How many times do we hear vendors do their demos this way: they start with the very first point of data entry, move through to the point everyone is waiting for (getting something back for all that entry), and then they say, “well, there was no point in re-inventing a report writer, so you should use something standard and off-the-shelf.” The “data out” are what matter in the actual business context, but to a software engineer it looks like a data processing problem, not a business use problem. If this were true, and off-the-shelf reporting was adequate, so too would be off-the-shelf entry—so actually, let’s forget the whole thing; and yet there really is a utility for clinical research–specific software products, if built with the end in mind.
Today’s software vendors need a knowledgebase and a discipline not commonly found. The need for vendor domain knowledge is greater than ever, plus an understanding and vision of where their customers are going. Certainly, sponsors have the bulk of the responsibility in teaching this, but for the vendors, the discipline is in rejecting enhancements for enhancements’ sake and leading their customers toward being enabled to handle the future.
Is There an End?
Another way that clinical research sponsors get ahead of themselves is to assume that once the first wave of interest and urgency is sated, the project is done. This is hardly the case. Yes, processes may have been rewritten, software configured, and newly reorganized staff trained in their altered jobs, but the work does not, and cannot, stop there. The second and third waves of change wash over the organization as the “lower priority” staff need to be oriented, and as the new processes need to be iterated to reflect actual experiences versus the original assumptions.
It sounds like “continuous quality improvement” for those sponsors who have process improvement staff. Except, for sponsors with such staff, they themselves are moving from project to project—working continuously, perhaps, but not necessarily improving. They too get bored (or run out of resources) with the first wave of the project, and are not there to reconsider the impact and effectiveness of new work models or software applications. So, in some senses there is no end, but rather steady re-examination of purpose, needs, and solutions.
“Begin with the end in mind” is certainly the start of a solution. “Begin with an understanding of the end” is probably more profound. Identifying possible “ends” is one thing; understanding their meaning to the user and the enterprise requires more thought, breadth, and management than most sponsors or vendors are used to providing.