If anyone who works outside the IT department suggests moving to the cloud, they may actually be criticizing IT. One reason behind this may be IT’s time to market, or how long it takes to get a new application up and running. Here’s information you want at your fingertips to manage this issue.
Imagine that the marketing department develops the idea for a new product or service and brings finance and manufacturing or similar departments onboard to develop it. (If you have a real-life example to collect information from, that’s even better.) If the product or service requires support from the IT department, they bring IT onboard. How long does it take marketing, finance, manufacturing, and other departments to develop what’s needed? How long does it take IT? Does marketing have to wait for IT to catch up (or do they think they need to)? How long between the first twinkle in the marketing VP’s eye and the time IT is brought onboard? How much time does IT have to evaluate and contribute to the product design in order to contribute more than just order processing and invoicing? Have new product launches ever been delayed, waiting for IT to deliver?
If you don’t have these answers, you will want to study two issues. The first is how you can improve your communications with other departments. This might be as simple as talking to the other parties on the subject of time to market and your role in it. Or, this might require longer-term relationship building or your inclusion in strategic planning sessions. To improve communications with other departments, you will want to know details about IT’s time to market.
And that will take you to the second issue: Once you know your time to market, how can you improve it? As Peter Drucker, the father of modern management, has suggested, you can’t manage it if you don’t measure it. If you don’t have statistics on how long IT takes to develop and deliver new applications, get them. Modify your application development process to measure both time to market and its components. Then bring in your best systems analysts to speed up the process.
They will likely break the application development process into component steps (perhaps including data gathering, requirements analysis, functional analysis, coding, testing, documentation, quality assurance, delivery, maintenance, and others).
Next, they will likely use standard systems analysis and structured decomposition to break these into sub-components and identify methods to improve speed. The methods might include overlapping or reordering steps, eliminating steps, reconfiguring steps (think of factoring in algebra class), automating steps, fine-tuning steps, staffing changes, and other techniques. The result should be an improved system development lifecycle. (If your team recommends the use of agile development to speed the lifecycle, take extra care that sufficient controls are in place to maintain quality and scheduling. Agile development success very often depends on the extremely high quality of all the team members and ruthless adherence to agile procedures.)
Test the improved approach on a non-critical application. You should now automatically receive statistics on time to market for this application. Apply what you’ve learned to your own considerations of the cloud.
Now to get more benefit from this exercise, take what you’ve done and apply it to arenas other than time to market. For example, do you have at your fingertips statistics about application problems? Which applications fail most often? What are the most common causes of problems in applications? How fast and how well does your staff resolve serious application problems? What are the trends of these numbers over time? What does marketing think about the number and significance of application problems? (You can’t manage problems if you don’t measure them.)
To get the most benefit from this exercise, and returning to our starting point, consider all the reasons other than time to market for going to the cloud. (Please refer to my September/October 2011 Mainframe Executive column, which listed these reasons.) Apply the approach described previously to each of these reasons. Then you will be ready to talk clearly when other people talk vaguely about the cloud.