Interop – Principles of Effective IT Management

This post is part 2 in a 3-part series. Check out the first post if you haven’t yet.

I want to review a workshop I attended at Interop Las Vegas in May called Principles of Effective IT Management. It would be tough to recap all my notes from the 2-day workshop in blog posts, simply because they’re so exhaustive. I would however like to highlight a few of the key takeaways, at least from the perspective of my experience and current situation.

We Are a Value-Add, Not a Cost Center

One of the main precepts that came up again and again was that of providing value to the business. “We are definitely not a cost, we are a value,” Tom Randall kept reminding us. Most businesses have a tendency to treat IT as a cost (both as viewed by Accounting but even just as a general feeling), and it’s completely in opposition to the way we should function. But beyond simply convincing the rest of the business to see us “properly,” it also affects the way we treat ourselves. If we just consider everything as a cost, we’ll be driven in decisions and approaches by the simple dollar amount — the bottom line — more than we should. When we think of ourselves as providing value — regardless of the dollar amount — the way in which we spend those dollars becomes considerably more impactful.

He also had this wonderful nugget to share, regarding the trend towards consumerization of IT and so much hardware: “It was a lot easier when what we did was effing magic.” So true.

Stewardship Reports

Tom mentioned one concept that, while it almost seems obvious, was new to me. He recommended sending what he termed “Stewardship Reports.” These reports should probably be weekly, and they would contain simple metrics on what the IT department has been up to lately. Include volume of work, time spent on tickets, and benefits to the users. This is not so much about dollars spent or dollars saved, but about letting your users know what you’ve been up to! Far too many users — either ignorantly or cynically — don’t have an accurate concept of the work that goes on in IT — until their workstation is broken, of course — and this is a friendly mechanism to help them understand.

As an IT department of one at my current job (as well as my last), this isn’t something I’ve implemented yet, but I’d like to consider it for the future. I’d love to hear if you’ve implemented something similar (or your company’s IT department does something like this). How do you like it?

SLAs

We spent quite a lot of time discussing SLAs — Service Level Agreements. While to some this is a very familiar concept, I’ve been noticing more and more how many contracts are lacking SLAs. When you’re a vendor and have a service problem, you become quite grateful that your clients didn’t think to make you include an SLA in your MSA (Master Services Agreement)… this has crossed my mind a couple times in the past couple weeks for a couple real-life experiences at work. I’m not going to go any deeper into those though.

But from the IT department perspective, including SLAs in your contracts with vendors is so absolutely critical. At a very high level, SLAs “guarantee” a certain level of service (uptime, speed, I/O, etc.) from that provider. But in reality, the provider should be trying to provide this level of service anyway… what the SLA provides in essence is a way to receive monetary compensation from the vendor should they fail to meet the agreement. While money can’t always truly compensate for downtime, lost business, and unhappy customers, it can certainly help. And it can motivate the vendor to perform.

There’s another way to consider SLAs. As an IT department providing service to the business — whether that’s standing up a server, building an application, or even just responding to Help Desk tickets — having an SLA in writing within your own company can go a long way to ensuring not only a level of service from your IT staff, but also accountability. Plus, this helps encourage buy-in from the business, ownership of the project, and a greater trust that the project will be taken seriously.

This post only covers a very small portion of the topics covered in the 16 hours of the workshop. As you can see, there were many great ideas and plenty of great conversation about them.

Finally, I want to leave you — without comment — this list from the very end of the workshop. It’s something I try to review frequently as I consider my own professional growth.

Tom Randall’s Top 10 Requirements of a CIO

1. Leadership
2. Expertise in aligning & leveraging technology
3. Business savvy
4. Relationship skills
5. Management skills
6. Communication skills
7. Ability to create & manage change
8. Knowledge of or experience in specific industry
9. International or global experience
10. Ability to hire, develop, retain high-quality IT pros

On to part 3 in the series…