Introducing New Software Technologies Into Large Organizations

An anonymous comment on my McGovern vs. Ruby Community, et. al post  (the actual comment is on the old blog, not here) asked the following:

One perspective that seems missing is that the success or failure of Ruby is primarily based on sneaking it into the enterprise under the radar as a tactic. Would love your perspectives on this technique.

Well anon, you're in luck as I have had the pleasure and pain of introducing various forms of new or open-source software technology into large organizations, but as with anything, there are various constraints to work within not only from technical perspectives, but organizational ones as well.

First, a couple of words about enterprises, er...very large organizations. As has been noted by many in the blogosphere, the disrespect of enterprises and architects (astronauts?) shown by various Rubyites in response to James' posts indicate the following:

• There is a huge difference between small software houses and startups and IT in very large organizations that, for example: provide financial and insurance services; build and sell automobiles; make and/or sell a wide array of consumer products; and furnish governmental services at the federal and state levels. Obviously, this difference in size and scope alters IT fundementals substantially.
• Some of the Rubyites opined that enterprise architecture is a waste regardless of the organizational and IT situation involved. A number of bloggers correctly countered those absurd claims by explaining the following attributes common to large organizations which indicate that an architecture function is necessary: compliance; regulation; existing law; transparancy; huge complexities in business, process, etc.; risk - both management and avoidance; legacy systems; data issues; etc.
• Still other Rubyites have had actual experience working in large organizations and, for whatever reason, didn't like it. All well and good, but that doesn't change the fact that these behemoths are huge, have many, many billions (with a 'B') of dollars in cash flow yearly, and generally operate on a global scale. Because of their huge size, they aren't going away anytime soon, and whatever they do (or not) cascades down to other organizations like suppliers, dealers, retailers, etc..

So, what does this mean in terms of introducing a new technology into the enterprise? Here's the fundemental point: you can't and won't be rolling out any new technology, whether from a vendor or open-source on an enterprise-wide scale all at once. Even large ERP and supply chain systems, if they're going to succeed at all, get rolled out incrementally. Big-bang rollouts, in my experience, have too high of a failure rate. I always advise against them in any event because the complexities and risk are too high to roll the dice in such a manner.

So how do we introduce a new software technology into big businesses? The obvious path from what I wrote above is: incrementally with enough successes over time for the technology to gain traction from the point-of-entry outward into the rest of the organization. If the introductions don't succeed for whatever reason, the overall risk and cost to the organization is low.

There are a number of methods one can utilize to accomplish an introduction as I list below. Depending on the specific circumstances involved, some or all of these may not apply to a given situation or need to be altered and finessed as needed to work properly. As such, I give these as general guidelines and your mileage can and probably will vary...

1. A specific project is necessary up-front. Without a goal state, such as one that a specific project provides, the new technology will be viewed by others primarily as a tool or toy to be fooled-around with and not much more than that. A properly-sized project with support of someone who matters on the business-side is critical to success because sooner or later, a business case is going to have to be made to embrace the technology. Sound obvious? Well, I've seen more than a few evangelists go down in flames when making attempts like this because they couldn't get enough backing to achieve proper traction with the technology.
2. Select the right project. Forget about doing some massive roll-out to hundreds of thousands of desktops in one fell swoop. Ain't gonna happen. The much better project candidate is very small, say, for example, the refactoring of some sundry Excel or Access application used by 5-15 people in a department. This is the perfect "fly under the radar" project for a number of reasons, and a key attribute is that the application has to be very important to the folks that will use it, but not so huge and complex that the risk of failure is too high for people to properly digest. If it isn't, you will be spinning your wheels.
   
3. Use agile development whenever possible. Your chances of successfully introducing new technology into a large organization is proportional to the amount of time and effort it takes to build and deploy. That doesn't mean you hack together something with no planning, but it also doesn't indicate following an ornate, complex development process with substantial documentation tonnage.Think small team, agile techniques, quick hit, test/QA well, and get the project out there live so people can use it and prove its worth to both the business and IT.
4. Promote to the business. You're going to need a business sponsor or champion to make this work, and without it, you're done before you start. Let me be straight up: there is a fine line between promotion of a specific technology and evangelism. The latter gets termed 'hucksterism' if the project doesn't succeed. You'll need to find a way to indicate the advantages to the business in terms that they understand, not your fellow IT folks (see #5 below for dealing with IT). Some possible avenues for 'selling' this to the business are: shortened development time, quick feature changes, web-based interface, etc., not frameworks, interfaces, objects, and other technical minutae that, while important, matter little or go over the heads of the business folks.
5. Promote within IT. You have a similar selling job to do with IT, but its the reverse of what you sell to the business and there are nuances that you must pay attention to. Not only do technicalities and minutae matter, but you're going to need support and help from certain people in your IT organization to succeed. Your boss is a good start, and those in a position to give you the resources that you'll require are also. A lot depends on how rigidly controlled your development and production environments are, and the higher level of control, the less the chance of flying under the radar successfully. The exception to this is the ability, assuming it exists in your organization, of setting up 'rogue' development and production environments but even then, you can't do it alone. The number of people I'm thinking about here is small, but they have to: a) believe this is worthwhile doing; and b) be in a position to run interference for you, secure necessary resources, or preferably, both.
   
6. Build and deploy it anyway. There are certain organizations where its possible to get away with 'just doing it' and deploying the project using new technologies, as long as it doesn't disrupt mission-critical production systems. In my previous post about a legacy architect, "Dr. No" in that tale routinely said 'no' to various technlogies and systems we wanted to implement, but the IT and business culture allowed us to do it anyway. Most of the time, such projects succeeded and the technologies involved were, in time, assimilated into mainstream development. If this is characteristic of your organization, your chances of success are much greater than those where total control (whether by committee or imperial management) of one's activities is practiced.
7. Shout out successes. Once you've successfully deployed, its time to come out of the closet and trumpet the success throughout the organization. You want both the business and your direct management involved in this because the new technology now needs to...
8. Gain Traction. One or two project successes with a new technology won't matter much if the effort stalls out shortly afterward. Now that the new technology is out in the open, it has to be assimilated and used by others. This means that it now must become part of the standard development environment lest it die on the vine. Your promotion activities in items 4 and 5 above aren't finished, but most likely expand to other areas of IT and the business. A good place to start would be with your CTO and/or architects (if they didn't become involved at some earlier point).

What I hope I have presented here are a number of perspectives in getting something in under the radar, and there is not one all-encompassing, sure-fire method of doing so. You also cannot do this alone, which is why coalition-building with certain players in IT and on the business-side is so important.

Comments

[tatiana]

It's just a glimpse on a very complicated process,but with very clear guidelines.

[tatiana]

It's just a glimpse on a very complicated process,but with very clear guidelines.