Enterprise Software Pilots in a Social Age

I’ve been thinking about sales processes and specifically how they should change as the types of solutions we are selling into enterprises change.  For example, the traditional first step to an enterprise software deployment (and the near to last step in the sales process) would be to do a controlled customer pilot.  Sometimes these are free and sometimes they are paid for but almost always they involve rolling the product out to a small set of users and tracking a set of pre-defined success metrics.  If the pilot meets the goals, the next stage is to move the product into broad production use.

Should enterprise software pilots change or stay the same as enterprise software makes use of more social or collaborative technologies?  Michael Idinopulos has a great post on the Social Text Blog that makes a very good argument that for Enterprise 2.0 applications, it makes sense to skip the pilot.  In that post he makes the point that the business tasks enabled by traditional enterprise software (transfer funds, purchase products, track inventory were his examples) do not vary with the number of users on the system.  He then makes the argument that Enterprise 2.0 applications are very different because they are more “interaction” based rather than “transaction” based.  He states:

Interactions and transactions have completely different scale
economics. When we use Enterprise 2.0, we’re not transacting with a
system; we’re interacting with other people. An interaction is a
connection between two or more nodes in a network. And as Metcalf’s Law
famously states, the more people there are in that network, the more
interactions each individual can have with his or her peers, and the
more value that individual derives from participation in the network.

Regardless of how you define an “Enterprise 2.0” application, I believe we are now moving into an age of collaboration and communications-enhanced business processes.  As our customer management and supply chain processes become more connected and start to really support collaboration, it would seem to me that our traditional model of doing a pilot has to change too.

I don’t believe that enterprises are ready to do major deployments without a pilot stage but maybe what we need is a new type of pilot that allows enterprises to contain the risks associated with a broad deployment while letting the user-base form organically enough to expose the range of ways that people will collaborate within a broad population. Ultimately this may result in doing pilots where the restriction is more around advanced functionaility and less around restrictions on numbers of users.

First time reader?  Subscribe or follow me on Twitter or Friendfeed

14 thoughts on “Enterprise Software Pilots in a Social Age”

  1. Interesting post. I agree we’re probably moving in that direction.
    The problem is that the effort required on the part of the vendor to do an extremely broad deployment as a “pilot” is going to mean that either the customer pays big $$’s to do it or the vendor eats big $$’s to do it. Someone will have to take on the additional risk.
    Justin

  2. Hi Justin,
    Thanks for the comment. In a traditional deployment you’re right, the burden on either the customer or the vendor is going to go up. If it’s a SaaS deployment, I’m not sure the scale matters as much as long as you can turn on/off features.
    April

  3. Good post April. What’s worked for me in the past is to engage customers as early in the process as possible. This can be at the product level or at the feature level – whatever you feel requires customer engagement. If you can get them into the process at the concept stage and move them through storyboards, demos, hands-on, etc. then the odds of meeting the success metrics at the end of the project are pretty good – thus eliminating the pilot. The key is to have a network of customers willing to be engaged throughout the process and good two-way communication with them.
    Other benefits as a result of this are that (a) customers are familiar with the new/improved feature/product, thus reducing the training requirements, and (b) reference customers may be quicker to acquire because they’ve (hopefully) fallen in love with what you’re delivering to them.

  4. Hi Peter,
    That’s a good point – no vendor wants to do a pilot so if you can get them closed without one, more power to you. For certain kinds of enterprise software though, I don’t see it being avoided. CRM being the big example in my head.
    Thanks for the comment.
    April

  5. Pingback: Larissa Gaston

  6. Pingback: Vincent Sortino

  7. Pingback: Stephanie Tilton

  8. I actually think the great thing about a trial for an Enterprise 2.0 software product is that to be successful, it **needs** the involvement of the wider community that will contribute content.
    While time consuming to set up and get the community to be involved, if the product actually adds value to that community, the community will be up in arms when the trial ends and access to the software is removed- what more compelling reason is there to buy?

  9. LOL – yes that IS off-topic! I’d need to spend more time thinking about it and frankly, I haven’t spent enough time on Squidoo to have an opinion. On the surface it would seem like an interesting why for brands to get engaged but I agree with TechCrunch that the price point seems awfully high. I will add it to my list of possible future blog topics…;-)
    April

  10. I totally agree with you that from a customer point of view there is great value in doing a broad scale “pilot”. The question I keep coming back to is whether or not you can get away from skipping the pilot altogether. Maybe we just need a new word for “pilot” in that case and I really like your word for it – it really is a “trial” at that point more than a pilot. In my mind there’s a stronger commitment from the customer in a trial than there is in a pilot.
    Thanks for the comment!
    April

Leave a Reply to April Dunford Cancel Reply

Your email address will not be published.