Authority -> decision -> action -> results

"Most of our obstacles would melt away if, instead of cowering before them, we should make up our minds to walk boldly through them." - Bear Grylls (on Twitter)


Don't find fault. Find a remedy.

Today Bear Grylls posted these six simple words to twitter, and lots of people, including me, re-tweeted them. What is so significant, or perhaps resonant is a better word, about this idea?

Finding fault is often associated with blame, appointing a scapegoat, and generally negative outcomes. Alternatively, focusing on finding a remedy often relies on cooperation, collaboration, communication, and more positive experiences and results. While I fully agree with Bear Grylls' philosophy of finding a remedy BEFORE finding fault, there is also value in understanding exceptions, faults, or mistakes so that we can learn from them and not repeat them.

In IT, and especially as ITIL best practices have become more prevalent, the priority is emphasized on resolving incidents and getting business clients / customers back on track and working. But when you step back and consider why the incident occurred to begin with, it is helpful to consider the cause or the "fault".

In my career I've spent significant time, energy, and effort producing valuable results on determining probable or root cause of IT service exceptions. Any time something unexpected disrupts normal IT infrastructure operations - something we often refer to as an exception - it has the potential to negatively affect users and/or customers. In worst case scenarios this can include real impact to reputation or profits. Business leaders recognize theses risks to reputation and finances, and want to know what will be done to avoid or mitigate a repeat occurrence.

In order to understand how to avoid another costly incident, we do indeed need to identify the fault or the root cause. There are good frameworks available - including ITIL and MOF - to guide a team through the discovery and investigation processes. There are also numerous software companies that provide a variety of tools to automate and accelerate these processes. One element I believe is essential to success in these endeavors is capturing the early details of the incident and thorough records of how it was resolved. The goal is not to identify anyone to be reprimanded, but to objectively understand - as precisely as possible - what transpired so that it can be corrected.

Finding fault in software or a system is ideally done before it "goes live", but that in practice that doesn't always happen. If we work together to quickly uncover what happened without fear of blame or repercussion, we can partner with others to find a remedy while simultaneously learning what lead to the "fault" so that the cause can be clearly documented and remediated.



From Server Admin to Supplier Manager

I thought Alan Le Marquand did a great job of identifying distinctions between the various IT service delivery models (SaaS PaaS, IaaS) that are becoming more popular, and how the associated IT roles will likely need to change.

I think a longer title could have been "From Server Admin to Supplier Manager", as the emphasis for IT Pros managing cloud services will be on measuring and managing ISPs and service providers. I think these role adjustments will require entirely different soft skill sets. I'm interested in your commments and feedback on how you see these affecting the IT profession and your career in particular.

Here is an excerpt and link to the original article:
From Servers to Services. The Role for the IT Pro in the Cloud | Media | TechNet EdgeThe looming question for IT Pro’s regarding the cloud is “What is the future for my role?” Simply put, no one can say for sure. There are many factors to consider when ...


New PowerShell scripts to share

I had a recent project where I needed to brush up on PowerShell, and I didn't find any other scripts shared online for my specific issue, so I thought I'd share what I came up with.

It's not particularly complex, but hopefully someone will find it helpful.


I put GetDataSet.ps1 together because I needed to be able get SQL records from an ODBC data source. I had read the System Center Central post on connecting to SQL with PowerShell, but it seemed like PowerShell has some built-in Microsoft SQL Server support that didn't apply to other data sources. I found a basic template PowerShell script for ADODB (ActiveX Database Objects) on the Hey, Scripting Guy! blog at TechNet. I had to customize the connection string for my specific ODBC driver, and I tried to leave this shared version of the script generic and commented so that you can tweak it for your own situation.


Another PowerShell script I use fairly regularly is checkProcess.ps1. It started as a basic kill process script, then I added the ability to more gracefully close down certain applications. After a while I realized I was also periodically starting some of these same apps, so I updated the script to be able to start them as well. One of the latest enhancements I owe to another System Center Central post, by Tenchuu, clarifying how the PowerShell count property behavior can change based on context. If nothing else, working on this script gave me excuses to work on nuance in PowerShell like checking arguments, write-progress, and declaring data types.

If you try out either of these scripts, let me know what you think by adding feedback to this post or using the Contact page.


Blog neglect

I've been quite busy with my latest job, and I have not made time to update this blog/journal.

The good news is however, I've jumped in with both feet to the social networking and micro-blogging world, so you can still find out what I'm up to, if you're so inclined. I try to keep my various accounts connected, so feel free to pick your favorite. I probably work directly with twitter the most, but that also gets aggregated to Google Buzz (and vice-versa). I try to keep Facebook focused on my personal life, and LinkedIn representative of my professional self.

If you have any questions or feedback for me, I'd love to hear from you.

Thanks for checking in, and take care!