In an interesting post from Jack Vinson (a fellow CENSA alumni) lays out to three simple truths of failure from a post on the IT Failures Blog which in turn was inspired by Dilbert:

• Complicated plans don’t work.
• “Spraying energy into the vortex of failure” doesn’t work.
• Your boss really doesn’t care.

The first is the most important in my opinion; and it is directly relevant to ELN projects. In my experience the more time a product takes to implement, and the greater the change in working practices required, the less chance there is of the project achieving the hoped-for Return on Investment. Which in my mind is a failure, even if you do manage to roll the application out and torture the users with it (aren’t we here to make life better for the end users?).

I’d broaden the last point to no one really cares about the ELN project – they care about its potential to impact their lives in a positive or negative way. If they really cared they’d be on the Project Team! This is a broader varient of my Toaster Analogy which when it comes up in Workshops often gets that kind of embarrassed “Yeah, that’s very true but it makes us comfortable so let’s move on” laugh.

There’s enough material around to show that complexity causes massive problems. There’s enough public literature around to show that IT projects often fail to meet their goals (and you only have to wonder what really goes on in private because who likes washing dirty laundry in public?).

Which is why I am mystified to see complexity still worshipped, with project teams brandishing their laundry list of features (all mandatory) and vendors explaining with great pride their multi-week implementation process. When questioned, people seem to honestly believe it has to be this hard!

Why can’t we find the quickest, simplest way to achieve the outcome we seek? Why are project managers so rarely rewarded for paring down the list of requirements to the essentials, shortening the project timescales, reducing risk, and slashing the budget? Why is it that products that “Just work” are somehow “Not powerful enough”?

I suspect the underlying reason (once you get beyond organisational politics and vendor sports) it is because geeks see value in intrinsic complexity. Which is fair enough – until that complexity meets the real world of people, budgets, and other projects.

Amphora are quite happy worshipping at the temple of “Less is more” because we believe that’s the best way to serve our customers. Seems that this view isn’t shared by everyone but that’s fine – the trend is in our favour. In this economy we all need to renew our focus on adding the most value for the least cost.

Oh, here’s Dilbert:

As a general rule Apple MacOS X, Linux are second class citizens in the ELN world and it is all the salesperson can do to stifle a laugh when you mention those “other platforms”. The iPad and Android equivalents don’t even get a look in!

I’ve felt this situation is increasingly unsustainable – not only is Apple’s Macintosh experiencing a resurgence, but we’re quite possibly on the cusp of a tablet-drive revolution.

An interesting blog post from the CTO at the UK’s Department for Work and Pensions wonders if their current Windows desktop refresh might not be their last.

Personally, I think it likely this is the last version of Windows anyone ever widely deploys, though.

The reason? I think they’ll be fewer workloads that actually require a heavy deskop stack. Today, of course, we have all this legacy that’s coupled to the desktop, but in a decade, I really doubt that will be the case. Most stuff will arrive via the browser.

Talking with our larger Enterprise customers, it appears their Windows Desktop infrastructure is increasingly cumbersome and it is very hard to innovate in such a complex environment. In the smaller Biotechs there’s a real push to avoid cumbersome IT generally and there’s ready adoption of web and Cloud technologies, as well as additional platforms such as Macs and iPads.

The article makes a good long term point which ELN project teams should urgently consider:

From a strategic point of view, if you’re designing the future technology estate of a large organisation, that last thing it makes sense to do in this kind of context is build stuff that depends on a desktop stack. Furthermore, decoupling legacy from the desktop stack also has to be on the agenda, because you just can’t count on that stack being relevent in 10 years time.

Most ELN products on the market are tightly linked into the Windows ecosystem, even to the extent that one vendor just trumpeted the re-launch of their ELN which is now completely based on SharePoint!

My feeling is that organisations looking for an ELN which is going to last for more than 2 years should consider a situation where there are more than just Windows Desktop PCs in their IT infrastructure – not an unreasonable consideration, but one that needs thinking about up front rather than purchasing a product that locks you in to a dying ecosystem. The Windows PC isn’t going to be replaced but it won’t be the only way you’ll want to access your ELN, and whatever you select needs to be able to work with whatever you might adopt. That such lightweight “thin” solutions are easier to deploy than a thick client just icing on the cake.

(update: this story has been picked up in The Register)

• Usability is the key to ELN project success.
• Usability almost always completely ignored, sometimes because project teams don’t realise it is important.
• However it is more the case that the project management process incentivises teams to follow a process and build a system rather than focus on the users.

I was intrigued by this post on User Experience in Startups. If you replace “Startup” for project in the first couple of paragraphs this surely rings a bell.

Startups Project teams start up with a single idea: a solution they believe the world their company has never seen. And while no one can argue that they’re the source of much of the industry’s innovation, they’re almost all lacking in purpose.

Most people believe that User Experience is just about finding the best solution for your users — but it’s not. UX is about defining the problem that needs to be solved (the why), defining the types of people who need it to be solved (the who), and defining the way in which it should be solved to be relevant to those people (the how). Yet as a rule, startups projects are being built on the what.

She then goes on to explore the reasons why, and again if you replace the words…

The challenge lies in the lifeblood of startups projects: the venture capitalists budget holder. Most VCs budget holders put their money in whats — not whys or whos or hows.

Hmmmm.

Requirements Gathering – a Broken Process

Project teams have been drawing up lists of requirements since the dawn of time, and since that first list the fate of a project has to a great extent been sealed the moment the requirements have been finalized. As a Civil Engineer my Father was always bemoaning the unrealistic requirements forced upon him by “dreamer” architects, a feeling that I suspect has dominated construction since the pyramids. I recall many a tale of tense ad-hoc negotiation on the construction site, and even the removal of troublesome architects from site entirely!

IT projects share a great many similarities with Construction, although a Civil Engineer has the advantage that she can point out the very obvious real-world difficulties (“You want me to build a roof of glass that large without any supports to spoil the view?”) whereas IT implementors often suffer from the perception that everything is easy. The progress in our field has been so rapid that our customers are used to apparent miracles, and of course there’s always the potential for distrust to arise due to the often large culture gap between the “Geeks” and “Normal people” – and that’s nothing compared to what people often think of Vendors and their dastardly sales people!

It is well known that IT projects can fail to meet expectations, and indeed some of the statistics on IT project success make sobering reading. Plenty of studies have shown the criticality of requirements setting in project success and indeed some practitioners (for example in the “Agile” and “Customer Development” movement) have gone so far as to remove what they perceive to be a very error-prone requirements setting step from their project entirely.

Unfortunately most large companies have purchasing processes which require the business to decide what they need, and then go out to the market to get the “best” solution from what they hope is a selection of competing solutions via a Request for Proposal (RFP) or other formal process. The need to maintain fairness to all concerned means the RFP process if often very rigid and leaves little scope for modification of the requirements in the light of the reality of implementation.

Therefore we are faced with a situation where a potential user’s desire to get the best possible solution forces them into a situation where they have to place almost total reliance on their up-front requirements setting process, an “Aim, and hope” approach which would be abhorred in another sphere of corporate activity. Who would design a process which explicitly prevented feedback from influencing the initial conditions?

And yet, we are here – to paraphrase Winston Churchill, the RFP process and it’s reliance on Requirements Specification maybe the worst way of purchasing systems but in today’s corporate environment is better than anything else available. In the spirit of making the best of the circumstances, this article will take the opportunity to make some suggestions and point out common pitfalls which so many implementation teams fall into.

The problems of requirements and the resulting issues in the RFP process are all the more critical for ELN projects because:

• The ELN replaces an existing paper process, which through the mists of time is often badly understood in itself.
• The term “ELN” can cover such a wide range of functionality and domains that in itself it is a foundation for confusion.
• Most of the current ELN offerings are still only “first generation” solutions which come with their own set of problems.

Thus an issue which bedevils all IT projects is often the founding cause of ELN project failure and requires particular attention.

Apparent “Solutions” which often aren’t

The difficultly in requirements capture/generation are apparent to anyone who has participated in such a project. A common approach is to hire a consultant, and when you get the right one they can single-handedly turn the situation around, although it does require the customer to listen! With apologies to the great consultants out there, the presence of a “consultant” leads to groans in the vendor community because (fairly or not) consultants:

• Are sometimes viewed as having an interest in creating long running complex projects, rather than quick productive wins.
• Despite having lots of industry experience, seldom get a long term view of a project. Often their involvement is restricted to the purchasing process, after which the vendor takes over. This gives them a rather one-sided view of the process.
• Need to get paid and that means making sure the customer is happy. Unfortunately sometimes the customer needs to be told some uncomfortable truths which might lead to them being “fired” as a customer – something a vendor with a large customer base can do, but very hard for a solo consultant to do.

Another approach is to “Stick with who/what you have and know” – for example, if you have an established implementation of SAP or a Document Management package, those solutions might be bent or tailored to meet the new requirements. Unfortunately this doesn’t remove the requirements generation pitfall, and leaves you with an expertise gap as domain-specific solutions ideally come with a vendor who spends their days working on a particular area, who can bring that expertise to bear both in the solution itself and the implementation process.

Some companies will already have an “ELN” deployed in one area, and there is a temptation to view this as being suitable for all kinds of science. This is a sad outcome of the rather generic “Electronic Lab Notebook” term, and is one of the primary reasons why we prefer to avoid the term in day-to-day use; “science” is by definition a very varied activity and you can’t assume that just because two different departments use the same Paper Lab Notebook, that a single ELN will work well in both places. Often all these groups will have in common is they both call themselves “Scientists” and work for the same company – hardly a basis for a common toolset.

It is important to note that these solutions – consultants, re-use of a horizontal tool, and a common ELN across multiple disciplines – aren’t in themselves inherently flawed and can indeed lead to a successful project. There is however a risk of viewing them as the solution to what is at heart a very tricky problem, and project teams who think they’ve somehow reassured themselves of success are often painfully brought back to reality. As the Financial Crisis has taught us, risk doesn’t go away by magic and sometimes the very approaches we take to remove it in fact just increases it, more dangerously so because we’ve stopped being sensitive to it.

Perhaps as Andy Grove says, “only the paranoid survive” and the ultimate key to project success is the recognition that any solution to risk reduction has the potential for problems in itself, often in ways you least expect it.

A Modest, Sadly Unrealistic, Proposal

This article has presented a bleak assessment of how most teams are forced by circumstances to approach their ELN projects, as well as pointing out some common pitfalls that requirements gathering processes fall into. Whilst the problems implicit in these approaches can’t be removed, I hope I have provided at least the opportunity for some reflection. In closing perhaps I might offer some suggestions which I know are unrealistic, but might one day mitigate the issues I’ve described.

One of the problems with an RFP process is the lack of feedback from the implementors; I am sure I am not alone in looking at some requirements and thinking “This project is doomed”. I for one would welcome the opportunity to answer some additional questions, such as:

• “If you could remove 5 of our requirements what would they be and why?”
• “What are the most expensive/troublesome requirements listed above?”
• “Which of these requirements do you think we don’t really need, based on your experience of similar projects?”
• “What are we missing?”
• “If you were us, what are the three things you would be most worried about going forward?”
• “Please rate our chance of success if we go with you, and if we go with another vendor, with reasons”

These questions would afford thoughtful vendors the opportunity to reflect and contribute their experience – after all, for all the conflict of interest that you might perceive in a vendor/customer relationship, a vendor only ultimately succeeds when their customer succeeds. Any vendor team is easily going to see ten times the number of ELN projects that any customer or indeed consultant will see in a year.

Sadly whilst all these questions are interesting I don’t know what project teams would do with this information! In so many cultures project managers are rewarded for following a process and thus any failure is blameless, any reconsideration a failure.

Other Approaches

One very interesting approach we’ve just experienced was where the prospective customer held an RFI (non-binding Request For Information) process which was rather like an RFP but held outside a commercial purchasing process. Crucially the RFI submission and scoring was then followed up with a 1 hour feedback meeting between the customer and the vendor team which allowed for a lot of constructive discussion which no doubt benefited both sides.

We have had good results from projects which have used a Six Sigma methodology with plenty of contributions from all parties – end users, management, IT departments, and outside vendors. This approach tends to be too “heavy” for smaller companies but has delivered great results in larger companies where Six Sigma is part of the culture.

This illustrates the final and most important point: a successful solution is the product of a partnership between everyone involved, and even the largest most process-driven companies reinforce this in their process. Perhaps the greatest danger lies in taking a very formal approach in the purchasing process without counterbalancing that with an up-front listening process – a trap that growing companies often fall into as they formalize their purchasing process without having developed the experience and resources to learn from themselves and the rest of the industry.

• Business drivers
• Comparing the different sectors and disciplines
• Build or buy?
• An overview of the solution space
• Patterns of success

There’s a few concepts in here which deserve their own posts (presentations are so useful for stimulating the creative juices!) which hopefully I can do over the coming weeks.

So many teams have over-specified what they want (because they are ELN geeks!), spent ages deciding to buy expensive software, and rushed out to their userbase with the result of years of effort – to be greeted with total apathy. Everyone loses in this case.

This is what I call the Toaster Problem – I just want toast. My wife on the other hand wants a work of art – which can produce anything you want as long as you have a degree in cooking. My wife is on the Toaster Buying Committee, and I am a humble Dad trying to get to work on time – huge difference in outlook, and sadly it’s the ones who aren’t on the committee who matter most for the ultimate business success of the project.

Anyway, I stumbled on the Parable of the Toaster which is tangentially related but will be amusing for those of us who have experienced the different mindsets which can populate our profession. Those lovely consultants…

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.

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!

It’s quite nice to have a Queen in such circumstances – she’s above it all (so there’s no finger pointing and has so much respect that when she asks people they jump. So when she asked the obvious question – why no one anticipated the Credit Crunch – a bunch of them sat down to figure out why.

The answer is very relevant. It’s why systems fail, Space Shuttles explode, companies fail, and in my particular interest – how a group of well meaning people in a company can fail in their quest to replace a Paper Lab Notebook with an Electronic Lab Notebook. From the article:

“Everyone seemed to be doing their own job properly on its own merit. And according to standard measures of success, they were often doing it well,” they say. “The failure was to see how collectively this added up to a series of interconnected imbalances over which no single authority had jurisdiction.”

Besley stressed that the experts had not been in “finger-wagging mode” and had agreed that the causes of the credit crunch were extremely complex. “There was a very complicated, interconnected set of issues, rather than one particular person or one particular institution.”

….. snip …..
“In summary, Your Majesty,” they conclude, “the failure to foresee the timing, extent and severity of the crisis and to head it off, while it had many causes, was principally a failure of the collective imagination of many bright people, both in this country and internationally, to understand the risks to the system as a whole.”

Lots of bright people. Complex problem, with interlinked components, dimly understood, with diffuse responsibility. Everyone working diligently on their own bit. It’s no ones fault – they all tried their best, etc.

Sounds very much like a lot of ELN projects . ELNs by their very nature are complex, span multiple areas of expertise, and require different parts of the organization to have conversations they aren’t used to having.

This is why we run “Fire Drills” – to get the customer’s organization to see the whole picture. Works very well. This overall perspective is one of the most valuable things we can bring to our customers, the result of an awful lot of interesting experiences in many different ELN deployments, across a whole variety of industries and company sizes.

Sadly we see a lot of ELN projects which are doomed from the very start, because they fail to appreciate and manage the complexity of what they are trying to undertake. I hesitate to say it, but I am inherently skeptical of any ELN project team, or indeed any consultant, who claims to be fully in control – these projects just aren’t that simple. If you think you know what you are doing, you’re probably just unaware of the problems which are going to seriously ruin your day.

For me, a healthy paranoia is much more encouraging as it shows respect for the challenges ahead. The Credit Crunch has “cost” each of us a mind-boggling amount of money and it would be a shame to lose the lesson.

I’m just about to give the following presentation at VIB’s Informatics Conference in Munich. Enjoy…

Using the two models to split the ELN problem up into different areas and data types, project teams can clearly see the different parts of the problem they face and how to tackle each one.

In cases where the demand for an ELN originates from Medicinal Chemists then clearly an ELN from one of the many vendors in this space will service that need, and as this is a relatively mature area of the industry a solution can be purchased in the traditional manner. However, teams should resist the vendor’s encouragement to view all scientists alike as non-chemists are unlikely to be well served by something that is primarily focused on Medicinal Chemists.

For Biology and other areas which don’t draw chemical structures, the demand for an “ELN” is often an expression of frustration by the scientists that they are using computers in their work, but are still forced to use a paper notebook. In that case, their needs may well be met by something that focused on the record keeping functions which are currently being performed by the paper notebook – an aspect rather inelegantly referred to as Patent Evidence Creation & Preservation (PECP). The scientists will rarely require any additional software but if they do it will be focused on particular niches – data management, additional workflow support etc. which will either be very specific or could easily be met with common software they probably already have as part of their standard desktop.

Most R&D organisations would feel a sense of discomfort if the possibility of “Silos” of information were to appear. Fortunately, PECP systems are by definition generally applicable and they can form the central repository of the organisation’s knowledge, available to all. A common PECP usefully reduces legal risk by ensuring common practices across the company, whilst freeing scientists to select their tools of choice without having to compromise as a result of legal considerations.

We need to stop thinking of an ELN as a single product, and more a system of parts integrated together. Some might fear the I (“integration”) word, but with today’s tools and sensible interfaces, it really isn’t a big deal. You can argue that cut & paste, or printing, are perfectly sensible integration mechanisms. I’m no fan of Microsoft, but when everything is on a common platform the only integration pain tends to be vendor pain/stubborness – and in today’s world Cash is King!

Not all of the “Stuff” sloshing around the lab is the same, and distinguishing between them helps tease out the best place to store things. We use a simple Triangle Diagram (originally proposed by John Trigg of PhaseFour which really just tries to point out that stuff is related, but it’s at different levels of abstraction:

It is quite hard to draw definite lines around things, but I think most people can appreciate that a raw data dump from an instrument is somewhat different from a report to management, or that an experimental write up in word is different from some tabular data in a spreadsheet. The differences between the levels come out in:

• The software that’s used to read the file and interpret the content. Some will require very specific software (e.g. from an instrument vendor), but a PDF or text file can be read by many different things.
• Who might be interested in the data. Again, some files are useful to anyone (for example, a report) but some only useful to certain people with specific training.
• How long your company might want to keep the data, and indeed how long you are realistically able to keep the data. Typically the lower you go, the harder it is to keep something, so if you feel it’s business critical you really need to pay attention to the formats used.

This differentiation can really help in ELN System design. Partly it draws your attention to what needs to be stored in the ELN (typically the “Experiment” write up level), and what can be left in systems e.g. a database or a file server, which can be pointed to from the ELN.

Not everything needs to be stored in the ELN, and indeed it would be unrealistic to expect to be able to do so. The important thing is common keys so you can offer the user a link to more information, and the advent of web-based systems has made this level of “integration” so trivial one sometimes feels a bit of fraud describing it as such.

By building on the storage tools you have in place, and focusing an ELN on Experiments, the resulting system is cheap to run, costs little to acquire, and results in little disruption to existing practices.

You can read the final part of this series here.

Most R&D organisations have more than one scientific discipline under their aegis. These groups will have developed their own suites of IT tools to help them do their work, everything from common desktop infrastructure to instruments and specialist tools. Some of these might be common to other groups, some will be very specific (and often unknown to anyone else). Meanwhile, the corporate-centric record keeping functions have remained in the commonly used Paper Lab Notebook.

“Broad” and “Deep” functions

The “ELN” question often arises when companies buy more and more IT to support the science, yet the only record keeping option is the paper notebook – a situation that generally arises because of the patent/legal issues around lab work in Discovery. Broadly, the the more computers you use, the more the paper notebook sucks – and to add insult to injury whilst you can search the entire planet using Google, the paper notebook is very much a “Write only” device!

The challenge for project teams is how to replace the paper notebook, and this is where splitting out what you mean really helps. Unfortunately most vendors have tried to expand the definition of “ELN” as far as possible which turns any project into a high-risk “do it all” venture, with an associated price tag.

By focusing on either the improvement of support for a particular niche or on replacing the paper notebook’s general record keeping process, projects can easily build on what’s already in place and achieve faster, more predictable ROI. Later projects run according to the same framework will by definition build on what’s already in place so there should be little scope for missed opportunities.

Vendor-driven approaches to use a single product for more than one area bring increased risk and often the promised cost savings are overwhelmed by the costs of replacing perfectly serviceable existing tools.

The next post examines what is stored in ELN systems, which is another useful way of looking at the ELN problem.

If the traditional large-ELN model no longer fits, what options are there for organisations who still need to find a better replacement for the Paper Lab Notebook? Fortunately, there are a number of concepts which have grown out of ELN deployments outside of the Life Sciences industry (which never had the money to afford “ERP for R&D”-style approaches) which can allow organisations to tease apart their requirements and clearly identify what they need.

Using these approaches, organisations can often achieve swift return on investment (often in a matter of months) for minimal outlay and vastly reduced risk. The more a project can focus, build on what’s already in place and solve the problems that need solving then it will by definition involve less of everything – less requirements, less code, less consulting, less change, and less money. Smaller, quicker projects are vastly less risky than larger ones, are easier to get approved, and allow the organisation to react easily to changing business circumstances. By building a culture of “quick wins” they lay the foundation for further improvements in tools.

The two models which help tease part the “ELN” functionality are relatively straightforward and indeed most thinkers in this space have their own versions. Their real power comes when they allow project teams to understand what they have and what they need, and develop a road map such that the future is protected even though the initial project may not have the widest possible scope.

We’ll examine each model in a separate post, first looking at ELN functionality and then what gets stored.

On to the next post in this series…

The problem with the term “ELN”

One of the problems that has confronted the “Electronic Lab Notebook” industry for a long time is the ambiguity of the term. Many a consultant and vendor has attempted to hijack the term with their own favored definition, complete with impressive diagrams in outdated and expensive reports.

ELN 1.0 started from the perspective of the suppliers – be they the vendors, or the consultants, or indeed the internal project teams. It was very much a “This is what we think you need” kind of approach, which led to a lot of worthy complexity which looked good but in practice got in the way of delivering the promise.

(For full disclosure, I was very much part of that group, and indeed the very first commercial ELN was written by me and others for Eastman Kodak – it was very functional but very complex. Then I led a Management Buy Out which created Amphora, and we had our own mini credit crunch which forced us to build something people could buy and use, not what we thought would be a good ELN!)

Today’s ELN 2.0 needs to focus on delivering value, and that means laser-like focus on the end user’s problem – which starts out something along the lines of “Since we bought all these computers, this paper notebook doesn’t fit with the way we work”.

ELN 2.0′s “End user first” approach doesn’t mean you end up with something that “isn’t a proper ELN”. What it means is you start focusing on the end user’s problems, prioritising them, and starting with the biggest wins first. Which is exactly what you need to do when there isn’t so much money around and everyone has become very risk averse. If we can do 20% of the work and get 80% of the benefit, doesn’t it make sense to do the 20% first and then look at where we want to spend our money next?

Interestingly this is directly against the interests of those who feel that a large, “fully functional” ELN is the only proper ELN. If we can deliver most of the benefit without the complexity, there’s no motivation to look further. So they have to bundle it all together and make the complex stuff appear necessary to achieve any kind of return. (for those who have attended my workshops, this is the “Toaster Problem”.

Differing needs

Some disciplines clearly benefit from a science-centric working environment which supports their niche requirements for example Medicinal Chemistry, and the considerable number of ELNs targeted at this sector is proof of the value that these solutions bring. The ability to draw structures and reactions, calculate properties, and structure/reaction-based search demonstrably increases the productivity of those scientists. Ironically, these solutions often don’t replace the Paper Notebook which is still required due to the concern that niche science-centric tool cannot provide adequate long term legal protection. However their value is only slightly diminished by the requirement to cut & stick into a Paper Notebook once the experiment has been completed.

For some scientific disciplines a gradual investment in IT tools, starting with a fairly typical desktop computer and then expanding into niche applications has provided them with all the tools they need to do their work. Once you deal with the legal issues, a lot of Discovery research looks a lot like any other kind of knowledge work and there’s a massive number of tools, sometimes already available to people for no additional cost, which can support that work. Indeed, one of the reasons the Paper Notebook is no longer suitable is that they are actually using those IT tools, and as a result a paper-based record keeping process is an unproductive overhead. Microsoft Office might not be blessed by the consultants as an ELN but it surely is the repository of more scientific thought and data than any “fully functional” ELN; that some products claim their similarity to, or integration with Office just reinforces the point! In these cases, project teams need to have a good answer to the CFO’s question “Why are you spending $1,000 a head to make Office harder to use?”

It is interesting to compare the health of the Medicinal Chemistry ELN market with the Biology ELN market, and indeed the discipline-neutral ELNs. Some have postulated that “Biology is next” and the approaches that work for a relatively homogeneous Medicinal Chemistry market will guarantee success in Biology. The implicit assumption is that Biologists have just been waiting for the ELN Gods to come and rescue them which rather implies that there are no biologists able to innovate in the same way as the chemists who developed the first Chemistry ELNs! A more realistic assessment might be that Biology is different – much more heterogeneous – which means the rise of a single Biology ELN is very unlikely. The adoption of the Biology-centric ELNs seems to be proceeding at a departmental level rather than the mass rollout to 100’s of scientists.

One size doesn’t fit all

Historically the ELN industry has been pushing a “One size fits all” approach, perhaps more due to the agendas of IT departments and suppliers. These projects are necessarily large, complex, and of course come with an associated price tag. With increasing size, complexity, and diversity of users also comes increased risk, and the success rate of such heroic endeavors has never been good. Projects of this type, which were always hard to justify anyway, are increasingly out of step with the new commercial realities. We just can’t afford to waste so much money stroking our “big project” egos – in today’s world, spending unnecessary money ultimately means there’s less money to spend on our own salaries.

If we want an ELN industry that’s healthy and can hold it’s head up high, we have to focus on delivering value, in a way that is acceptable in today’s environment. The subject of the next article in this series.

The past year has been “eventful” to say the least. So many long-held truths have shattered in moments, taking with them institutions who were meant to be the model of probity and longevity. Only a fool could pretend that the business of modernising R&D by replacing Paper Lab Notebooks is unaffected by such massive events, and it is perhaps useful to peer into the mist and see what the future might hold. It is clear the Electronic Lab Notebook’s time has come, but perhaps we need to adjust our sights for the new environment.

Warren Buffet said “It’s only when the tide goes out that you learn who’s been swimming naked” and perhaps the hidden blessing in reduced financial circumstances is a renewed focus on value. Successful projects will be more disciplined, surviving suppliers will be more customer-focused, and the products that succeed will be capable of delivering a predicable Return on Investment within a short time period.

It isn’t just a simple matter that there is less money around; for sure, companies which are exposed to the wider economic cycle are clearly hurting badly (the Chemicals industry is perhaps the most obvious); Venture-funded endeavours that planned to go back to the market for additional funding are having to close or sell out. Even for companies which are well-funded for a few years, the general climate of uncertainty is causing significant caution and search for value. Suppliers who had pumped themselves up on cheap speculative money, with the intention of selling large amounts of high-ticket software and associated consulting are being forced to make cutbacks as their sales pipes evaporate, and the resulting revenue loss reducing their ability to service the sometimes onerous commitments they have made to their existing customers.

Despite all this, the problem remains – Paper Lab Notebooks are no longer “fit for purpose” and an ELN can deliver well-documented savings in both time and effectiveness for any R&D-based organisation. The question is, how can we achieve this in a cautious, value-focused climate?

The answer goes right to the core of how we have been currently approaching the problem. Yes, you can tweak around the edges – most suppliers now have rental options which removes some of the financial pain (although the consulting effort required by many “fully functional” products is still onerous), and some have even started offering on-demand SaaS-style (Software as a Service) offerings. However, in an environment of such uncertainty much more needs to be done – how can you expect a management team to support an ELN project which will require 6 months of customisation before it even starts to deliver value, when no one is sure what the business will look like on that timescale or even if they will be in business? The answer goes right to the heart of our assumptions about how to approach the problem of replacing the Paper Notebook.

You can read the next post in this series here.

I’ve been thinking for a while about the impact of the Financial Crises and the ELN industry. I was asked to write an article on it and some of the proof readers suggested I take some time to expand on the various elements on the blog. So I will start a series of posts exploring what I feel the impact of the Credit Crunch has been on the Industry, and how we need to respond – what I think ELN 2.0 needs to look like.

Although the ELN blog world isn’t all that active, I’d be delighted if this sparks some discussion. The issues are important, and I hope my stance is suitably (but respectively!) provocative enough that others feel moved to make their own contributions.

You can read the first post here.

This is my first attempt at using SlideShare… hopefully this makes my stuff more accessible. Enjoy…

From the summary:

As you can see, the town did not fully understand that implementing an ERP system means changing and improving existing processes and ways of working. Many problem implementations result from the customer’s incomplete understanding about the extent of process change that will be required.

For small organizations such as Oak Park, this lack of implementation sophistication is quite understandable. After all, these folks don’t have a large IT staffing infrastructure and are not experienced with large implementations.

On the surface, it’s easy to blame the original system integrator as well as PeopleSoft. Both of these participants should probably have worked more closely with the town to ensure that process change expectations were clear and realistic. However, it’s entirely possible the external folks explained everything to the town, but somehow the information didn’t sink in.

Most likely, the vendors didn’t push hard enough because they wanted to sell software licenses and related services; at the same time, the town probably was caught up in its own hopes and didn’t listen sufficiently closely to advice from these vendors. Without more information, there’s no way to isolate original cause.

We know that our customers typically get their money back on our systems between 4 months and 1 year after purchase. That’s a very gratifying result, but the key is to make sure that’s achieved by all our customers rather than a few headline ones.

So we’ve worked very hard to get these kinds of project-related risks out of our deployments.

• Our product is focused, and battle-tested. Simple but not simplistic – exactly what’s needed to solve the problem, nothing more and nothing less. (it’s the bells and whistles that get you).
• We’re not above explaining hard truths to customers/prospects, even if that means we lose the deal – your not just buying our product, you’re buying our experience, too. Our interest is in a successful implementation with a happy customer, nothing else.
• We try very hard to fit in with what’s already there, minimising the disruption and increasing the benefits.
• Internally, our sales team reports to the Director of Customer Relations. Sometimes you see sales people say anything to get a sale – at Amphora, that would be career limiting and very noticeable.

I’m not going to claim we’re perfect but I’d hope we were at least not making the same stakes twice!