This blog was guest written by Greg Hubbard. Greg is the Director of Application Development for Q Interactive, a Chicago based digital marketing services company.
In a previous post about Cloud Computing I discussed the barriers within technology that make it difficult to get a Cloud Computing prototype moving. After a small scale technology proof of concept has been done, the next step is to get something exposed to a non technology crowd and into production. How is this accomplished?
- Show Value
- Minimize Negative Impact
- Get It Done Fast!
Show Value
Improving something intangible like user experience or department process unfortuately is not an attention grabber. We want someone to pay attention to what Cloud Computing can accompish and for this purpose numbers, especially ones related to money, are best
even when the numbers are relatively small. The idea is to walk into a meeting and say "We're going to replace four servers with a cloud solution. On the server replacement costs, warranty contract and data center charges we'll save $30,000. Not bad for a small test is it?" While large numbers are flashy, most companies could find uses for a suddenly available 30k like training or hardware replacement.
Minimize Negative Impact
When introducing something new, the goal is to not scare the natives. Abrupt change or changing something that people consider very important is difficult especially if that something is unstable. While an unstable application would seem like a good target, especially if you offer to fix a few problems, people would rather deal with the sometimes working devil they know than the devil in the Cloud that they do not. Also, don't use a system or application that has a large monetary loss if it is unavailable or does not work as you expected. If downtime for a specific application costs hundreds of dollars per minute, find something else. People are very cautious about making changes to systems with expensive downtime and rightly so. Most companies have internal applications that have grown important enough to support and make redundant, but not so important that if it were down for an hour it would cause a problem. That's the application to find and use.
Get it done fast
Everyone likes to improve, re-engineer or re-imagine. However when you open the improvement door to change the proverbial "just one thing", scope creep and its associated delays begin. Changes to existing functionality require extensive development time and significant amounts of quality assurance. A better approach, that takes much less development and QA time is to merely move an existing application. You want someone to say "What do you mean the TPS system is in the cloud, it looks the same!" The other benefit to getting it done fast is that by the time someone wants to weigh in on, control or attach their own agenda to your test, you're done.
While it is always nice to make a big splash when trying new technology, it is better to quickly do something valuable to the company while minimizing risk. This gives you a success on which to build.

0 comments:
Post a Comment