At CloudOne, we focus a lot on helping companies get Rational shelfware off the shelf and into use - but I thought it might be good to explore some of the reasons why this happens.

A few core observations to start:

  1. At many companies, software development is not a centralized function, but instead is distributed throughout the organization's business units.  This means that if you're working for an insurance company, and they have a claims department, it's very likely there are people in the claims department maintaining and building software for processing claims.  This is as opposed to many other IT functions, like e-mail, data warehouses, workstation management and the like which are highly centralized.
  2. The usage of software development tools is highly cyclical, meaning that there's not an even usage from the start all the way through it's lifecycle.  This is as opposed to many other infrastructure IT tools like web application servers or databases, where the usage level is generally known in advance or is highly predictable.  Development tool usage varies directly with the velocity and resourcing of the projects that are applying the tools.
  3. Quite frequently software development tools are sold as a financial-based sell, rooted in return-on-investment calculations and anticipated future projects, vs. known, documented technology needs or existing staffing levels.
As a result of these tendencies, companies can get into a position where a central IT organization or procurement group makes a large purchase of development tools, only to find themselves in the position of needing to "resell" them out to divisions and departments where the actual users reside.  Because the purchase is often based on anticipated vs. actual need (#3), and the actual needs are rarely known in advance (#2) and the users of these tools are in other organizations outside the purchasing group (#1), the result can often be large stockpiles of software sitting, undeployed - better known as shelfware.
Software development is not the only area of software that is subject to these issues.  The same thing tends to happen for collaboration tools (for exactly the same reasons), project management tools, new desktop tools - anything where large groups of users need to be encouraged to adopt the decision of another central group about what software they use.
So, certainly, when CloudOne gets involved we can set up virtual private clouds, which speed the delivery of the software to the distributed groups, and we can provide managed services which offloads the burden of managing this software from understaffed teams.  
But, the real secret to solving this issue lies in other areas:
  1. Decisions about distributed software should be made collaboratively and with support and input from those who would use the tools.  Sort of like taxation without representation, it's important to get the buy-in before making the purchase.
  2. Those responsible for selling software should be as concerned (or more) about deployment success as they are about sales success.  Ultimately they are the losers when the customer is unsatisfied or refuses the upgrade or maintenance because the software remains undeployed.  
  3. Users should look first to see what is already owned before becoming excited about what is new and shiny.  Chances are there are economic and implementation speed benefits from helping someone else deploy in your department what they purchased before.
Would love to hear your thoughts.