Monthly Archives: March 2012

From Prototype to Production

A lot of organizations that we work with want to start off small with a prototype to see how the product works and how users react to it.  This is a great way to start and we are usually quite successful at getting things set up and the users are off and running in a day of two.  The pilot may run for 30, 60, 90, or even 120 days.

Turns out that the prototype is usually the easy part.  Where we see most organizations struggle is how to take what is working for a small segment of the population and rolling it out to the entire organization.

Interestingly, technology is not the problem.  Databases can handle the extra volume, in a virtualized environment extra CPUs and memory can be easily added when necessary, the networks are already in place, single sign on solutions exist, and services can easily be integrated into additional front-end applications.

So why is it so tough to go from a prototype to operational capability?

Many times, the prototype is done within an organization that does not control the corporate IT infrastructure.  Although successful, there must be “buy in” from the corporate IT team.  Without this “buy in” it’s often difficult to get their support to deploy the solution across the enterprise.  Otherwise, you are just bringing them more work to do. Don’t forget that they may have been looking at another solution or may be understaffed to handle the additional resources that your solution requires.  And who is going to fund that?

Even if you have the IT department on board, you still have to convince the other users that this is a worthwhile effort.  They may like the current tool that’s being used, or may have tried another one at home that they like better.  It does not matter if that is realistic for a corporate solution, they know what they want.

Starting with a prototype is a great way to see if the technology works.  You should ensure that you get the IT department on board as soon as possible so they can begin to understand what is required to scale across the enterprise.  Then you have to realize that you still need to work with each user organization to get their buy in.  To help bridge this gap, make sure that you include members in the prototype group that reach as many organizations as possible.  Select the users that actually influence the users in the organization. It’s possible that they may cause risk to the success of your prototype; however, if you can convince them chances are they’ll easily convince their peers. Once you deploy the prototype to the enterprise and  you begin to scale, others will naturally join in -especially in a collaboration capability.  You’ll be amazed at how quickly the system will expand.

Migrating Users to a New Collaboration Environment

People are creatures of habit and it is often difficult to get them to change.  If you have ever tried to introduce an new application into an enterprise IT infrastructure or even a major change to an existing application you know just how hard that can be.

Case in point with collaboration.  Many people we work with already have an existing collaboration tool that they want to upgrade to take advantage of more advanced features or better integration with their infrastructure.  The question then becomes, how do you transition users to a new collaboration tool?

If you control all of the tools in the environment you can integrate the new collaboration capabilities into the user experience and shut down the old system.  Users will automatically move to the new system.  This is the approach that we discussed in our earlier blog Apple Computer’s 25 Billion iTunes Downloads and Your Collaboration Solution.

What if you do not control the entire environment but  want your organization to transition to a new collaboration capability?  Teams are already working in the existing tool and some people may resist moving to the new collaboration space.

One approach is to integrate the collaboration tools together using the one of the standard collaboration protocols such as XMPP or SIMPLE.  Again, this assumes that those controlling the existing collaboration environment are willing to allow your new system to connect with the current system.  If so, then users of your new collaboration software can see and collaborate with users of the current system. Overtime the collaboration capabilities from the new system can be integrated into additional applications and migration from the current system to the new system will begin.

How about if you those controlling the current system are not willing to enable this connectivity?  In that case, you need to select a group of users that can work easily in both collaborative environments or select a group that can work independently on a problem.  Once the group is identified, begin converting them to the new functionality.  They will either need to work completely independent of those in the current tool or they will need to work on both tools to bridge the gap. As this prototype group begins to experience the improved capabilities of the new tool, they can go to the users of the original tool and explain the benefits of switching to the new tool.

Both of these solutions may take more time, but once the transition starts, more users will attract their existing teams and critical mass will eventually bring everyone over to the new tool.