This is kind of a longer rant, so I'll break it up. Given my somewhat unconventional approach to IT, it is probably not surprising that I wasn't always an IT guy. I have really had several careers, and those experiences, plus a couple of strong mentors along the way have formed my approach. More or less in order, I spent eight years in the US Navy (Submarines), three years in commercial nuclear power, three years as a small business owner, two years writing technology sales proposals, and 12 years in software quality.
At the last place I worked (by acquisition, not by choice), the IT group was horrible. They we not the least bit interested in helping the business move forward. All they cared about was compliance with their policy and procedures. Those procedures were often at odds with the needs of the business, and even though I would find folks in the IT group that agreed with me ("You're right, it is stupid") no one was ever willing to work to change the rules. This was quite the shock, as prior to being acquired, we had an IT group that was pretty supportive of the business.
I was senior enough to have contact with enough of the executive team to know that I wasn't the only one that thought IT sucked, but that it was a common perception. The thing that struck me as odd, was that everyone seemed to believe that you had to live with it, and that big corporate IT just sucked by its very nature, and that all you could do was squeeze their budgets so at least you could pay the minimum for their suckiness.
I was convinced that IT could be done better. It was my belief that if the business felt they were getting good value for their $, you wouldn't be getting squeezed at budget time. Hence, the IT Rocks! theory of IT management was born.
The first day I had responsibility for IT here, I met with my ops director, and talked about how I wanted to approach our delivery. In that first meeting I had two things I wanted to start on right away. First, my new, single metric, if you can call it that, by which I was going to judge the team, was customer satisfaction. How I would measure it, was simple; if I asked any employee in the company, from the CEO on down "How's IT?", the target answer was "IT Rocks!". Minimal acceptable was "They are pretty good". The second thing, and the most important thing in achieving the first, was to stop saying no. No matter what the request, if we thought the answer had to be no, I wanted a good analysis of why, and if it was just because of some policy of ours, I wanted justification of that policy. I even went as far as to say that the only person in IT that could say "no" to a request, was me.
The ops director came just short of laughing at me. It could best describe it as a strong mirthful grin. He said I was nuts, and that he would play it my way, but seeing that I was his fifth boss in three years, this too would pass. As I have related this story to some of my peer CIOs, many have said that that approach can't possibly work. How on earth can the CIO review every request? The reality is that I don't think I even had to review one in the first six months. It was obvious to the team that I wanted them to say yes, so they spent a lot more time understanding what our customers really wanted, that is the problem they were trying to solve when they made the request, and then offered alternative solutions that we could do, instead of jumping straight to "no".
I'll exapand on this more about how it has evolved over the last four years, but the bottom line is that it works. IT does rock. The business loves us. I do not have to fight for budget (there is an interesting budget side effect of IT Rocks that we'll talk about later). Not only does the business love us, but we have added real value, streamlining systems and process to drive more revenue and greater operational efficiency.
Friday, July 30, 2010
Wednesday, July 28, 2010
What does a good enterprise architecture get you?
Why, a good enterprise architecture, of course. Never mind that a good architecture is no guarantee that your IT environment will have any relevance at all to the business.
I presented at a recent CIO conference on our use of cloud computing, and the first slide in my presentation was a high-level drawing of our IT architecture. This one slide ended up in a discussion that lasted nearly my entire allotted time slot.
It started with the question "Wow, great architecture, how did you come up with it?"
I had to stop and think, as the reality is that I (we) didn't spend a minute thinking about or talking about architecture. We knew our existing systems were not doing a good job of supporting the business, and we started there. Of course for us to support the business, we had to understand it, and we kicked off a project (really driven by the CEO) we called TLC (Think Like a Customer). The goal was to look at the most macro of business processes, in our case lead-to-cash, analyze current state, and make changes in process and systems to streamline the business. In short, to make it easier to do business with us, for customers, partners, and employees.
Out of TLC came about 70 "quick wins"; small changes to process or systems that would make things easier for all. The key component here is that we not only identified them, we actually implemented most of them. We also identified some major gaps in process and systems, and set out to fix the business pain. Our cool architecture is the result. It is not a cool architecture because we set out to design it that way, it is because we set out to solve the business problem(s), and the architecture evolved.
I was asked by one of the attendees at the conference what my enterprise architects thought about the build it as you go approach, and I said that was easy, I don't have anyone doing "architecture" as their primary job. Certainly as things evolved we would ask the "how does this plug in" question, but our focus is always on solving the business problem which is #2 on my guiding principles of IT.
Which kind of leads me to those principles, which drive everything my IT group does:
Customers First
Enable the Business
Showcase our Products (we are an IT supplier)
If everything you do is around one of these things, you can't go wrong. Focus on architecture, or anything else not directly related to one of the principles, and you may succeed, but are just as likely to end up with a cool architecture, and still end up like so many IT departments, despised by a business that sees little value in the services you provide.
I presented at a recent CIO conference on our use of cloud computing, and the first slide in my presentation was a high-level drawing of our IT architecture. This one slide ended up in a discussion that lasted nearly my entire allotted time slot.
It started with the question "Wow, great architecture, how did you come up with it?"
I had to stop and think, as the reality is that I (we) didn't spend a minute thinking about or talking about architecture. We knew our existing systems were not doing a good job of supporting the business, and we started there. Of course for us to support the business, we had to understand it, and we kicked off a project (really driven by the CEO) we called TLC (Think Like a Customer). The goal was to look at the most macro of business processes, in our case lead-to-cash, analyze current state, and make changes in process and systems to streamline the business. In short, to make it easier to do business with us, for customers, partners, and employees.
Out of TLC came about 70 "quick wins"; small changes to process or systems that would make things easier for all. The key component here is that we not only identified them, we actually implemented most of them. We also identified some major gaps in process and systems, and set out to fix the business pain. Our cool architecture is the result. It is not a cool architecture because we set out to design it that way, it is because we set out to solve the business problem(s), and the architecture evolved.
I was asked by one of the attendees at the conference what my enterprise architects thought about the build it as you go approach, and I said that was easy, I don't have anyone doing "architecture" as their primary job. Certainly as things evolved we would ask the "how does this plug in" question, but our focus is always on solving the business problem which is #2 on my guiding principles of IT.
Which kind of leads me to those principles, which drive everything my IT group does:
Customers First
Enable the Business
Showcase our Products (we are an IT supplier)
If everything you do is around one of these things, you can't go wrong. Focus on architecture, or anything else not directly related to one of the principles, and you may succeed, but are just as likely to end up with a cool architecture, and still end up like so many IT departments, despised by a business that sees little value in the services you provide.
Subscribe to:
Posts (Atom)
