Extremely interesting article Joel, thanks for sharing. It's interesting to see how the two different approaches at first seem to address the problem in the same way, but in the end I suppose it's more about who is asking the important questions. Rather than IT asking "What can I do for you?" the question becomes "How will IT help the company achieve its goals?" and then letting IT figure it out.
Any insights as to which philosophy the Church tends to ascribe to more?
Thanks for this article Joel. This is the kind of articles that express the unwritten things that happends in the real world. For me the central point is this frase "My job is to help you and the company succeed," followed by "Show me how you do things now," and "Let's figure out a better way of getting this done." I think of this as using all the brains we have to make the bussiness run better. Very interesting article.
The fundamental problem is exemplified in the article of putting a horn in the backseat because that's what the business community wants. At the end of the day, you need a model that allows IT to say "no" to bad requirements. You need IT to save the business community from itself ("I don't care about backups -- it's too expense. I don't care about redundancy for my mission-critical app because I'm too cheap.")
So which model works best? Where IT is a standalone entity within the company with a defined process and a defined set of minimal requirements that the business units need to agree to? Or a "buddy-buddy" "partner" of the business unit who says meaningless things like "We're here to serve you without question"?
It would be great if IT said "We're here to serve you -- but you need to go along with the sensible things we require." Unfortunately, business units don't like being told what to do and IT execs tend to back down when challenged. The area which suffers the most is infrastructure, because most business unit people may understand software, UIs, etc., but they don't have a real understanding or appreciation for a robust disaster recovery plan, for instance, and what it takes to implement and support.
I think the answer ultimately lies in the company DNA and the executive management team. In my experience working with dozens of companies, the best organizations go to IT and say, "You're the expert on IT and I don't tell you how to do your job. Here are my needs. You have certain infrastructure requirements, and we'll let you do your job. Go engineer the best solution." Lots of companies don't do that, and they continually struggle.
My guess, based on conversations with people in Church IT, is that the Church respects its IT people devise the proper solutions.
Joel - thanks for sharing the article. I thought it was great and a refreshingly new take on IT. I would be interested to hear your thinking on the subject as well. I liked the focus on business process change and the idea of IT partnering with other departments to improve how they do things. The focus on improving efficiency or enabling capabilities previously unavailable is key. Acting as a partner with the business feels much better to me than treating them as customers.
I always hated the idea of an internal customer. It’s so Peter Druker from the 80’s, like a dying dinosaurs that missed the extinction memo. IT has changed dramatically over the last decades, and can’t be considered just like a support area. Sadly this seems the overall vision in the PBO and thus missing key strategic ground. IT should analyze constantly the organization and propose better, faster, newer and safer way to do things. I like this approach better: “Don’t tell me what to do, just teach me WHAT you need to accomplish and HOW you are doing it now, and I’ll FIND the hidden connections to other peoples work and PROVIDE a better way to accomplish that.” IT should be the bonding organization that keeps all other departments together, spreading through all the structure and indeed making a digital nervous system of information getting it when, how and to who it needs to get right away. Working as a separate entity, or as an “Internal Service Provider for the Internal Customers” just won’t do it. That’s a dead end.
Extremely interesting article Joel, thanks for sharing. It's interesting to see how the two different approaches at first seem to address the problem in the same way, but in the end I suppose it's more about who is asking the important questions. Rather than IT asking "What can I do for you?" the question becomes "How will IT help the company achieve its goals?" and then letting IT figure it out.
ReplyDeleteAny insights as to which philosophy the Church tends to ascribe to more?
Thanks for this article Joel. This is the kind of articles that express the unwritten things that happends in the real world. For me the central point is this frase "My job is to help you and the company succeed," followed by "Show me how you do things now," and "Let's figure out a better way of getting this done." I think of this as using all the brains we have to make the bussiness run better. Very interesting article.
ReplyDeleteThe fundamental problem is exemplified in the article of putting a horn in the backseat because that's what the business community wants. At the end of the day, you need a model that allows IT to say "no" to bad requirements. You need IT to save the business community from itself ("I don't care about backups -- it's too expense. I don't care about redundancy for my mission-critical app because I'm too cheap.")
ReplyDeleteSo which model works best? Where IT is a standalone entity within the company with a defined process and a defined set of minimal requirements that the business units need to agree to? Or a "buddy-buddy" "partner" of the business unit who says meaningless things like "We're here to serve you without question"?
It would be great if IT said "We're here to serve you -- but you need to go along with the sensible things we require." Unfortunately, business units don't like being told what to do and IT execs tend to back down when challenged. The area which suffers the most is infrastructure, because most business unit people may understand software, UIs, etc., but they don't have a real understanding or appreciation for a robust disaster recovery plan, for instance, and what it takes to implement and support.
I think the answer ultimately lies in the company DNA and the executive management team. In my experience working with dozens of companies, the best organizations go to IT and say, "You're the expert on IT and I don't tell you how to do your job. Here are my needs. You have certain infrastructure requirements, and we'll let you do your job. Go engineer the best solution." Lots of companies don't do that, and they continually struggle.
My guess, based on conversations with people in Church IT, is that the Church respects its IT people devise the proper solutions.
Joel - thanks for sharing the article. I thought it was great and a refreshingly new take on IT. I would be interested to hear your thinking on the subject as well. I liked the focus on business process change and the idea of IT partnering with other departments to improve how they do things. The focus on improving efficiency or enabling capabilities previously unavailable is key. Acting as a partner with the business feels much better to me than treating them as customers.
ReplyDeleteI always hated the idea of an internal customer. It’s so Peter Druker from the 80’s, like a dying dinosaurs that missed the extinction memo. IT has changed dramatically over the last decades, and can’t be considered just like a support area. Sadly this seems the overall vision in the PBO and thus missing key strategic ground. IT should analyze constantly the organization and propose better, faster, newer and safer way to do things. I like this approach better: “Don’t tell me what to do, just teach me WHAT you need to accomplish and HOW you are doing it now, and I’ll FIND the hidden connections to other peoples work and PROVIDE a better way to accomplish that.” IT should be the bonding organization that keeps all other departments together, spreading through all the structure and indeed making a digital nervous system of information getting it when, how and to who it needs to get right away. Working as a separate entity, or as an “Internal Service Provider for the Internal Customers” just won’t do it. That’s a dead end.
ReplyDeleteAwesome article, Joel. Thanks for sharing.
ReplyDelete