Mousley Consulting, Inc.

Portals and Document Management

2011-04-18T09:00:00.000-04:00

Technology has evolved over the years in a response to issues encountered in the workplace.

In this column, Dr. Kirk Mousley and and guest author, Michael J. Hoy discuss portals as the authors believe that it is a very relevant technology that attempts to provide solutions to several common business problems.

It has been over five years ago, that Kirk presented "Clinical Research Collaboration Using Portals" at a Philadelphia Chapter of the ACRP Smooth Sailing Conference and while the technical landscape has changed, the business issues addressed by portals remain the same.

For more details on what has changed and how that might affect you - Please click on the icon below to see the complete article (PDF).

Revisiting the "Do It" Button

2011-04-11T09:00:00.003-04:00

"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

2011-04-05T09:00:00.000-04:00

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

2010-12-29T16:00:00.002-05:00

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?

2010-10-26T09:00:00.001-04:00

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?

2010-10-20T09:00:00.000-04:00

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

2010-10-12T10:30:00.001-04:00

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

2010-05-10T10:13:00.009-04:00

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

From e-Survey to EDC

2010-03-23T13:00:00.000-04:00

Recently, Karl and I attended a seminar presented by IBM SPSS titled "Predictive Perspectives" where they demonstrated their Data Collection Author product as well as several others.

Data Collection Author can help you create surveys. You can create one survey and deploy in many different modes (online, telephone, offline) and in any language.

While the presentation was underway, it brought up the question, "At what point does e-survey software become Electronic Data Capture (EDC) software?"

We are aware of a mushrooming number of e-survey products on the market today. A incomplete list of them might include:

SurveyMonkey, eSurveyspro, surveygizmo, QuestionPro, and SurveyMethods

Now, while we don't necessarily endorse any of these, we thought these vendors might consider further developing their offerings into EDC products. What would doing so entail? Might it be possible to create a low-cost EDC system using a well-designed e-survey application as a starting point?

Obviously, a lot of surveys are single-pass collection of unedited data from anonymous sources.

One would need to allow data editing. One might need more enhanced data cleaning power than that provided by form-level edit-checking and input masking (e.g., capture dates in consistent date format). One would need to identify the person entering data. With the ability to change data, comes the need for an audit trail.

In between e-surveys and full-fledged EDC systems, lies a range of applications that allow someone to select user preferences from a specific set of options. Examples of those would be a user profile or health benefit enrollment. These applications are often custom tailored and one-time use. Can e-survey software, with its user friendly authoring capability be extended into these areas in areas to offer a much more "generic" development/update environment?

Finally, EDC would require compliance to 21 CFR Part 11 software requirements - more specifically, the software requirements detailed in Section 11.10:

Validation of systems to ensure accuracy, reliability, consistent intended performance, and the ability to discern invalid or altered records

The ability to generate accurate and complete copies of records in both human readable and electronic form

Protection of records to enable their accurate and ready retrieval throughout the records retention period

Limiting system access to authorized individuals

Use of secure, computer-generated, time-stamped audit trails

Use of operational system checks to enforce permitted sequencing of steps and events

Use of authority checks to ensure that only authorized individuals can use the system, electronically sign a record, access the operation or computer system input or output device, alter a record, or perform the operation at hand

Use of device checks to determine the validity of the source of data input or operational instruction

Determination that persons who develop, maintain, or use electronic record/electronic signature systems has the education, training, and experience to perform their assigned task

The establishment of, and adherence to, written policies that hold individuals accountable and responsible for actions initiated under their electronic signatures

Use of appropriate controls over systems documentation

Adding all of this to an e-survey application would not be a trivial endeavor. Nor will it be complete since we haven’t mentioned the addition of other longtime Clinical Data Management System functions like autoencoding and site monitoring.

While we remain hopeful that advances in software will eventually allow the creation of a low-end EDC system, we remain skeptical that it will be "inexpensive".

Improving Communications

2009-09-01T15:01:00.008-04:00

In today’s business world the daily onslaught of data and information seems to be rapidly escalating – just ads from radio, TV, magazines, billboards, and junk mail along with e-mail spam and telemarketing telephone calls bombard each of us in ever-increasing amounts. This “unwanted noise” makes it even more imperative than ever before for people to communicate with each other the best they can and for them to strive for effective, concise, and clear messaging not only on the job but elsewhere.

Communication occurs in a variety of forms: gestures, spoken word, written prose, visual imagery, as well as sounds, music, color, lighting, odor, tactile feel, temperature and even taste. Business communications can be in any combination of the above forms (and perhaps other forms as well) but for now, let us just consider more typical forms of day-to-day discourse shown in Table 1.

Each of these forms of communication has its own unique pros and cons. Unfortunately for those that think they have little time to spare, it takes time to maximize the chance the communication will be fully understood and even more time to ensure it is acted upon in the manner in which was intend.

Face to face communication, perhaps assisted with visual materials, is probably one of the most effective means of communicating, and doing so on a one-on-one basis is the most effective means. The time and other costs it takes to do so, prohibits this form of communication from being used extensively, but it should be used when the situation calls for it, such as in an emergency or other crisis, business or otherwise.

At the other extreme, a quickly composed postcard, such as one bearing a change of address, mailed to many can be a sufficient way to communicate relatively brief, commonly expressed information that is important, but not especially urgent in nature. Obviously, one wouldn’t expect the company CEO to telephone each and every vendor and customer with such news (however, they might wish to personally talk to very important and special customers).

So when you are deciding which form of communication should be used, consider the nature of the communication. Is it routine, such as a holiday schedule announcement? Or is it informational, such as directions on how to get to the company’s auditorium for a meeting? Or is it an emergency or crisis requiring that immediate instructions be given to key personnel?

Clear communications are necessary for maximizing efficiency and productivity as well as reducing inefficiencies, unneeded costs, and even workplace stress. The more complex the task, the more communications that will be required, and the greater the likelihood of one or more miscommunications will happen.

For more details on what you can do to improve your communications - Please click on the icon below to see the complete article (PDF).

OmniComm's Purchase of eRT Data Capture Unit

2009-07-06T15:47:00.004-04:00

OmniComm Systems Inc. recently acquired eResearchTechnology Inc.’s Electronic Data Capture (EDC) business. Click here to see the Philadelphia Business Journal article.

This acquisition represents a change in the EDC landscape that directly affects Mousley Consulting and some of it's clients; eRT's software customers; and biotech and pharmaceutical companies in general.

There are three points that we would like to briefly discuss about this transaction. We will not comment on the financial arrangements of the transaction, however, since that is not our direct concern. What is of interest are the following questions:

1. What will be the impact on eRT's customers?
2. What will be the impact on OmniComm and its current customers?
3. What will be the short and long term impact on the EDC industry?

First, what will be the impact on eRT's customers?

We believe this acquisition will probably be a good thing. We feel that the software might be better served being owned by a software company and not as an "orphaned" product owned by a services company. eRT has traditionally made most of its revenue from its ECG business. Software was a component of their business, but it was not the main focus. OmniComm will certainly pay more attention to the product.

However, it remains to be seen how much of the eRT software OmniComm will actually keep. Since OmniComm already has its own EDC software, it will be interesting to see how much of their own software and how much of eRT's software continues in OmniComm's future product.

When DataTrak purchased ClickFind, DataTrak's own EDC product was discontinued, and the ClickFind product enhanced to be the eventual future offering. While we feel what will happen with OmniComm probably won't be that drastic, we do believe there will be an eventual integration of the two products into one.

in any case, eRT customers may end up getting a more complete software offering, albeit not what they have been using, as well as better focused service.

Secondly, what will be the impact on OmniComm and its current customers?

Clearly OmniComm picks up a large customer base which should help the company in terms of its financial stability. In the short term, we believe there will be disruptions in service as OmniComm folds in the eRT business, but just how disruptive it will be depends on how well the merger is managed. In the longer term, the OmniComm product may be enhanced with the data management features from the eRT product, which overall should be a good thing.

Hopefully OmniComm will strive very hard to keep all of its current customers in the loop and be very responsive to them during this time of transition. Mergers are never easy, and two very different software packages will need to be maintained along with their own customer support in the short term to keep everyone happy.

Finally, what will be the impact on the EDC industry?

We have long felt there should be consolidation in the industry. At the DIA Annual show in San Diego, held in June 2009, there were still a lot of vendors. It seems, however, that the new entries are focusing on different niches, like pen on paper in the case of Kayentis, or on CDISC SDTM integration in the case of Octagon Research.

So we feel that there is still not a lot of consolidation going on yet. Maybe OmniComm's acquistion of eResearch's data capture unit is the start of more consolidation?

Looking forward, we believe that the EDC market will continue to mature and evolve. Where it ends up and what it will look like as it does so, is still anyone's guess.

Integrated Clinical Trial Management Systems

2009-06-17T15:20:00.007-04:00

Several years ago Mousley Consulting wrote an article describing some of the key functions of a Clinical Trial Management System (CTMS). Our premise was that many of the people involved with Clinical Trials knew that Electronic Data Capture (EDC) and Clinical Data Management Systems (CDMSs) are computer systems designed to capture, store, and manage clinical trials data.

However, much less familiar to many people, is the integrated CTMS. In the past, the business requirements expressed as functionalities, found in a CTMS were typically “home-grown”, stand-alone or at best loosely-coupled systems. Systems that hopefully helped clinical project managers and others create, manage and conduct their trials.

With EDC being used in more and more clinical studies, and with the increasing emphasis on the use of portals and dashboards, we are seeing some of the functions of the CTMS tightly integrated with the EDC application. Obviously the conduct and management aspects of trial management lend themselves nicely to being part of a portal or a dashboard.

The planning and resourcing aspects of a CTMS, however, do not lend themselves so readily to the portal environment. Consequently, we feel that much of what we wrote earlier is still very much relevant to trial management of today.

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

CDMS and EDC Design Highlights

2009-06-03T09:30:00.003-04:00

Over the years Mousley Consulting has published a number of articles with EDC-related topics. This was done as a founding partner of EDC Management. We believe that it makes sense to periodically revisit some of these topics and update our thinking when necessary. One of the topics we wrote about was CDMS Design Highlights. A CDMS is a Clinical Data Management System which is used by data management departments in Biopharma to collect, clean and store clinical trial data.

CDMS and Electronic Data Capture (EDC) applications suffer when the underlying repository (i.e., database) doesn’t offer data types that support the convenient storage of clinical trials-specific data. Clearly Data Capture Form Developers and Programmers spend much time developing code (and much of it redundant nature) to support the different clinical data types such as "Partial Dates". If this support were built into the repository, form developers and programmers would have a much easier time providing necessary clinical trial-specific functionality, and could more quickly make data entry forms available for users saving both time and money.

We believe that future versions of CDMS and EDC software should include the "clinical data types" that are discussed in our article. However, we understand that the design and implementation of these data types will be a challenging exercise for vendors. Certainly, there will be different ways the support for these data types can be developed and introduced. The best implementations will balance ease of programming with the required functionality.

Readers are encouraged to share recommendations that they may have for how vendors can improve their products. We would also like to encourage feedback and suggestions regarding this article, and welcome suggestions of topics.

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

What are we really trying to accomplish?

2009-05-28T12:45:00.000-04:00

As a certified Project Management Professional (PMP) and a Ph.D. in Computer Science, I realize the importance of clearly stating the purpose of a project or an application.

For many, it is difficult to take the time to work through the process of defining what is really needed.

While there are tools such as rapid prototyping and Rapid Application Development (RAD) available (see http://en.wikipedia.org/wiki/Rapid_application_development for more info), they do not remove the need for the eventual end users or the sponsor of the project to articulate in his or her mind what is really wanted.

To a large extent, my experience has shown that the more specific and constrained the requirements, the greater likelihood the project or application will succeed. The real world, however, does not always allow us to keep things as straightforward as we would like them to be.

So how do projects and applications get started? Someone identifies a need. Perhaps it is a need to do automate a repetitive function so that it can save the company money. Perhaps it is collecting information in a clinical trial for making a submission to the FDA. Needs can be small, and they can be very large.

Once the need is identified, the questions begin. I like to think of the 5 Ws and 1 H (see http://en.wikipedia.org/wiki/5_Ws). This is the hard (some may say annoying) part of starting a project. All the questions need to be asked, and some many times over until as many "clearly stated" answers as possible are obtained. The biggest question, and the one in my experience that leads to all the others, is why? Why are we trying to do this? This question is then followed by, "What are we really trying to accomplish?"

The "why" should be asked repeatedly to ferret out as many reasons as possible. Some of the first reasons we come up with might not be the most important. Some of the non-obvious reason(s) why might cause user acceptance problems if they involve issues with human performance or personal productivity. Knowing these reasons in advance will help a project or application be successful.

Once we know why we think we need to do something, we then need to define what we intend to do. To some extent, this is a question of scope in that it might involve how much of the problem we will attempt to bite off. Again, the question of what we intend to do should be asked repeatedly so that we can compare options and decide if we are addressing the most important parts first.

If we do the "why" and "what exactly" well, the rest will follow in a much easier fashion.

So, why did I write this???? :-) Certainly I did it to share my experience, but I also did it in hopes that I can help you answer these questions in your next project.

Planning Ahead

2009-05-20T11:51:00.000-04:00

Preparing to attempt to avoid "emergencies."

One of the discussions I have been having with one of my clients is that we cannot always justify taking as much time to do something as we want. One just needs to think about an ambulance on their way to an auto accident. Time is of essence, it is life or death in some cases.

The key is that the ambulance is ready before hand. The ambulance is stocked with supplies. The ambulance personnel are trained and ready to go. They minimize what might go wrong while they are not in an emergency.

I have been giving this a lot of thought. Certainly backups are part of the preparation for a business to be ready for a potential emergency, as in the case of a computer crash which the client just experienced.

Having a good backup strategy is a good start. However, we may want to go even further. In space, many systems are redundant since there is no way to get things fixed quickly. When I used to work at GE Space Division, the saying was "It is hard to find a ladder to reach a satellite if something breaks down."

Of course NASA has much more of a budget than most of us will ever have, so we cannot justify going that far. But the question is how far do we want to go?

It might make sense for a critical employee to have two computers, both validated, and both loaded with the software needed, and both able to access the "data" on a file server. Both of these computers are ready to go. If one goes down, the employee uses the other until the first one is fixed or if necessary replaced.

A key point is that this planning takes place ahead of time. The proper analysis is made when we have the time to think about it. When we implement the redundant systems (and the necessary backups), we make sure everything is working (including file recovery).

Then, when we are in the middle of a critical project, and we have a crash, we implement our "switch over" plan, and continue working.

The hard question is how much insurance is enough. No real easy answer for that one!

Welcome to Mousley Consulting's blog

2009-05-15T10:22:00.000-04:00

Hi all,

This is our first posting. I appreciate your time to read this.

Over the years (16 to be exact) we have been providing contract programming services for the biotechnology and pharmaceutical industry. We have programmed in a number of different languages ranging from Oracle PL/SQL to Microsoft .NET. We have covered a complete range of applications for data management departments including setting up Clinicial Data Management Ssystems (CDMS) and Electronic Data Capture (EDC) applications, programming Edit Checks, programming lab normal range applications, programming safety systems (eSafety Net and Clintrace), and many others.

We also have been involved in the metal industry for many years as my father owns Atlas Bronze Corporation.

Lately we have expanded into the financial arena. We have been involved with several companies attempting to raise money. One of my favorites at the moment is a Brew Pub in Hanover, PA.

We look forward to serving you an a number of different ways. Please email me at kirk@mousleyconsulting.com if you are interested in learning more.

Kirk