Breakthrough IT: Supercharging Organizational Value Through Technology (英語) ハードカバー – 2007/11/2
Kindle 端末は必要ありません。無料 Kindle アプリのいずれかをダウンロードすると、スマートフォン、タブレットPCで Kindle 本をお読みいただけます。
Unlock the secret to creating maximum business value from technology
Filled with case studies from leading C-level executives to illustrate concepts discussed, Breakthrough IT is a revolutionary approach to reshaping the corporate information technology function. This innovative, step-by-step guide provides concrete methods every business can implement to yield maximum value and competitive advantage from their IT organization.
Patrick Gray (Harrison, NY) is the founder and President of the Prevoyance Group, an IT strategy consultancy that combines project management and process improvement to ensure large IT departments deliver maximum organizational value.
"Patrick Gray has done a very commendable job of delineating the evolution of information technology's (IT's) role: basic history, and the roadmap for supercharging the value of IT to the enterprise. It has robust content and the chapter material is well-conceived and logically sequenced. Breakthrough IT is a valuable read that should be kept handy." (New Jersey CPA, May/June 2008)
"examines what it means to be living in an era of corporate information technology and the step-by-step methodology required to create a value-based IT organization." (Bookviews.com, February 2008)
"IT today is being squeezed by a "Triple Threat" Gray does a nice job of describing." (Techrevu.com; 11/2/07)商品の説明をすべて表示する
Liked the executive style sumamaries at end of each Chapter
The book contains sections on creating the right employee base, applying portfolio analysis to your project list, implementing project budgeting discipline, and (as a last resort) how to kill a project.
If you want to move away from being a harried order-taker and become a peer of the other departments in your company, you owe it to yourself to read "Breakthrough IT."
Assuming I understand the book correctly, the author defines Breakthrough IT as an IT organization in which current and ongoing operations have been moved out of IT. The IT organization has been remade as a group of process and business experts who are passionate about IT, rather than a group of technologists.
The author says the CIO (which stands for "Career Is Over") is not considered a true peer of those in the C-suite, such as the CEO, COO, and CFO, and other CxO corporate officers. The CIO is seen as an uber geek rather than a business officer, and is left out of strategy; brought in only when something is needed from his "utility".
CIOs can change this picture and become true peers of the CxO group by outsourcing or insourcing all current and ongoing operations and turning his group into business and process experts. Somehow this will make him admired and respected in the C-suite. I'm sure you know what outsourcing is. An example of insourcing as I understand it would be taking your NetOps (Network Operations) and/or helpdesk and removing them from the IT business unit. They will be transferred to another part of the company away from the CIO's purview, freeing the CIO to concentrate on strategy, business, and processes.
I'm not sure I agree with this assessment. He makes a case and builds an argument, but I don't think his arguments fit together into a premise I agree with. He seems to pull a bunch of statements together and say "See! Breakthrough IT is the way to go!" This made me think of the Underpants Gnomes in South Park. Their business plan was as follows:
1) Collect Underpants
I'm not trying to be unkind or critical of the author.
After getting through the first few chapters, he settles into what I considered a review of topics I already know, only using his "Breakthrough IT" concept as he explains them. He talked about Investment Planning, Project and Portfolio Management, and Change Management. I would LOVE to have forced these chapters on the last organization I worked for, which seemed to have little understanding of such things. They did have processes for some of them, but no discipline to follow or enforce those processes.
I appreciated Chapter 8 with its discussion on killing a project. Although this wasn't new material for me, it was a nice focus and concentrated heavily on the HR aspects of killing a project. A project that must be killed isn't necessarily a failure, and should not be assumed as one. A project can fail for a number of reasons. Say you're trying to roll iPads out to the entire enterprise, and Microsoft releases its Surface tablet, which turns out to be as good as it sounds. Suddenly, the iPad concept makes less sense, and this could be considered a time to kill that project and move on. It doesn't mean anybody failed. The market/technology changed right in the middle of the project, which in this example was planned and started BEFORE Microsoft announced Surface, so nobody could have seen it coming.
Chapter 8 dealt with learning lessons, spinning off mini projects in order to reap beneficial portions of the killed project, and above all, not ruining the careers and laying off the people on the killed project. This is a discussion I haven't seen much of in the classes I've taken, books I've read, and projects I've worked on. This chapter alone is a reality check and should be required reading before starting or killing a project, and before a lessons learned meeting.
Chapter 9 is about taking over as a CIO and how to get started, as well as some of the problems you're likely to face.
I liked the author's discussion on how IT should not seek to be a "low cost provider". I agree. This is always a race to the bottom. Between automation and outsourcing, somebody will ALWAYS be able to do it for a lower cost than you.
This book seems to assume a universal problem and solution. I've been wrestling with this. I'm sure if I wrote a book, I doubt I could write it to a small, specific problem so I'd have to assume a universal. This book seems to assume all CIOs are in the same situation, and all IT needs to become "Breakthrough IT".
Chapter (3?) had an interesting dicussion about the differences in processes and technology. The author said that the process should be independent of technology. He suggested writing a process for getting from your home to work. He said the process doesn't need to mention your car or bus. I ran this thought experiment briefly. While I could write a process for getting to work from home without mentioning my car, I would still have to ASSUME some form of technology in order for the process to work in the real world. Mentioning my car specifically would be stupid, because what if I get rid of my car and get another one? But I can't get from home to work without a car, bus, or ride from somebody else. It's too far to walk (almost 30 miles) and riding a bike on most of the roads involved is out of the question. I MUST assume the use of a conveyance (technology).
Similarly, say I'm writing an ITSM (IT Service Management) process for work. Let's say I have to write a process for the ESD (Enterprise Service Desk) to answer phone calls. While I would not need to mention the specific ITSM solution (Remedy), I still have to assume it when the process calls for taking a phone call and opening an incident or service request. The process cannot be independent of the technology. Although if the author would like to buy me a coffee (or beer) I'd love a chance to run my understanding by him.
The conclusion of the book has a brief discussion on decentralization, which I'm dealing with in my organization. I found it helpful in understanding at a high level what we're trying to do and how to build strategy for it.
Breakthrough IT also offers several case studies from real life CIOs, which helped answer my skeptical question from the beginning of the book "Yeah, that's nice, but would it work in the REAL WORLD?"
About Chapter 4, I considered giving this book two stars. However, I decided when I finished the book, it's worth 5 stars. The author got me to question my assumptions, to ask questions and argue with him through my notes, and I learned a few things. I read some books and think "That's nice" and toss it, learning little or nothing and never thinking of the book again. I read some books and only feel like writing a few lines of review. You can see how much text I've pumped out writing about this book. That means it got me to engage. I give it five stars for that alone.
Several other reviews say CEOs and CIOs should read this book. My expectations may be unrealistic, as it seems to me that these officers should already know this kind of material. I admit; I don't have much exposure to IT organizations outside of my industry, and in my industry I've seen plenty of CIOs that made me think I could do their job better.
Here's my take: you probably should read this book. The idea of Breakthrough IT is interesting, even if I don't find it universally applicable. Take a good look at your business needs and implement it if this would be a benefit. Don't just do it because it sounds like a fad. But if it works, implement it.
This book includes an interesting idea, and comprehensively covers many aspects of the business of IT. Chances are you'll learn something. If you're a CIO or CEO and don't already know most of this, you definitely need to read it. Also, did you lie about a Computer Science degree like that one CEO recently?