{"id":223,"date":"2014-02-05T21:38:22","date_gmt":"2014-02-06T02:38:22","guid":{"rendered":"http:\/\/waife.com\/home\/?p=223"},"modified":"2016-04-25T16:27:45","modified_gmt":"2016-04-25T21:27:45","slug":"the-end-is-the-beginning-monitor-2010","status":"publish","type":"post","link":"http:\/\/waife.com\/home\/the-end-is-the-beginning-monitor-2010\/","title":{"rendered":"The End is the Beginning (Monitor, 2010)"},"content":{"rendered":"

We all now know that the cost [of software acquisition] in money, time, headcount and disruption will be high\u2026.the benefit therefore must be high as well, or the cost reduced.<\/em><\/p>\n

 <\/p>\n

\u201cBegin with the end in mind\u201d is one of those classic business phrases which is no less valuable for the number of times it is ignored. Software developers and clinical research sponsors alike are guilty of sometimes fatal forgetfulness of this key concept when planning the development, implementation and use of software applications.<\/p>\n

 <\/p>\n

Clinical research sponsors generally start a software acquisition process not with the end in their mind, but with some stimulus in their back: a department is complaining that everybody else gets new tools except them; our competitors all use this tool so we should; I met a salesperson on the airplane; the vendor just announced an upgrade and they won\u2019t support our version anymore; we just hired a new vice president and she prefers vendor \u201cx\u201d over vendor \u201cy\u201d. While some or all of these situations may justify a re-evaluation of our need for software, they do not in themselves sufficiently define the \u201cwhy\u201d and \u201cwhat\u201d.<\/p>\n

 <\/p>\n

Starting Isn\u2019t the Hard Part<\/strong><\/p>\n

Sponsors may also start from some business trigger which gives them the illusion that the end is mind: we need to save headcount so let\u2019s use EDC (electronic data capture); or we\u2019re frustrated with having multiple overlapping and out-of-date investigator databases so let\u2019s buy a CTMS (clinical trial management system); or our new translational medicine VP says we\u2019re going to have a flood of pharmacogenomics data coming in so let\u2019s get one of those \u201cdata warehouses.\u201d<\/p>\n

 <\/p>\n

What\u2019s missing from these situations is the company\u2019s consideration of the strategic benefit, and of how the software\u2019s users will actually have to use it and what they will get from it. What is the tie-in between the initial impetus \u2013 the needle in the back or the business trigger \u2013 and the actual output the new software will provide? This disconnect is particularly critical in enterprise software projects because we all now 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.<\/p>\n

 <\/p>\n

Analyzing a potential project\u2019s end user benefit compared to the initial impetus need not be fatally time-consuming, which is the usual reaction to the suggestion. But it can save a large amount of wasted time and money. We should recognize that it is very easy to fall into the disconnect trap. For instance, let\u2019s consider the situation where clinical operations gets that frustration over the multiple investigator databases. The complaint is forwarded to the IT department (or worse, a na\u00eff goes to a booth at a trade show), and the answer comes back: there is no \u201cinvestigator database fixer\u201d product out there, but there are these CTMS packages and boy, they do everything. Before you know it, you are installing a multi-million dollar application over multiple years, you\u2019ve 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\u2019s not relevant \u2013 neither to the original trigger or actual user circumstances.<\/p>\n

 <\/p>\n

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\u2019s business environment. We have fewer and fewer in-house staff, we are narrowing our \u201cdistinctive competencies,\u201d we have uncertain economic and reimbursement conditions, and we have unrelenting competitive pressures. All of this mitigates against expensive multi-year infrastructure projects unless we do more to predict and understand the future end user business need. What are the future identity, purpose and constitution of our business, and therefore, what tools do we need to get there?<\/p>\n

 <\/p>\n

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 mis-configure and mis-spend our time and money. For instance, h0w does a shift to outsourcing change who the users are for a CTMS, document management system, EDC, and similar programs? How does a thoroughly \u201ce\u201d-oriented sponsor exploit tools like ePRO (electronic patient-reported outcomes) which are still fundamentally device-based? Or alternatively, how useful are e-tools if the \u201cback end\u201d of the workflow stays \u201cpaper-minded\u201d in its policies and procedures, reflected in unchanged workflows, double-checks, and review practices?<\/p>\n

 <\/p>\n

And Vendors Too<\/strong><\/p>\n

The developers of software used in clinical research are equally guilty of forgetting the context of how customers use their tools. Vendors have a great opportunity 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.<\/p>\n

 <\/p>\n

Typical software development, even the industry-specific kind we encounter, falls for chasing after customer-driven enhancement requests that are often shortsighted for all the reasons cited above (responding to the \u201cneedle in the back\u201d). The result is needlessly complex software with features even the requesting sponsor may forget they wanted! More damaging than needless complexity is that the effort to chase enhancements takes money away from the vendor\u2019s literal \u201cend\u201d \u2013 the output of the tools they are developing, which is all a tool is really good for.<\/p>\n

 <\/p>\n

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 it, 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, \u201cwell, there was no point in re-inventing a report writer so use something standard, off-the-shelf.\u201d It is the \u201cdata out\u201d that matters 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 \u2013 so actually, let\u2019s forget the whole thing. And yet there really is a utility for clinical research specific software products, if built with the end in mind.<\/p>\n

 <\/p>\n

Today\u2019s software vendors need a knowledge base 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. For the vendors, the discipline is in rejecting enhancements for enhancements\u2019 sake and leading their customers towards being enabled to handle the future.<\/p>\n

 <\/p>\n

\u201cBegin with the end in mind\u201d is certainly the start of a solution. Begin with an understanding of the end is probably more profound. Identifying possible \u201cends\u201d 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 supplying.<\/p>\n","protected":false},"excerpt":{"rendered":"

We all now know that the cost [of software acquisition] in money, time, headcount and disruption will be high\u2026.the benefit therefore must be high as well, or the cost reduced.   \u201cBegin with the end in mind\u201d is one of those classic business phrases which is no less valuable for the number of times it is ignored. Software developers and clinical research sponsors alike are guilty of sometimes fatal forgetfulness of this key concept when planning the development, implementation and use of software applications.   Clinical research sponsors generally start a software acquisition process not with the end in their mind, but with some stimulus in their back: a department is complaining that everybody else gets new tools except them; our competitors all use this tool so we should; I met a salesperson on the airplane; the vendor just announced an upgrade and they won\u2019t support our version anymore; we just hired a new vice president and she prefers vendor \u201cx\u201d over vendor \u201cy\u201d. While some or all of these situations may justify a re-evaluation of our need for software, they do not in themselves sufficiently define the \u201cwhy\u201d and \u201cwhat\u201d.   Starting Isn\u2019t the Hard Part Sponsors may also […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[51,50],"tags":[],"class_list":["post-223","post","type-post","status-publish","format-standard","hentry","category-columns-archive","category-recent-columns"],"_links":{"self":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts\/223","targetHints":{"allow":["GET"]}}],"collection":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/comments?post=223"}],"version-history":[{"count":1,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts\/223\/revisions"}],"predecessor-version":[{"id":224,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/posts\/223\/revisions\/224"}],"wp:attachment":[{"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/media?parent=223"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/categories?post=223"},{"taxonomy":"post_tag","embeddable":true,"href":"http:\/\/waife.com\/home\/wp-json\/wp\/v2\/tags?post=223"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}