I wonder what the company going through the RFP process thought about this refusal. Ideally they would take it as a possible warning sign that there might be something in their project that needed attention (e.g. executive sponsorship) and also with this supplier not participating they wouldn’t get the overview of the market they (or their management) were hoping for. As a project manager, as soon as I got this I’d call up the supplier and at least have a chat with them to find out if I it was in my interests to make some changes and get this supplier back on board – if nothing else, they’ve shown integrity.

Then again a lot of RFP processes are just going through the internal motions and the preferred supplier is already pre-selected, or in actual fact there’s little chance of the project going ahead. So this response was probably just noted and the process continued as planned.

We’ve declined to participate in RFPs before although not in quite such eloquent language! Sometimes that’s because we’re not a good fit and we said so and wished the project well. More often it was because we saw structural flaws in what they were trying to do, and in almost every case we’ve later heard on the grapevine those projects have subsequently hit serious problems.

Sadly, I’ve never been contacted to ask why we felt it wasn’t in our interests to proceed – perhaps running a proper RFP process is more important than a successful project, so there’s no point in finding problems and fixing them before they doom the project, because that would violate the sanctity of the RFP process!

I’ve often thought about blogging my thoughts on the various RFPs that come past, so that even if the issuing company isn’t interested at least other people might avoid similar problems. Feels a bit wrong though (washing their dirty laundry in public even though it would be anonymous), and I haven’t figured out a way to do it that feels right.

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.

Human progress happens at 4% per year, averaged across many fields, ranging from 2% to 7%

How interesting! I wonder what the state of play is for ELNs…. I suspect we’d like to think it’s something like 10% or 20%, but I fear that if we took a good look at what’s really going on, it would be somewhat lower! One of the problems we currently face as an industry is there’s too much marketing spin in our communications and not enough real understanding of what’s going on.

I’d like to think at Amphora we’re on the realistic side – replacing the Paper Lab Notebook is a hard problem and we’re only going to get better if we pay attention to the whole problem and are clear-eyed about what’s really happening. Geeks at heart, we run a lot of stats about the performance of the business and customer experience and it produces really thought-provoking insights.

It isn’t just about the product, there’s lots more involved to the customer experience – from the sales process, pilot & training, commercial packaging, infrastructure requirements etc. all have a significant impact. Interestingly from a product perspective it is often more about what functions you leave out rather than making a complex mess, which does take a lot of discipline. For example we were recently eliminated from an RFP because we didn’t meet a “mandatory” requirement but we’d prefer to lose a deal than bend PatentSafe in weird ways which would lead to a more complex product which was harder for everyone to use. Purity of design is a good thing (yes, we’re Apple fans!).

In this post he explains how it all took off:

After I retired, I began teaching Customer Development, a theory of how to reduce early stage risk in entrepreneurial ventures. The first time I taught the class at the Haas Business School, U.C. Berkeley, I had a few hundred pages of course notes. Students began to ask for copies of the notes so I threw a cover on them and self-published the notes as a “book” at Cafepress.com.

As a pun on my last company as an entrepreneur, E.piphany, I called the book The Four Steps to the Epiphany.

Two years later, Eric Ries mentioned that I could list the book on Amazon. I never imagined more than a few hundred copies would be sold to my students. 15,000 copies later, the horrifically bad proofreading, design and layout is now a badge of honor. You most definitely read the book for the content. (Congratulations to all of you who actually managed to slog through it.)

I love how a mixture of blogging, self-publishing and easy distribution mechanisms have allowed an idea to start from something quite small, to finding a larger community, to becoming a movement.

Hopefully the eBook movement will make it all so much easier….

Some thoughts on the first day of SMI, which I chaired.

As a general note, I think it’s important to calibrate any of these case studies against:

• What industry is the person in
• What department they are speaking from
• The kinds of science they do (throwing around words like “Biology” and “Chemistry” aren’t precise enough
• Their legal and regulatory environment
• Their level of IT and business sophistication

If you don’t do this you can take entirely the wrong message away from these talks!

I never quite know what to do in “Chairman’s Opening Remarks” but given it was the day of the Apple iPad announcement (which started at 6pm that evening, London time) I just spoke a little bit about how I felt “consumer” devices were going to have an impact. Presentation here.

Mike Kopach from Eli Lilly talked about their ELN implementation, which has been a popular talk at many conferences. This is now a pretty mature ELN installation and just seems to work, which is excellent.

Jo Mulgrew from Pfizer is responsible for their ELN in Sandwich, and gave a really interesting talk on all the tools and techniques they use to smooth the rollout of their ELN. This wasn’t so much about the ELN as the implementation process, and I know we learned a lot from this. Their use of short (1 or 2 minute) screencasts was particularly interesting.

I talked about the “ELN Landscape”, the slides for which are here. I’ll be expanding on some of the themes on my blog in due course – it’s interesting how having to write a presentation causes you to crystalise stuff which you then have to summarise in a single slide but could easily do a good post on.

Jeremy Frey from Southampton University gave a really interesting on what they’ve been doing with blogging – not so much about the technology but how it all works in a science setting. Jeremy gave a talk last year and things have moved on a lot, I’m still distilling it all but I guess it’s a vindication of the research grant process that they are doing really interesting stuff and I’m trying to figure out how to translate some of their insights into an industrial setting.

After lunch we had two talks on the legal side. Colin Sandercock of Perkins Coie talked on the US issues, and then Matthew Dick from Bristows talked about the UK & EU perspective. Although this is my primary area of concern in my “day job” I continue to find these talks interesting and the compare & contrast was quite stimulating. The legal implications of SaaS are still being worked out so and I think that it will become a bigger topic for next year.

We then had a panel discussion on “Pitfalls to Avoid in implementing ELN”. I must confess I really dislike the panel format as a chairman because you’re so often left in the situation where you don’t get good questions, and there’s an embarrassing silence. So to spice things up a little bit we had a quick Google Wave demo, and then a 2 minute talk from each of the panel on “The one thing…” – and the discussion flowed quite well after that.

For those who were there, Jo has just about forgiven me for making her stand up at the podium

Finally Antonio Gomez from J&J talked about their home-grown ELN solution which has been discussed before and continues to evolve. I think what J&J have done is really impressive both from a technical and business standpoint and there’s lots of practical lessons there (Oh if only they could blog!). Disclaimer: I have a commercial relationship with J&J who use PatentSafe as the records/patent solution for both their Chemists (integrated with their ELN) and Biologists.

That was it – the evening was spent in the bar & restaurant with me sitting on Twitter watching the reactions from the Apple announcement and everyone else politely ignoring my geekish excitement.

Hope that’s useful. I didn’t manage to attend the second day unfortunately but perhaps someone else can comment.

With regard to “bed behaviour” particularly by Sales & Marketing personnel, I’m afraid I’m one of those naive people that believe open conversation spurs creativity, and if people act badly they’ll just look like idiots to the very people they are trying to “impress”. As long as there’s transparency it tends to self-correct.

However, I realise that only a few of us are willing or indeed able to Blog, so forums such as LinkedIn groups definitely have a role. There are a couple of ELN groups on LinkedIn, one’s pretty quiet and the other is somewhat stifled by rather outmoded policies.

So I’m delighted that a more open ELN group has been setup on LinkedIn – you can join it here and I would strongly recommend you do.

Here’s the group description:

This group was set up to provide a place where all can discuss content free from restrictions.

By joining this group you are agreeing to allow other group members to make comment on your discussions free from any risk of litigation or lawsuit. This means other members are free to make reference to trademarks and express their opinion positive or negative. The only recourse is to answer their discussion. Abusive replies will be removed.

Content from this discussion should not be referenced elsewhere.

Innovation requires uncensored discussion.
So feel free to discuss anything related to this topic in here.

I really like this approach, the only quibble I might have is “Content from this discussion should not be referenced elsewhere” which is going to be really tricky in practice – good ideas and discussion spread, that’s the whole point. But I’m sure we’ll have a discussion about it .

FYI the group was setup by Andrew Lemon who runs The Edge, producers of BioRails which is on my list of “interesting things to look at when I have time”. So guess he’s a fellow supplier although I’m not sure we compete that much – we briefly met at a conference once, but apart from that I have no relationship with him. I’m just pleased that someone is doing something to enhance the quality of conversation in the industry because we urgently need to something to improve the success rate and ROI of ELN implementations.

• 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.

Anyway, you have to give a 10 minute presentation talking about wider industry issues and I thought it was appropriate to draw people’s attention to what’s happening in the consumer space and how it might bring us towards the original vision of an ELN.

I’ll blog more on this tomorrow (after the Apple announcement today!) but for the moment here’s the presentation….

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…

(as an aside, we generally prefer to sign mutual NDAs rather that one-sided ones – just as a matter of mutual respect – we’re both bringing something of value to the conversation, surely?)

Having said that, whilst I believe we’ve done a really good job in PatentSafe replacing the corporate aspects (record keeping, long term records etc.) of the Lab Notebook, scientists still need a place to work. Sometimes that’s a discipline-centric product (sometimes badged as an “ELN”, sometimes something else), sometimes Microsoft Office and other general Knowledge Worker tools.

Looking forward I can’t help but think that tools like Google Wave and WordPress (especially with 2.9’s nifty features) are the long term future. A lot of vendors have “Web based” ELNs which are nothing more than their thick-client products wrapped in a browser – which I’ve always felt is cheating.

But when you look at what people are doing with web-native UIs these days…surely the next generation of Scientific collaboration products are going to come from the blogging or Web 2.0 space, with a little chemistry added to the mix. They’re cheaper, easier to use, easier to deploy, and often more powerful than a typical thick-client “Enterprise” app – and I suspect they’re more capable of dealing with large-scale use than any of the commercial products on offer at the moment (the lack of scalability being the dirty little secret of most ELN deployments right now).

All these tools need – apart from some open mindedness – is a decent record keeping system. Which we would be happy to help with

What an exciting time…

I’ve written about my frustration with the RFP process before – I have a more detailed post provisionally titled “Why starting with an RFP dooms your project to failure” but wiser heads than I tell me it needs a little more work before it can be published

Anyway, I bumped into this article which talks about the RFP process from the salesperson’s perspective. Here’s some of the things they’ve observed about RFPs:

First is that there is a disconnect between Procurement and their customers (called users). Often times, Procurement authors the RFP and establishes the measurement criteria for evaluating the submissions. However, when you speak to the actual user, they say that the criteria developed by Procurement is inconsistent with their needs. Thus, a supplier is selected for a user based on flawed criteria.

Another thing you should know is that an RFP is not necessarily a commitment to make a change in provider. Some companies require that they source the business every x amount of time. Ever wonder how that RFP got in your inbox? Procurement will surf the web and pick a handful of providers to whom they will send the RFP and off it goes. It helps to know that Procurement folks are measured on their ability to reduce cost to the company. Just like a sales person’s scorecard is based on achievement of their sales quota, Procurement’s quota is based on cost reduction. The RFP that arrived in your inbox could very well be their attempt to put the squeeze on the current provider so they can show a 10% savings. Don’t kid yourself. This happens a lot!

One final thing you should know about RFPs is that they are sometimes used as a manager tactic. For example, some people are too nice to tell you ‘no,’ so they hide behind the statement that their company only buys through the RFP process. Don’t buy that for a second. No company exclusively buys this way. Even the Federal Government, who is the most formal buyer, does not limit their purchasing to this means. Sales people, present company included, sell products and services to the Feds without an RFP being issued. It can be done!

Which resonates with our experience – very few RFPs actually produce a purchasing decision, and it’s often more an exercise in internal politics for the prospective customer.

The article goes onto suggest an approach to dealing with RFPs which is consistent with our approach, with the one proviso that generally if we didn’t hear either through our sales contacts or the industry grapevine that the RFP was coming then we generally politely refuse at the outset – if the customer has issued the RFP without any prior investigation into the market then the chances of a successful project are near zero, so we may as well sit out the first round of ELN purchasing attempts.

The sad thing is I suspect people inside the issuing company are as frustrated with the RFP process as the vendors who receive them. With a few exceptions, it seems to be such a futile exercise in negativity – “Let’s not actually talk because you might screw us, or we might make a decision in a way that can be criticised later”.

Oh well.

Basically SaaS is not a magic bullet for enterprise apps, the problems associated with large complex software can’t be magicked away just because someone else runs the software for you.

Our hosted products and SaaS products are identical, as is our deployment methodology. I’d like to think we’ve put in the design time to ensure that deploying a replacement for the paper notebook is as painless as possible. That’s the result of experience and careful design, which I hope produces the same results regardless of how it’s deployed – on premises or SaaS. That some of our customers find purchasing our products as a Service is more a matter of convenience and economic preference.

“McAfee’s Hypothesis: Within organizations, collaboration technologies are dictated by the most powerful person involved in the collaboration.”

This discussion will start out with identifying the many forms of information we create and use, and the needs of those doing the creating and using. It would then move on to how best to share this information within our organization, and with our customers and partners in a secure manner. Our mental model will be the most well-known computer network – the Internet.

I really quite like this. I think The Internet has a lot to give in terms of sources of inspiration and it’s sad that the Lab Informatics market has been rather knocked off course by an obsession with a paper artefact rather than looking at what’s really going on.

I’ve always felt fortunate that we’re operating in one of the few “Green field” markets for IT systems. I thought my age would condemn me to working on incremental IT projects, as opposed to all the fun my predecessors must have had in the 80’s and 90’s going into manual processes and achieving quite amazing business impact by automating them.

Perhaps what’s happened is our generation have forgotten some of the basic system analysis skills that our Dads used?

Regardless of the cause, I strongly suspect if the Paper Lab Notebook didn’t exist we wouldn’t have come up with the concept of an Electronic one. Which does make you wonder how much more effective we could all be if we focused on the real problems scientists and their companies have?

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!