Fear not my friends… come next Friday you can have one of your own. :-

As anyone who has played with an oscilloscope knows, the 50Hz hum from mains power does show up at a low level pretty much anywhere and these make it through to the recording. It seems these fluctuations create a unique signature in time, and so they just keep a record of the power line frequency deviations over time. When they need to find out when a recording was made they can just match up the mains power fluctuations on the recording with what’s in their database.

Not majorly useful for our purposes, but a really interesting approach to authenticating evidence all the same.

In an article on 52 weeks of UX, exploring “The Distance Between Maker and User” the following principle is espoused:

As the distance between the maker and user increases, so does the difficulty of designing a great user experience.

This is our approach to usability – we make sure the Geeks are never too far away from the end user, and we achieve this in the following fairly simple ways:

• The people responsible for writing our products support them. We don’t have a support team – the guys helping our customers are the ones who you will speak to if you have a problem or need advice. This is probably the our effective way of increasing usability because not only do the developers get swift feedback on their decisions, they have an incentive to engineer out problems at source.
• We regularly review the kinds of issues we’re getting and see if we can make them go away entirely. Sometimes this is a re-worded screen, sometimes it is removing a step or component completely. I appreciate lots of vendors do this as part of a standard quality process, although we tend to do it in fairly tight feedback loops.
• We use the product internally. Did you know that PatentSafe makes an excellent financial records system? . Not only does that mean we have internal customers who deliver feedback every day, but the developers (and managers!) interact with our products daily. You’d be surprised how many little tweaks come out of this, things that customers probably notice but don’t think it is worth bothering us with.
• Our Sales, Development, Admin and Management teams are all co-located in the same office space, which means there’s lots of gentle interaction and sharing of context. It is interesting how often a problem in one area can be resolved in another. There are some problems with this because the different functions have different working styles (for example sales people switch context every 10 – 30 minutes, developers every few hours) but some simple informal rules make things easier.

Every time we bring someone new on board they are surprised that we aren’t more “formally” organised, but so far this setup has really helped us. It does mean we need to check that techies also have people skills, that our admin people need to be slightly more techie, and our sales people do need some involvement in the more geeky side of the shop. However it does seem to work very well for us, as demonstrated by the short training period that new users need to get up to speed with our ELN, and also the low volume of support calls we get (which apparently is very low compared to most software vendors).

Interestingly once new employees get over the initial shock of the proximity of roles, they really enjoy the richer environment it creates.

Having a small distance between the designers and developers is something that happened when we were a small startup, but I’ve come to view it as tremendously important for our ongoing success.

I’m intrigued how using an iPad causes me to think differently about user experience, and perhaps raise my expectations of what is a possible and indeed necessary.

I was reminded of this post on the ACM talking about “Why Features Don’t Matter Anymore” from 2006, where Andreas Pfeiffer talks about “the age of user experience”. He gives 10 rules about user experience:

1. More features isn’t better, it’s worse.
2. You can’t make things easier by adding to them.
3. Confusion is the ultimate deal-breaker.
4. Style matters.
5. Only features that provide a good user experience will be used.
6. Any feature that requires learning will only be adopted by a small fraction of users.
7. Unused features are not only useless, they can slow you down and diminish ease of use.
8. Users do not want to think about technology: what really counts is what it does for them.
9. Forget about the killer feature. Welcome to the age of the killer user-experience.
10. Less is difficult, that’s why less is more

We’ve just had one of our regular consultations with an Information Architect (IA) and even though we’ve attempted to keep PatentSafe as clean as possible, the results were enlightening. A fresh pair of eyes asking “Why are you bothering the user with that?” is always enlightening (and humbling!).

More features, especially when shoved in the user’s face, do not make for a better user experience. The user experience is one of the most important factors in the ability of any ELN project to deliver the return on investment it promised to stakeholders. That ability to deliver a return is a key aspect of any project’s success.

Interestingly we get two different reactions from customers when they look at our PatentSafe ELN.

• In the sales process we often get asked “Is that it?” in a rather disappointed tone when we’ve demonstrated the product – of course it isn’t but we don’t overwhelm people with features in the Demo – we talk about the things relevant to to their business problem. PatentSafe is designed such that you don’t have to wrap your head around everything to understand the positive impact PatentSafe can have on your life.
• Later when training, we get the same “Is that it?” but in a much happier way. Yes, with 15 minutes training and very little disruption to your existing workflow you can stop having to cut and stick, and move to a completely electronic world with all the benefits that brings.

One small anecdote might serve: We periodically survey our customers and one of the questions is “How long does it take to train your users”. One large pharma customer responded (slightly tongue in cheek I guess)

“45 minutes. 15 minutes to show them the system, and then another 30 minutes to convince them they already know everything they need to know”

Just because a product is powerful and can deliver a great ROI doesn’t mean it has to be complex. In fact, that’s the whole point of good design… I can’t claim we’re perfect but a good dose of Information Architecture really helps.

(most IAs work freelance – we are lucky to have worked with Karen Roles of Nidbe since we’ve started, and would highly recommend her to anyone. She delivers the sometimes painful medicine with a distinct charm… and you know it is doing you good)

So at this time the data portability situation in the ELN world is pretty awful. Which is a shame, and at some point people are going to start noticing – and perhaps the next round of ELN purchases will have open file formats as a purchasing consideration.

I came across the Data Portability project in this article on Tech Crunch which seems to be a really nice way of at least making the Data Portability issues obvious to consumers. They are starting off in the online web app area but clearly it is very relevant to any IT system, either cloud-based or on premises.

For the record, Amphora’s systems are completely open – our view is that it is your data and you should be able to take it where you want, when you want, without even having to involve us.

In addition, our focus on IP means we need to be able to reassure our customers that they can take a record out of our ELN and defend their IP long after their relationship with Amphora has come to a close – with a 50 or 100 year retention timescale, requiring the vendor to be around just isn’t acceptable (which is a big concern with services that claim to outsource IP protection, something I’ll blog on in due course).

We take this a step further in our Hosted/SaaS offerings, where customers can take a copy of their data (via rsync or similar) onto another server controlled by them every night. We also work with those customers to make sure they can spin up their own server as needed. This means that even where we’re Hosting them, they can tell us our services aren’t required and still have complete access to their data without any cooperation for us.

We believe that open data, neutral file formats, powerful APIs and above all a respectful policy to our customer’s IP are the cornerstone of any ELN vendor’s offering.

Our next web site refresh will contain our Data Portability policy. In the meantime I can only hope that as various advocacy groups get more vocal about the need for Facebook, Twitter and others to unlock your data, that will cause Data Portability to be given the consideration it deserves in the ELN world.

This is a really important point – you can have innovation, but if you can’t figure out a way to present it in a way that people will adopt and pay for it, there’s no way you can ever take that innovation out of the lab.

We have plenty of ideas kicking around, but it isn’t just about the technology. One of the reasons our PatentSafe ELN has the form and features it does is that we seem to have the sweet spot in terms of something we can sell to people, they can install, deploy and ultimately pay for. I’ve seen so many fellow ELN vendors come up with cool products (often received by much enthusiasm by self-styled industry watchers) which fail the “Can people actually buy & deploy this thing” test. You see plenty of marketing buzz, a couple of pilot deployments, and then it all goes quiet.

Having a good product isn’t just about feature count, it is about creating something that your customers can buy, they can install, and live with. Turns out that writing software is the easy part, creating a product people can buy and use after the marketing hype has died down is a lot more interesting.

We’ve always had a very straightforward model; because our Electronic Lab Notebook needs to know about every user to do its job (every user needs to be uniquely to sign and witness their entries), it is easy to just charge for the number of users which are enabled on the system. Fairly straightforward.

We do have a slight complexity in that we split PatentSafe functionality into modules, so you can have cheaper licenses for people who just want to read, or people who just want to submit and sign stuff, etc. We have assigned “points” values to these functions, and customers buy a certain number for their system which gives them a lot of flexibility.

Sometimes we’re asked about concurrent pricing but that request generally comes from an IT dept who are (quite reasonably) looking for ease of administration and don’t realise every user is going to be setup (automatically or otherwise) with a PatentSafe account anyway. Concurrent licensing wouldn’t help anyone in our use case.

We do have a mix of perpetual and rental options in our licensing structure; this accommodates customers who have capital and want the reassurance of owning something (generally larger more established customers) as well as making enterprise-grade solutions attainable to companies who might either be short of capital (being VC funded and at the end of a round) or unsure of their growth curve.

We don’t do anything silly in terms of copy protection; it just adds to pain for the users, and ultimately support pain for us! We don’t even lock a system to a particular number of users – PatentSafe just points out how many users you have and we trust our customers to have that many licenses. We also don’t charge for test servers, although we do make a small additional support charge if you want production-level support for an additional server.

I guess we are unusual in that we’re a records system which is intended to go into court at some point, so we can trust our users to do the right thing in terms of having the right number of licenses. This level of trust makes everything easier, and interestingly means users are more trustworthy back – in all the years I don’t think I’ve ever heard of a reason to be worried that a customer may be exceeding their entitlement.

I know some software companies view having a complex licensing structure as a sales tool but I’ve never found it all that attractive. We’re providing and supporting a tool which will benefit a customer’s organisation, and the question is how to fairly measure the value we provide and hence should be compensated for. We’ve found the easiest and most reliable way to do that is count up how many scientists we’ve freed from the drudgery of the Bound Paper Lab Notebook, so that’s how we price the system. Simple, transparent, predictable – and fair.

Interestingly treating our customers like adults means they act like adults; and the relief expressed in the sales cycle when the realise we’re straightforward to deal with is quite gratifying! I continue to remain befuddled as to why more companies can’t have understandable pricing schemes – I can’t see how complexity helps the vendors or the customers.

Whilst there are considerable differences between Academia and Industry (as indeed there are between Biotech and Pharma) I have to say I find the challenge of implementing an ELN in an academic environment quite refreshing – the constraints are such that you really have to think carefully about the human side of things, as well as ensuring you can do it all for a cost that will fit into whatever money a lab might be able to find. So far we’ve had an excellent response which is quite gratifying, and I the less buttoned-down culture is a lot of fun.

So I was greatly amused to see this satirical data management plan, ostensibly in response to an NSF request. Of course one of the reasons why it is so funny is that it is rather close to the mark!

Getting a decent data management process and associated ELN implementation in such an environment is perfectly possible, and we can often do it without inflicting too much pain on the individual researchers. Fact is, scientists became scientists because they liked science, not record keeping! Fortunately I think the tools have finally got to the stage where despite the relentless increase in computerization and resulting data volumes, we can make the record keeping side of things as transparent and hassle-free as it needs to be.

In a move that I take as more of a sign of weakness, Adobe have placed an advert in the press basically saying they love Apple, but Apple are being unreasonable.

I can’t improve on TechCrunch’s thoughts this whole thing. Adobe have painted themselves into a corner and I suspect Flash is a dead end technology. They’d do better to admit that and move on, rather than flailing around like so many other failing businesses – the Flash franchise wasn’t as strong as they tried to make out (being dependant on a plugin being installed), they overplayed their hand, and Steve Jobs called their bluff.

UK pricing from Apple’s Press Release: £429 (inc. VAT) for 16GB, £499 (inc. VAT) for 32GB, £599 (inc. VAT) for 64GB for Wi-Fi models and £529 (inc. VAT) for 16GB, £599 (inc. VAT) for 32GB and £699 (inc. VAT) for 64GB for Wi-Fi + 3G models.

There’s also rumored Euro pricing here.

Aside from all the really interesting philosophy stuff which might give insight into the design decisions Apple have made, my interest in the iPad and ELN is as follows:

• Finally we have a practical device which allows access to “The Cloud” in a magazine form factor.
• They’ve sold 1m in the first 28 days, with supply restricted to the US. There are no credible alternatives announced. This is Apple’s segment to lose at the moment. If you want The Web in your hand, Apple is the place.
• Because it is in consumer space, pricing and volume are almost commodity-like.

It might not currently be positioned as an enterprise device, but the above make it viable to evaluate. Turning to the ELN:

• It has a proper web browser on it – no compromises (except for the lack of Flash – but HTML5 is here). The keyboard is ok ish and you can always use an external one – but it isn’t intended for content creation, really – this is a consumption and annotation device.
• It is relatively cheap so accidents won’t break your heart. But it is sturdy enough for kids… it isn’t an executive toy.
• Apple’s control-freak side mean this can be one of the most secure devices around.
• You can use it in a plastic bag, with gloves etc.
• Which makes me wonder – is this a hint of what we need to take the ELN to the science?

It isn’t perfect, but for my money it has earned a decent evaluation. It doesn’t replace the laptop, the desktop, etc. – but it does fill a gap which opens new possibilities. This is version 1 and I wouldn’t go out and buy them for everyone in my lab just yet, but I’d buy a couple and use those to understand the impact.

My conclusions so far are:

• If you get one and take it home, be prepared to get one for your significant other. It is the only way to maintain harmony. Having said that, I rarely get to use mine when my children are awake, and I don’t know how to solve that yet (I am not getting them their own!).
• This is a content consumption device, with the ability to annotate and make small contributions. It won’t replace your computer as the place you write.
• Applications – web or otherwise – need to be re-visited in the light of the iPads characteristics. Straight ports won’t work.
• The ecosystem is still settling down, you can tell that people have written apps not having seen the UI metaphors everyone else use. I suspect it will take at least 6 months for things to settle out.
• This really is very interesting. I suspect it could be as profound as the the introduction of the Mac.

This post is interesting as an insight into what Apple are probably doing with the iPad. This is more about changing our entire relationship with computers than merely the choices they’ve made for this one device.

If you haven’t seen it, I covered some more about this on the morning before the possible iPad release in my Chairman’s remarks at the SMI ELN Conference (this was just before the iPad announcement – apologies to my dinner companions who had to suffer my addiction to Twitter that evening!).

We’ll also have a couple of iPads with us if people are interested – we think this class of device has great potential in Labs.

The future of our industry now looks totally different than the past. It looks like a sheet of paper, and it’s called the iPad. It’s not about typing or clicking; it’s about touching. It’s not about text, or even animation, it’s about video. It’s not about a local disk, or even a desktop, it’s about the cloud. It’s not about pulling information; it’s about push. It’s not about repurposing old software, it’s about writing everything from scratch (because you want to take advantage of the awesome potential of the new computers and the new cloud—and because you have to reach this pinnacle). Finally, the industry is fun again.

It’ll be interesting to see what the iPad and devices inspired by it do for the world of ELNs. Clearly Marc’s got a very cloud-centric perspective but the success of Salesforce.com (which he launched when Enterprise software was very much a 3-teir world client/server affair) does mean he’s worth listening to.

But perhaps the real issue here is our application-centric view of laboratory systems

Which I very much agree with. So many projects start out not looking at their problem but instead “What ELN should we buy?”. When the terms we use such as “Electronic Laboratory Notebook” and even “Laboratory Information System” cover such a wide spectrum of potential functionality, starting out that way without being clear about what you are trying to achieve is a recipe for failure.

When we meet people for the first time we always ask “Why did you make time to see us?”, and hopefully they tell us the business problem they are trying to solve. If they answer “Because we’re looking for an Electronic Laboratory Notebook and you are an ELN vendor, show us what you do”, we find ourselves asking questions like “Why do you want one?” and “What do you think one will do for you?” which helps us to get to the root of the issue.

You’d be surprised how many people who tell us they want an ELN (and are quite certain about that!) but in fact have a problem that doesn’t need one – they might just need to use their existing software in a different way, or buy something like an SDMS or a LIMS.

I know that the traditional sales school says you should immediately “re-engineer” the prospect’s “vision” to suit the features of your product, but in my experience that rarely leads to a happy outcome even if you do manage to make the initial sale. If the end users didn’t need one, then just because the organization went out and bought one, and the vendor’s salesperson convinced them to buy his (plus the consulting time to aid with the inevitable painful implementation) it doesn’t mean the project is going to be a success in terms of achieving a Return On Investment.

From my perspective (as a technology implementor, not a salesperson), the sales process is where a potential customer and a potential vendor communicate and establish if what the vendor has to sell is going to solve the business problem the potential customer is prepared to spend money to solve. That often involves clarifying what the real problem is, before we get into solutions.

From the vendor side that means being willing to say “That’s not us, why don’t you go talk to these guys”, and from the customer side that means talking to us about the business problem you need solve, not what application you think you want to buy.

Once we understand a business problem, then if appropriate we can show how our ELN might be able to solve it. But not before. This sometimes upsets people who want us to just come in and demo, but surely the idea of the sales meeting is to have a productive outcome, and requires communication? Which is why we like to ask as many questions of prospective customers as they might ask of us, as strange as people find that.

I’d rather have a meeting where after 10 minutes we mutually come to the conclusion that there isn’t a fit, than labor with on each side pretending there at some point might be a happy outcome. If we communicate well at the first meeting, it means if things do go forward there’s a high probability of success all round.

(This approach of finding out people’s business problem and telling them if we aren’t a good fit did cause problems with our sales team until we changed their focus and compensation to be biased towards “happy customers” rather than just “make sales”. A small but important tweak which really helped the quality of the business, but still raises eyebrows when we recruit new salespeople.)

There’s some seriously interesting times ahead for all of us and being able to have a separate corporate voice will hopefully make it easier for me to engage thoughtfully without having to consider the implications of what I write from a company branding perspective.

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!).