But getting back to the point, locating computers in the laboratory is not new; we’ve been doing it for 40 years or so, and its getting easier. Flat screens, mounted on telescopic arms, membrane keyboards, on slide-away trays, and use of KVM devices to switch the desk-bound processor between use at the desk or in the lab, have all helped. Of course this doesn’t overcome the basic mobility of a paper notebook, and it remains to be seen whether mobile electronic devices will have any impact on laboratory work. Already there are ELNs that are iPad-ready; there’s a major LIMS vendor that has been advertising for some while, a LIMS running on an iPhone. It is possible that these mobile devices may offer the possibility of capturing data, notes and ideas that can be synced back to a laboratory system so that the chore of sitting down and fully documenting an experiment can be conducted in an office environment.

But what if…..we were to use multimedia, rather than just text and images, to record experiments, or if the laboratory became a ‘Minority Report’ example of ubiquitous computing???? It may be some way away, but I suspect its not the ELN that is doomed.

The other news item appeared on the BBC website: ‘MI5 staff who lack computer skills made redundant’. (MI5 is the UK counter-intelligence service). In a round of compulsory and voluntary redundancies, MI5 staff lacking IT skills are being told that they are not wanted. Counter-terrorism is increasingly dependent on technology and officers have to adapt to keep up and to be completely comfortable using computers and the latest technology. This would never happen in a laboratory, would it?

I can well remember witnessing projects where (a) the objective was to faithfully reproduce a paper process on a computer, and (b) there was no give and take over a specific requirement. In the first case, the project was a total failure; it reproduced fundamental flaws in the paper process and never took advantage of the capabilities of the technology. In the second case, the only way out was some very clunky customisation that was unable to survive the next software release. Clearly there are some things that we as human beings are very good at, and there are other things that computers are very good at. There’s still a way to go before these qualities are fully merged, so the more we can do to adapt to the logical capabilities of a system, rather than expect the system to adapt to our occasional illogical capabilities, the more likely we are to find a successful solution. Now that’s not to say we just give in to whatever is presented to us in the way of a computerised system, but we do need to be confident that we have a robust and logical process that we can apply the technology to.

In terms of a collaborative approach with vendors over RFPs, the issue may bear resemblance to Game Theory and the Prisoner’s Dilemma. The basic scenario is competitive, from a financial perspective, and communication, is to some extent, driven by the passing of a document (RFP) between the two parties. In this context, achieving a win-win isn’t going to be easy.

Unfortunately the RFP process is never going to be completely open and collaborative, but that’s not to say that it cannot get better. Like many aspects of business life, standardisation, and a one-size-fits-all approach tend to eliminate the flexibility that is needed to drive good outcomes.

Within the context of laboratory data and information management, raw data tends to draw out some interesting debate along the lines of what constitutes raw data, how and where do we store it, and for how long?

Those of us involved in the business of laboratory systems and laboratory integration can be kept pretty busy with the technological challenges of acquiring, managing and storing ever increasing volumes of raw data, but behind these challenges are some more fundamental questions that need to be answered before we can even start thinking about a solution.

So, if we assume that we know what the raw data is, the decision about how long we keep it is influenced by three different considerations.

Firstly, scientists are often hoarders of data and like to hang on to raw data as basic scientific evidence, for reference purposes,  or for re-assessment in the light of future scientific or technological advances. This requirement has no definable timeframe.

Secondly, there is an ethical position, largely determined by regulatory bodies, to allow for the re-examination of data in the light of the consequences of unforeseen defects, failures or adverse effects of products or processes.  This timeframe may be determined by, or related to the lifetime of the product or process.

Thirdly, there is a business requirement to address IP protection in terms of the underlying value of the data to the business.  This may have a long timeframe if it is relevant to a patent, but could in other circumstances have a relatively short timeframe.

Making the decision on what to store and for how long has its complexities, but the combination of regulatory and legal guidance, business best practice, good technology and hopefully, common sense, is helping shape a way forward.  However, it is always good to remember that the scientific knowledge food-chain starts with the raw data, and an item by Derek Lowe (Data, Raw and Otherwise), loosely connected to ‘Climategate’ on In the Pipeline serves as a good reminder of the importance of raw data from the scientist’s perspective.

The programme served to highlight the difference between the perspective of business success and user acceptance. Its difficult to argue against the fact that RyanAir are a successful business, but at what cost?

So when it comes to informatics projects, how do we measure success? There are three phases in an implementation that may have different measures. In the short term, completing the implementation on time, on budget and in full (all deliverables) represents the conclusion of a successful project. In the mid term, the return on investment becomes a success criterion; how soon can we claim that the upfront costs have been recovered through some form of increased productivity. But in the long term, the metrics become more fuzzy. Most informatics projects will have a knowledge management component that targets sharing, collaboration and IP protection that lead to some discernible improvement in the way the business operates. These three phases roughly align to the three basic criteria of cost, time and quality, the emphasis in the first phase being on time and project costs, in the second phase on ROI (costs) and in the third phase on quality. So in the Ryanair example, the difference of opinion centres around ‘quality’, a discussion that seems sadly out of date since ‘fit for purpose’ is a modern acceptable catch-all definition for quality, and that having the latest and greatest doesn’t automatically correspond to a quality solution.

This argument tends to reinforce the fact that user acceptance is the most critical long term success factor for any informatics project, and as a consequence, identifies where a lot of effort needs to be made in project planning. This means keeping careful control of user requirements, keeping users involved throughout implementation, and recognising and supporting the full spectrum of users.

This was the basis of a presentation I gave at the 5th Forum on Laboratory Informatics, San Francisco, Oct 26-28th. The presentation is available here.

Now, knowledge management (KM) is a scary topic, open to abuse and exploitation by unscrupulous vendors and consultants. The principles of KM all make good sense; it’s just that an ‘industry’ seems to have grown around the topic that sees it as a potential revenue stream. I’ve spent some time working in KM teams and with KM initiatives in my corporate career, and the conclusions that I came to were:

• KM solutions do not come in a shrink wrap box
• You cannot implement KM, it is an outcome
• KM is about people; technology can facilitate good KM, but that’s all

Basically, Information Technology is a big part of the problem, but a small part of the solution.

By complete chance I came across an article written by Elisabeth Goodman, about a company (Deep Visuals Ltd) being run by an ex-colleague of mine, Alan Payne. The article touches briefly on some of the KM outcomes from the enterprise-wide ELN implementation from our Kodak days and was a good reminder that despite the up-front concerns about the investment, longer term benefits accrue from (a) sharing and making information accessible, (b) ensuring that systems are easy to use, and (c) evolving a culture based on collaboration.

Reading Elisabeth’s article caused me to check her blog, and I found a number of interesting posts that may be of interest to visitors to this site – you’ll find a link in the Blogroll in the left-hand sidebar. The item that really caught my eye was There’s more to decision making than meets the eye or.. why we shouldn’t dismiss gut feelings. Serendipity has always had a significant role in science; so many of the major scientific breakthroughs and advances originate from chance observations and things that went wrong. We often learn more from failure than success! You can’t help but wonder where we would be if Lean and Six Sigma had come along a couple of centuries earlier. That’s not to say that Lean and Six Sigma don’t have a place in science, but I side with Elisabeth in her conclusion that we need to keep some reasonable space for right brain thinking alongside the systematic and structured approaches that strive to attain increased efficiency and productivity.

As a footnote, I’ve just finished reading a novel, The Invention of Everything Else by Samantha Hunt. It is an entertaining literary mystery based on the life of Nikola Tesla, an outstanding but somewhat neglected 20th century inventor. Pure right brain!

Oh, well I suppose I should expand on this further. We have terms such as COTS (Commercial Off-The-Shelf) as a response to things like GAMP (Good Automated Manufacturing Practice):

http://www.ispe.org/cs/gamp_publications_section/gamp_publications_overview

Is “COTS” Confusing?

Here’s what I see that continues to happen: we come out with a set of guidelines that imposes or suggest certain terminology and, if it sounds like an appealing thing to achieve, everyone wants to call themselves by that term. One such term is COTS. I had started an academic discussion of the “true” meaning of this term in my LIMS/Laboratory Informatics group in LinkedIn and found some good academic responses to the term:

http://www.linkedin.com/groupRegistration?gid=36640

However, I realize that there is a different dynamic of understanding during the sales process of these systems.

Now, it could be that there are circumstances where the terms do apply. It could be that end-customers expect too much from these systems. Regardless of the intentions of what COTS should have meant, there is an expectation from many customers that they will purchase these systems, have a small implementation to “configure” them and an equally small series of validation scripts and will be up-and-running. The truth is that, with many of these systems, the projects are more extensive than this.

Why Do We Care What “COTS” Means?

The reason this is important for customers to understand is that it will affect the budget you need to allocate, as well as the types of people to allocate. Many of these projects require a true project manager and people with experience in delivering software specifically for these exceptions-based systems, as opposed to those with specific experience in “from scratch” software delivery. Using people that only know how to install systems is not sufficient, either.

As such, the people buying new systems have to be made aware of the fact that they will not know what level of effort to allocate to these projects without doing an in-depth study of their requirements and comparing it to these systems, especially if their installation will be a large one.

And, they cannot rely on those of us that are selling them the software or the services to do it for them, unless they specifically bring in a person just for that purpose. The reason is that each person involved will be true to our own mission, regardless how “honest” each claims to be and will do so as a practical matter, to some extent. If that mission is to sell the software, that is primarily what you must expect that person to do – not to make an unbiased evaluation of your project situation. As such, I truly believe that each customer must become a savvy buyer just as they would if they were buying an automobile.

One of the more significant stories has been the problems with the NASA records from the early space program.   I came across this article The lost NASA tapes: Restoring lunar images after 40 years in the vault which describes some of the superhuman effort involved in reclaiming important data that may otherwise be lost forever.  The data may probably be a bit more significant than some of the stuff we have in our labs, but who knows?  But this is exactly the scenario that a good records management process and a good records’ manager has to save us from.  If Records Managers become the heroes of the 21st century, so be it!

The NASA story makes interesting reading and raises the question ‘it couldn’t happen to us, could it?’  An earlier item from Charlie Sodano  Getting Started with Records Management, was posted to draw attention to the problems and how to make a start on solving it.  And the big question is, how ready are we now?  It’s not unusual to come across surveys quoting the number of companies who feel they have a robust records management strategy in place being frighteningly low.  Unfortunately, investing in records management doesn’t show a plus on the bottom line…..but if disaster strikes, then it can prevent a very big minus.  Just like buying an insurance policy, really.

It is now getting to be quite common to find presentations on aspects of Web 2.0 in conferences dedicated to laboratory data management. It was at the SMi Conference on Electronic Lab Notebooks in London earleir this year that Cameron Neylon gave a presentation on ‘The lab that was born on the web’. The presentation was a fascinating insight into the construction of a laboratory system built from available, free of charge, web-based tools. Those of us from an industrial background probably winced a bit, thinking FDA…, USPTO…, and a few other constraining acronyms, but it was quite eye-opening to consider what could be achieved with zero capital outlay.

Cameron is an established blogger (Science in the Open), and he has recently turned his attention to the announcment of Google Wave, a new online communication and collaboration tool, where a “wave is equal parts conversation and document, where people can communicate and work together with richly formatted text, photos, videos, maps, and more.”  With a definition like that, you could easily imagine wide potential across a number of industrial sectors.  You can access the two parts of Cameron’s thoughts here:
Google Wave in Research: Part 1 – Papers
Google Wave in Research: Part 2 – The Lab Record

In my experience there are three factors that have a distinct influence on the likelihood of success.

1. Technology Adoption and Crossing the Chasm.  Blatantly obvious, I know, but it is important to understand that all users are different and it’s important to figure out which users sit on either side of the ‘chasm’.
2. The Technology Acceptance Model. There are two vital factors that influence user buy-in.
3. The Technology Adoption S-Curve and the Assimilation Gap.  The roll-out plans need to incorporate tasks to ensure that users are fully aware and understand the project objectives in order to minimise the assimilation gap.

The project team members tend to be enthusiasts and/or volunteers, committed to the success of the project; most problems come from people that don’t volunteer for the team.   So it’s always helpful to remember that people are more likely to comply with a request when:

• A reason is provided
• There is give and take
• They see others complying
• The request comes from someone they respect or like
• The request comes from a legitimate source of authority

This gives some clues as to the type of people that should make up the project team.