My “Are ELNs doomed?” Presentation at IQPC

Our marketing dept signed me up to do a presentation to the general session at IQPC in Brussels, with the rather provocative title “Are ELN projects Doomed?”. Um, thanks guys. No real guidance on what to say, but an expectation it will be provocative!

I’ve become increasingly concerned that what’s said in public forums (e.g. articles, conferences etc.) isn’t a true reflection of what’s really going on. A lot of ELN systems are being introduced based on tools companies already have (Microsoft Office being typical), and those don’t get any publicity (no vendor to push it!), and of course you never hear about the problems, disasters, and near misses!

This systemic fault in how the industry communicates is really serious – and will result in an awful lot of money being wasted, and our credibility damaged – just because people think doing X is the safe way (for any given value of X), but in fact the case study they’ve seen was the only one where X has worked and there are 10 other people who tried X who have hit really serious problems (often fatal).

Given the nature of our business and product we see an awful lot of ELN projects across a wide variety of businesses, disciplines, and vendors. What we’re seeing in terms of best practice is at times completely contrary to what you’d think listening to conference talks, reading magazine articles etc. Of course, there’s no reason to suggest we’re right and everyone else is wrong, but on the other hand there’s a huge gap and that’s a worry.

So my presentation was an attempt to draw attention to this and propose some solutions:

  • Be very careful about the use of the “ELN” word, as it’s too ambiguous. Ideally, stop using it entirely. It is especially useful to get vendors to describe their offerings without using the term “ELN” – then you find what their real focus is.
  • Keep the ELN project as simple as possible. I mentioned some of the frameworks we use for this – The Triangle, Broad Vs Deep, etc.
  • Blog – read blogs, and join in yourselves.

You can download a copy of the presentation here here. I had some interesting chats with people afterwards – I’ll try to expand on some of these points in future posts.

As an aside, I’ve nearly given up on SlideShare – the Keynote conversion process doesn’t seem to be working well.

Update: Rich Apodaca over on Depth-First makes some contributions here.

My workshop at IQPC Brussels yesterday

Jo and I gave a workshop on “ELNs in Biology” which people seem to enjoy. My thanks to the attendees who not only listened to what we had to say but contributed their own expertise and experience too which greatly enriched the experience for all involved.

We didn’t know what the attendees were going to want to cover so I must confess the presentations don’t read as well as they hopefully came across. However, I hope they will provoke some thoughts all the same.

My overall proposition is that Biology is a very different beast from Chemistry and what works in Chemistry – the products, approaches to the projects, rollout strategies, etc. all need to be reviewed in the light of the special challenges of Biology environments.

There were two main presentations I used. The first looked at the ELN story from Chemistry from Biology and some of the differences between the two. You can download it here.

The second presentation looked at the Technology Adoption Lifecycle (TALC), which was first described by Geoffrey Moore in his book “Crossing the Chasm”. The TALC describes how people react to discontinuous/disruptive innovations and how you can help your innovation get adopted as easily and widely as possible. My contention is that Biology userbases are sufficiently complex that you should use Chasm-crossing techniques to both develop and deploy your ELN. You can read the presentation here.

Interestingly there were a number of people in the workshop who had successfully deployed an ELN into Biology and they had used Chasm-crossing techniques to do so – not because they’d heard of the concept (they hadn’t) but because it was the most sensible approach.

I’ve also uploaded the presentations to SlideShare, but the conversion process is taking some time. Once they are up the SlideShare versions should have the transitions and builds etc. which might make for a better reading experience. They should be on my SlideShare page in due course.

There’s lots of other stuff that came up in discussion, which I will try to cover in later blog posts. For example:

  • What you see in conferences and publications in terms of case studies etc. isn’t representative of what’s really going on. There’s a lot of in-house development, a lot of use of Microsoft Office and other applications – but because there’s no vendor involved, they don’t get publicity because most publicity needs paying for, e.g. speaking slots, article placements etc. Sadly these are often the most successful deployments of ELN functionality – but it didn’t come from a vendor with “ELN” stamped on the box!
  • I don’t believe you can have one ELN for Chemistry and Biology – or even for all of Biology.
  • All of this is dependent on your definition of “Chemistry” and “Biology” – and this varies from company to company. In particular big Pharma seem to conduct a restricted set of activities on a very large scale (perhaps because all the really weird stuff is effectively outsourced to Biotechs) – which makes taking lessons from any company very difficult.
  • Of course, sales and marketing efforts by various vendors do nothing to clarify this already muddled picture!

Bad Software Design Inhibits Use of Enterprise Apps

It’s a well known but little admitted problem with Enterprise Software that the User Interface sucks, and that it matters – it’s kind of a weird “Don’t ask, don’t tell” thing.

Sadly we’re all conditioned to this, accepting it as the norm – to the extent that users feel bad because they can’t immediately use the product, and companies require as a matter of course that their vendors provide extensive documentation and training to make a badly designed product usable.

The Electronic Lab Notebook industry is no stranger to these problems, and in fact suffers more than most. Products are designed by Geeks (of the IT or science variety), evaluated by teams concentrating on feature count, and thrown at users who are just required to use them.

I’ve always been concerned with the problems created by the ELN selection process, but even when a product has been selected adoption is hampered by usability issues. Good products shouldn’t need extensive consulting, training, customisation to enable the users to be productive – they should “just work”. Of course there should be APIs and the ability to customise the system (and our products do) but that work shouldn’t be a requirement to get things going.

One of the best early decisions we made was to hire an Information Architect to work on PatentSafe. What I learned is that Usability isn’t just a matter of a nicely designed User Interface, it’s also about the concepts that the software exposes to the user. In fact, consistency and transparency are more important for usability than “prettiness”.

There’s a good article on ComputerWorld on how Bad Software Design Inhibits Use of Enterprise Apps. Some choice quotes from the article (I’d encourage you to read the full thing) with some comments…

“Software manufacturers are generally confident that their products will succeed on the strength of their technology,” Hambrose writes. “But products that don’t appeal to their users can be self-defeating. Whenever software systems create obstacles-technical jargon, ambiguous messages, illogical sequences or visual clutter-the people who use these systems will respond in a variety of ways.” That typically includes undesired behaviors that users (and CIOs and applications managers) know all too well-frustrating and inefficient workarounds, complete disregard for business process, or abandonment of the application altogether.

As a vendor I’m always interested in hearing from users about how we can improve our products, and it’s depressing the number of times something’s not quite right and they just live with it rather than shouting. All the stuff in PatentSafe that makes people go “Wow” has come from conversations which have started from us probing into what a user thinks is a minor issue not worth actually mentioning. This is the major reason we visit our customers face-to-face, and I often come away with half a dozen new feature ideas.

Sadly so many companies buy stuff over and above the real interests of the users – because the user’s don’t have a voice, or because they don’t know what to ask for. Yes, there are user representatives on the purchasing committee but they suffer from what I call the Toaster problem. Again from the article:

“Hambrose: It’s the same problem, different day: dashboards, CRM systems, or whatever is coming down the pike this month. And the dashboard suffers from same problem. The consumers of the technology-the business side of the house-don’t know how to ask for what they need. They ask for what they want. That’s different than understanding the need. The tech group on the other side of the house, they’re ready to buy or build what’s asked for.

Finally, I loved this bit on what happens when they are invited into product demos. (it’s a bit too large to quote in full here).

Some days I feel we’re punished a bit by evaluators because PatentSafe is too straightforward to use. Yes, there’s a lot of power there but we’ve worked hard to make the learning curve shallow and ensure you only need to understand the bits that are relevant to you. It really does take a lot more thought and effort to design a “simple” system rather than an complex one, a lot of watching how people adopt the system, and good communication with customers long after they’ve purchased and deployed the system. Ironically sometimes people evaluate PatentSafe against other products which take a week’s training and customisation, and feel the other solutions are somehow more “powerful”. Of course, they aren’t – they just make the user work harder.

This is why we encourage prospective customers to pilot – use the system in real life, get a feel for it. 90% of the time, they fall in love – even when compared like-for-like with other products and approaches. The other 10% is where we learn a lot about how to make a better product.

By the way, our IA is Karen Roles, she’s an excellent Information Architect and available for contract work – you can see her Portfolio here. We like her to come back every now and then to make sure we haven’t strayed too far from the One True Path 🙂