Revisiting the "Do It" Button

"For some reason I was reminiscing this past weekend on one of my past consulting assignments at a local biotechnology company. I recalled a discussion I had with a woman who was the director of Data Management there at the time. We were talking about the frustrations we had with program specifications, and she laughed, and said, 'What I want is a big red button in the middle of the screen that says "Do It," and all I have to do is click on the button and everything is done properly!'"

Is this purely wishful thinking or can modern technology achieve this level of automation even in a fast changing, regulated Pharmaceutic world?

For more details on what you can do to get a "Do It" Button - Please click on the icon below to see the complete article (PDF).

ACRP 2011 Global Conference Presentation

Dr. Kirk Mousley continues to present new ideas and his insights at the ACRP annual meetings.

Join him in Seattle, Washington April 30 – May 3, 2011 for the ACRP 2011 Global Conference & Exhibition where he will be giving a presentation titled "Creative and Critical Thinking in a Regulated Environment".

Session Date: 5/1/2011 09:15 - 10:15 AM.

Creative thinking and critical thinking work in concert to spur innovation. Creative thinking produces new ideas; critical thinking evaluates these ideas and determines their worthiness and how to implement them. Both are needed to improve current processes and tools.

The pharmaceutical industry is a heavily regulated industry, in which employees must follow SOPs, and be aware of and compliant with FDA regulations. Sometimes these regulations stifle creative and critical thinking.

Many businesses, not only in the pharmaceutical industry, need employees to follow set procedures, especially in a manufacturing environment, to ensure quality and consistency of the end product. As a result, creative and critical thinking not only aren't encouraged, but often are discouraged among "production" employees.

The use of standards in the pharmaceutical industry, especially in the clinical data management area, can sometimes conflict with creative thinking; yet, critical thinking is crucial in this area. A thorough evaluation of proposed changes must be made in conjunction with an understanding of the value of standards.

The FDA is not always clear or timely in producing regulations and guidelines, and it is this lack of clarity and timeliness that often stifles, or even paralyzes many companies' efforts to improve processes and implement new technology.

In this presentation Dr. Kirk Mousley will discuss both creative and critical thinking as it applies to in the pharmaceutical industry and offer insight on how to encourage it - for the better.

Medical Dictionary for Regulatory Activities

Mousley Consulting is pleased to see that after many years of numerous “do-it-yourself” medical terminology coding dictionaries in use by Biopharmas, the FDA has committed to a standard dictionary, and that this dictionary has become the standard for adverse event reporting in the USA. This fairly recent commitment is to the Medical Dictionary for Regulatory Activities, commonly known as MedDRA.

For many years Biopharmas performed medical terminology coding using their own private dictionaries developed totally “in-house” or modified in some way from one or more dictionary sources such as Coding Symbols for Thesaurus of Adverse Reaction Terms (COSTART), World Health Organization - Adverse Reactions Terminology (WHO-ART), International Classification of Diseases (ICD9), and World Health Organization – Drug (WHO-DRUG) resulting in a hodgepodge of dictionaries and coding schemas.

In order to bring consistency and uniformity to the coded data being submitted to it, the FDA has recently committed to a standard coding dictionary, namely MedDRA. In addition to the FDA’s selection of MedDRA, the International Conference on Harmonization (ICH) backs MedDRA and the European Union and Japanese regulatory bodies mandate the use of MedDRA for safety reporting.

In this article, we explore the fundamentals of MedDRA, hoping to provide a primer in medical terminology coding for the uninitiated, non-dictionary group, persons otherwise involved in clinical trials. We begin by discussing the need for coding, and then delve into MedDRA, its structure, its use, and why we are pleased to see it after all these years.

Readers are encouraged to share feedback and suggestions regarding this article, and welcome suggestions of topics.

Please click on the icon to see the complete article (PDF).

Document Management - What it is and why?

It has been my experience that oftentimes, many companies do a better job managing and securing their office supplies than they do their business-critical documents.

The electronic documents that are essential and critical for today's business are all too often taken totally for granted. Very few businesses take the time to consider the expenses that they might incur because of:

* Time and effort wasted in locating documents. Recent research indicates that nearly 10% of an average office worker’s day is spent trying to locate existing information and documents.
* Redundant effort expended because it’s often easier to recreate something than it is to try to find it.
* Time and effort involved in figuring out who has the latest version of a document, and recovering it when various revisions overwrite each other.
* Unnecessary and inefficient usage of network storage devices and network bandwidth, because the documents are dispersed everywhere across the businesses' storage devices, rather than in a centralized, indexed, location.

Likewise, few businesses take the time to consider the considerable risks that they expose themselves to on a daily basis because:

* Security is applied haphazardly at best, which potentially exposes important information to inspection by inappropriate people, like your competitors.
* Critical documents are stored -- often exclusively -- on laptop computers that could be lost, stolen, or damaged at any time.
* Documents that are stored centrally on Windows network drives, once deleted, do not go into a recycle bin as commonly believed. They simply disappear, and must be restored from backup (if you’re smart enough to have one).
* No record exists of precisely who has viewed and/or edited a document. It’s therefore impossible to audit a business process to uncover mistakes or inefficiencies.

In rather stuffy terms, a Document Management System (DMS) can control the life cycle of documents in your organization — how they are created, reviewed, and published, and how they are ultimately disposed of or retained.

We at Mousley Consulting, Inc. believe that properly designed and used Document Management System can rapidly pay for itself. Furthermore, we do not believe that there is a one-size, fits (or suits) all software application. The range of solutions goes from inexpensive, open-source systems based on Unix-based servers to robust, hosted Microsoft SharePoint applications customized to seamlessly support proprietary workflows - what are your business requirements?

Dr. Kirk Mousley

What is this Unix stuff?

Unix is a computer operating system originally developed in 1969 by a group of AT&T employees at Bell Labs.

Unix and Unix-like operating systems are widely used in both servers and workstations today. The Unix environment and the client-server program model were essential elements in the development of the Internet and the reshaping of computing as centered in networks rather than in individual computers.

Under a 1956 consent decree in settlement of an antitrust case, AT&T (the parent organization of Bell Labs) was forbidden from entering the computer business. Unix could not, therefore, be turned into a commercial product under the terms of the consent decree, Bell Labs was required to license its nontelephone technology to anyone who asked for it.

In 1983, the U.S. Department of Justice settled its second antitrust case against AT&T and broke up the Bell System. This relieved AT&T from the 1956 consent decree that had prevented them from turning Unix into a product. AT&T promptly rushed to commercialize the Unix System V, a move that ironically very nearly killed Unix.

In 1991 Linus Torvalds released a version of Unix named "Linux" as free software. Linux distributions, comprising Linux and large collections of compatible software have become popular both with individual users and in business. Popular distributions, some with rather esoteric names, include Red Hat Enterprise Linux, Fedora, SUSE Linux Enterprise, openSUSE, Debian GNU/Linux, Ubuntu, Mandriva Linux, Slackware Linux and Gentoo.

Mac OS X is also a Unix system developed by Apple Inc.

Linux and BSD are now rapidly occupying much of the market traditionally occupied by proprietary Unix operating systems, as well as expanding into new markets such as the consumer desktop and mobile and embedded devices.

We at Mousley Consulting, Inc. are not only closely watching the "Open Source" software initiative, but are dabbling in it as well, having set up a server running the Ubuntu operating system with OpenDocMan and OpenClinica web applications. Furthermore, we have set up a laptop running Ubuntu to serve as our test bed client.

The allure? The software is free, the source is readily available and customizable, and it is supported by hundreds (if not thousands) of developers/experts.

Stay tuned! We will continue to explore "alternates" to the perceived high cost of Microsoft software and discuss our findings in this space.

Have you used Unix and/or Open Source software? If so, what do you think?

Working Together

I think the word "collaboration" is too fancy and is poorly understood by many in any event. I prefer to say "working together."

The best way to for people to work together is for them to be physically together.

When you are in the same room as your co-workers, you can easily interact, share ideas, asks questions, and accomplish things. Many people work better in a social environment where conversations fosters understanding, spark ideas and provide enthusiasm.

Of course, one can get carried away with talking to another and end up shooting the breeze all day and not accomplish anything. However, being alone in a quiet workplace, one can daydream all day and not accomplish anything just as easily as one can do significant, uninterrupted work.

One of the downsides to being together is the need to travel to a common gathering place, such as the office. Many companies have geographically dispersed workforces and more and more companies allow telecommuting so workers don’t have to spend as much time on the road.

For telecommuters, perhaps the next best thing to being physically together is to be virtually together. Software tools such as IBM LotusLive Engage, DRE Business Collaboration Network and Microsoft SharePoint can put everyone in the same “room” electronically.

Microsoft SharePoint uses a web server that provides Team Sites which allow sharing of information, calendars, tasks, ideas (wiki), and documents. The only missing component to virtual "working together" is the verbal/visual communication aspect. Perhaps SharePoint combined with video conferencing is the way to be productive, social, and working physically apart? What do you think?

Dr. Kirk Mousley

Why Software Projects Fail

According to a study done by the Standish Group, the U.S. government and businesses spent over $81 billion on canceled software projects, and another $59 billion for budget overruns annually.

Their survey claims that only about one-sixth of all projects were completed on time and within budget, nearly one third of all projects were canceled outright, and well over half were considered "challenged."

Of the challenged or canceled projects, the average project was 189 percent over budget, 222 percent behind schedule, and contained only 61 percent of the originally specified features.

What are the primary causes of this failure rate?

We define a failed software project as one that is over budget, behind schedule, or fails to deliver value for the users of the software. Most people talk about the first two, over budget and behind schedule. One wonders how many companies actual evaluate the "value" they get from their software projects.

Here are our reasons why software projects fail. In a future post, we will address how to mitigate these issues.

Unrealistic Schedules

(Poor Cost and Schedule Estimation, Failure to Plan, Never Reviewing Project Progress, Ignoring Late Failure Warning Signals)

Pushing for an aggressive schedule does not accelerate the work, it actually delays it. When faced with an unrealistic schedule, development teams often behave irrationally. They race through the requirements, produce a superficial design and rush into coding. The mad scramble to build something - anything - results in a poor-quality product that has the wrong functions, is seriously defective and ends up being late anyway.

Setting correct schedules can be difficult. If management has software development experience, that is a help. However, our general observation is that most projects are not allowed sufficient time, and with many projects, the time from the testing and quality assurance phases of the project is often severely trimmed.

Inappropriate Staffing

(Lack of Resources, Lack of Executive Support, Skills that Do Not Match the Job)

The only way to complete an software development project rapidly and efficiently is to assign an adequate number of people with the proper skills and then protect them from interruptions and distractions. This helps build the motivation and effective teamwork needed for quality results. When managers fail to provide timely, adequate and properly trained resources, their projects will generally fail.

Software development continues to be a rapidly changing field. Programmers need continual training to stay current. It also takes a continual desire to learn on the part of programmers.

Changing Requirements During Development

(Incomplete and Vague Requirements, Poor User Input and Lack of User Involvement, Stakeholder Conflicts, Communication Breakdowns)

To start designing and building products, software developers must know what product to build. Unfortunately, management, marketing and even the customers often don't know what they want. Or worse, they think they do know and then change their minds partway through the job. While the requirements normally change in the early phases of a job, there's a point beyond which changes will waste time and money and disrupt the work.

This area also leads to the lack of value of the software project for the company. If the project's requirements are not thought out to a reason degree of completeness, the resulting software often provides little value.

Poor-Quality Work

(Poor System Architecture, Inadequate Testing, Testing in the Production Environment, Lack of Quality Assurance, Not Conforming to Industry Standards)

A common scenario is one where a manager of a software project that has to meet an accelerated delivery date set by their boss. They may unmercifully push their software developers, who rush through the design and coding and skip all of the quality reviews and inspections. Testing finds many defects, but management argues for delivering the software and fixing defects later. Management meets the deadline, but the system is a disaster. It is so unreliable that the software has to be fixed every time a change is made in the product or product mix.

When executives push for unrealistic schedules, the project either will be late in delivering a working product or will produce a product that doesn't work. There's a saying about software quality: "If it doesn't have to work, we can build it really fast."


Believing in Magic

(The Big Red Do-it Button, Unrealistic Expectations)

Commercial off-the-shelf software, or COTS, is an attractive way to save development time and money. But COTS isn't a silver bullet. If not properly managed, it can be a disaster. A COTS product that works perfectly in demonstrations, for example, may crash when subjected to different hardware configurations, higher data rates or even data-entry errors. You must test the product thoroughly enough to expose previously untested conditions. If the program is troublesome when stress-tested, it will almost certainly be troublesome when used in production.

In addition, the use of COTS may force users to adopt inefficient processes in order to use the software. This inefficiency will reduce the value of the software. A full explanation of the "buy versus build" evaluation process is beyond the scope of this entry. However, there are costs associated with configuring COTS, adjusting processes, and process inefficiencies that must be compared with the cost of writing software from scratch.

Conclusions

It is important to allocate sufficient time and resources to complete your software projects successfully. It is equally important to take time in the planning and requirements phase to make sure the project is able to deliver real "value" to the users. Finally, it is important that software be sufficiently tested to minimize the cost to the business of software errors.

Source: Why Projects Fail - Watts S. Humphrey
Source: Cost of Software Failures