Riding the Winds of Change

analysis
Jun 22, 20073 mins

Sometimes it can be really difficult to get changes made in your company. And most of the time the more important the change is, the harder it is to make it happen. However, there can be a way to get things done that lights a fire under their butts. One technique I like to employ when the opportunity arises is to wait until something big happens and then ride the skirt of the aftermath to get my change made. Her

Sometimes it can be really difficult to get changes made in your company. And most of the time the more important the change is, the harder it is to make it happen. However, there can be a way to get things done that lights a fire under their butts.

One technique I like to employ when the opportunity arises is to wait until something big happens and then ride the skirt of the aftermath to get my change made. Here’s a recent example… I wanted to reduce the rights of this one generic accout in our DB so that we could put the DB in dbo only mode during our maintenance. The problem was that we can’t get our maintenance done because processes keep logging on to do run reports. They were ruluctant, and it was a fight, but I finally got it done. Now, now even 2wks later, we had problems with our ETL and it was running several hours behind. We’re actually doing our best to get it done, so we’ve got the DB in dbo only mode again… and guess what… that generic account won’t be interfering with ETL because I took those rights away. Currently, everyone is thrilled that we don’t have to worry about the extra usage on the box while we’re trying to get ETL finished. So misison accomplished.

To that end, I’ve also wanted to limit the access of all the users. Everyone has way more access than they should, and I’ve been trying to find a way to bring that up for serious conversation. Well, since I was right about this one, then if I strike while the iron’s hot, I should be able to get them to listen to me about the others too. I’ve got good solid logic behind me, so I’m not going in there unprepared. But timing is everything.

Another good technique is to use data collection. Whenever you have a production issue, you have to determine the root cause. Well, record that info with dates, and details. Now, whenever you’re ready to go to management with your change, you have actual numbers to back you up. I’ve documented that 45% of our production issues come from people making unauthorized changes in our DB, so if those rights go, we should see a dramatic decrease in production issues. You can’t argue with numbers. Don’t get me wrong… I know they still do, and those are the battles you just can’t win. Sometimes all you can do is all you can do… but at least you’ll have more ammo than you would otherwise.

So collect your info, and hang off the skirts of disasters and you’ll have a lot more success.