"Success" in an IT operations space means that you've avoided all the problems. And usually, IT people avoid the problems in ways that mean that management doesn't know about them. And what they don't know about, they cannot see value in.
Allowing failures is one way to establish the value of IT operations, because that is guaranteed to get management attention, but it's the kind of attention that will only benefit your successor because clearly *you* can't handle the job.
So you need to educate your management.
What can go wrong? These are the risks.
What happens when a risk becomes a reality? This are called impacts.
What are the odds of the risk becoming a reality? This is the likelihood.
Take the list of impacts and get management to rank them. Dollar impact, or just "Very Bad/Bad/Annoying/Don't care"
Then you take your risks and likelihoods, and you build a map. High impact, and High likelihood means something ought to be done. Low Impact, Low Likelihood, and nobody really needs to care.
Once you've done that, you have a map that shows your current state. So now, show what you can *DO* about the high end issues. So by hiring a backup guy, you guys are covered if you get hit by a bus. By developing a disaster plan, you guys will ready for a hurricane hit, or a terrorist attack. By getting IT involved in the development/requirements process, you can get extra time to qualify technologies or select software, or you can help them understand which requirements are real, and which ones are for a mauve database, and avoid the situation last year where they wasted $50k on a package that nobody used.
Ultimately, it's about showing non-trivial and sustained value, just like any other part of a business should be operating.
Presenting Risk in that kind of format is a very easy way to get people to understand and accept that value, as well as giving them next steps for how to make it so. (Just make sure your map looks out over years or else you're justifying a one-time effort instead of an ongoing group.)
Also, sometimes doing that kind of risk assessment shows that it just doesn't matter enough. At which point you can accept status quo or not.
Slashdot Mirror
Allowing failures is one way to establish the value of IT operations, because that is guaranteed to get management attention, but it's the kind of attention that will only benefit your successor because clearly *you* can't handle the job.
So you need to educate your management.
Take the list of impacts and get management to rank them. Dollar impact, or just "Very Bad/Bad/Annoying/Don't care"
Then you take your risks and likelihoods, and you build a map. High impact, and High likelihood means something ought to be done. Low Impact, Low Likelihood, and nobody really needs to care.
Once you've done that, you have a map that shows your current state. So now, show what you can *DO* about the high end issues. So by hiring a backup guy, you guys are covered if you get hit by a bus. By developing a disaster plan, you guys will ready for a hurricane hit, or a terrorist attack. By getting IT involved in the development/requirements process, you can get extra time to qualify technologies or select software, or you can help them understand which requirements are real, and which ones are for a mauve database, and avoid the situation last year where they wasted $50k on a package that nobody used.
Ultimately, it's about showing non-trivial and sustained value, just like any other part of a business should be operating.
Presenting Risk in that kind of format is a very easy way to get people to understand and accept that value, as well as giving them next steps for how to make it so. (Just make sure your map looks out over years or else you're justifying a one-time effort instead of an ongoing group.)
Also, sometimes doing that kind of risk assessment shows that it just doesn't matter enough. At which point you can accept status quo or not.