Charles A. Araujo, Jr.

Running IT as a Business is no Train Wreck

A recent article on CIO.com (originally published in InfoWorld), really got under my skin.  It's basic premise was that the concept of Running IT as a Business was flawed and nothing but a train wreck waiting to happen.  I think that's malarkey.  Following is the comment I posted in response:

To begin with, Running IT as a Business is a metaphor that creates a simple way for technically-oriented IT folks to understand that technology exists for something more than its own sake. And to that end, it is extremely powerful and useful.

While I agree with the simple message that IT must be integrated with the business and viewed as a strategic partner to be effective, I do not believe that is in any way incongruent with "Running IT as a Business." What successful business isn't founded on a fundamental understanding of its customer's needs and the value which they place on those needs? What successful CEO doesn't spend the vast majority of his time obsessing about changes in the market, meeting with his customers, understanding their businesses and forecasting their future needs - often before they do? The most successful businesses do, in fact, become strategic partners and become integrated into their customer's business. And to the counterpoint, how many successful businesses are founded with the premise to become the best darn order taker out there?

It is not the paradigm that is broken, but simply its execution. Likewise, it is important to understand that it is not all of IT's job to be the "car designer." If IT was a car business, it is clear that there need to be designers - but there are also line workers, accountants, customer service reps, quality control coordinators, etc. They are all part of the process to provide value to the customer through the product or service delivered - and they are all equally important.

So the paradigm of running IT as a business says that I must first design effectively, based on a solid understanding of what the customer values (not merely their requirements), but also must execute flawlessly on everything that leads from that design to a usable product that delivers the value we promised in the first place. That's running IT as a business - and it makes more sense now then perhaps ever before.

ITSM Portal: Politics and ITSM Adoption

I just posted a new column over at ITSM Portal entitled "Politics and ITSM Adoption."  It speaks to the need to be actively aware of the "politics" surrounding (and often working to defeat) and ITSM adoption effort.  Politics isn't a bad word, but is simply a way of saying that organizations are made up of people and those people have needs, ambitions and fears that may drive their behavior.  As a leader of an ITSM adoption effort, you must be tuned into these issues so that you can leverage or mitigate them to lead your initiative to success.  Read the column here: http://www.itsmportal.com/columns/politics-and-itsm-adoption

New Post on 'Transforming IT': The Myth of IT Transformation?

I just posted a new entry on our CastlePointe Blog, "Transforming IT."  It's called, "The Myth of IT Transformation?" and I just realized that I'm getting into a bad habit of posting questions as titles.  Anyway, it's in response to a year-old blog post and its comments that I thought it raised some good questions and which deserved an answer - especially from the guys who are all about IT Transformation!  Check it out here: The Myth of IT Transformation?

New Post on 'Transforming IT': The Future of the CIO Role?

I just posted a new blog entry on our Transforming IT Blog, entitled "The Future of the CIO Role?". It discusses a recent article from CIO magazine about their 2010 State of the CIO survey and what they felt it meant to the future role of the CIO.  I don't entirely agree with where they went, but I found it to be an interesting and thought provoking article. Check out the post here: http://transforming-it.castlepointe.com/2010/01/the-future-of-the-cio-role.html

A Time to Transition & Focus

Well, in case anyone is still checking this blog, it should be apparent that I haven't done a good job of posting to it.  Well, as 2010 dawns, I'm adjusting my strategy a bit.

To begin with, my posts related to IT Transformation, ITSM/ITIL and Organizational Change will predominately be found on our new CastlePointe Blog, Transforming IT.  It can be found at Transforming-IT.castlepointe.com.  This will align these posts more closely to the efforts of my company and also provide opportunities for my partners to write on the same subject without it being affiliated with my personal blog.  So I'm excited about this transition.

I am also a new columnist at ITSM Portal (www.itsmportal.com) one of the oldest ITSM news and information websites out there.  I'm not sure when my first column will be posted, but I'm very excited about this new opportunity.  It will allow me to write periodic columns that will be ready by a larger audience and share some of what I've learned over the years.

As I write posts on our Transforming IT blog or have columns published on ITSM Portal, I will post links here.  But otherwise, I intend to write occasionally on a more personal basis across a much more varied set of topics.  I'm honestly not all that sure what that means, but I'm looking forward to finding out!

Creating the "Wise" IT Organization

I was recently contemplating the nature of wisdom and what it really meant.  Was it something that had relevance to an organization? Could you create a "wise" IT organization?  And if so, what did that mean?

I think wisdom really has three elements:

• Knowing what is right
• Knowing how to apply that knowledge to the situation (what's right for me)
• Knowing when and how to take action on that knowledge (and when not to)

Isn't that what wisdom really is - applied knowledge for the greater good?  But does that have meaning to an IT organization as a whole?  I think it does.

In ITIL v3, this is actually addressed somewhat in the context of a Service Knowledge Management Systems (SKMS). Within it, it lays out a structure of Data-to-Information-to-Knowledge-to-Wisdom.  It basically describes the process in which discrete pieces of data are provided context to become information, which is then analyzed and associated to become knowledge.  Wisdom, then is the judgment and discernment to apply that knowledge in a meaningful way.

I think that this is the essence of organizational wisdom and frankly, a missing element in most IT organizations.  Most IT organizations are awash in data - particularly the technical kind.  But what happens with that data?  The entire context of ITIL's SKMS is to lay out the need to do something more - to add context and analysis so that the data transcends into something useful and meaningful and actionable. 

I think that this is what it might mean to become a "wise" IT organization and I think it should be a stated goal of any IT leadership team. Every IT organization should strive to create a "wise" culture that seeks to do three things:

• To know what is right.  To know the needs of the customer. To understand the true goals and objectives for the organization. To truly understand their reason for being.
• Create Understanding and Knowledge.  To gather data and apply the context of customer needs.  To analyze it in the context of business impact and so convert that data into information and then knowledge.  To transform the relationship between the data and the customer to go from a disconnected, dissociative relationship to an intimate one that applies to everything IT does.
• Seize the Moment.  To leverage this knowledge and understanding and take the prudent action - or inaction - to meet the present and future needs of the business.  Through this knowledge, to seize opportunities that leverage technology in ways that may be new and innovative.  To see the coming changes in the business and create flexible, adaptable business approaches that enable the IT organization to react quickly to the changing business needs.

If you could create an IT organization that operated like this - holistically and baked into its culture - would you call it a "wise" IT organization?  Whatever you'd call it, it would be a highly effective organization that was driven and bound by a "higher purpose." It would be an organization that wasn't merely providing technology or even IT services, but one that was fully connected with its customer and able to provide true, lasting and meaningful value through its application of knowledge for the greater good of the business. That sounds like an IT organization I'd love to be a part of.

Roadblocks to Innovation: Knowing What Your Customers Want

Ok, so this isn't really about technology, but Malcolm Gladwell gave a talk at a TED conference in 2004 that talked about something that I think often perplexes IT leaders - understanding what your customer wants.

We know the basics.  We know that our customer needs us to deliver ERP and financial systems.  That we need to deliver and support an infrastructure to enable these, etc.  But when we have reached a level of maturity and are looking to take that next big step forward - to move beyond the stale strategic planning process and really begin to bring new, innovative ideas to the table - we are often stumped at the starting gates with the simple question - what does my customer really need and want?

It's a question we need to be able to answer if we are to cross the divide and become true IT innovators.  I know it's a stretch to make a connection between IT and spaghetti sauce (you'll see), but take a look and see if it doesn't stir up some ideas.  If nothing else, it's very entertaining.  Enjoy!

The Rise of the Lifeguard CIO (It's not what you think)

Fortune Magazine recently (well, November!) published an article entitled, "Meet Your New Leader."  It described an apparent transition that is underway in CEOs of large, publicly traded firms from the "Visionary", charismatic, autocratic CEO to a new form of leadership that the article likened to the make-up of a Lifeguard. 

But this isn't about racing to the rescue. Rather, the article pointed out some key characteristics of this new type of leader:

• Calm in the face of crisis
• Comfortable not knowing what's going to happen
• Ability to scan the horizon and anticipate coming shifts
• Ability to work with a team and with rules set by others

And while this article was about CEOs, I couldn't help but feel that it applied equally to CIOs as well. 

I largely "grew up" in the era of the technically-focused, autocratic CIO.  Vision and strategy would be set at some high up level and passed down to us minions to go implement.  It basically worked - but let's face it, technology was a lot simpler then.

The combination of the sheer business criticality of technology and customer visibility to it, coupled with exponentially increasing complexity makes this approach woefully outmoded and frankly, fraught with risk.  So, like the new vision of the CEO, the CIO of the future is going to have to have a very different approach to building and managing the technology landscape.

If you'll indulge my interpretation, I believe that the modern "lifeguard" CIO is going to have to look at their role very differently.  They will need to focus more on:

• Building adaptable and agile organizations - rather than architectures
• Identifying where technology may impact their business - rather than on how the business may impact their technology
• Integrating technology into business strategies - rather than aligning IT to business decisions
• Harnessing the creative innovation within their teams - rather than capturing only organizational efficiencies

Admitedly, most IT organizations are nowhere near this state of maturity - and in fact many of the "rather" statements are stepping stones along the maturity path.  Still, I think it's important that we always be mindful of where we are going so that we can constantly evaluate if we are on the right path. 

It seems clear to me that as technology architectures continue to increase in complexity, and while the impact of technology on the business becomes more and more mission critical, the demands on IT leadership are going to change and grow.  The leadership required will look a lot less like the "in command" General most common today and much more like the Lifeguard.  It's probably the only way that IT will finally get to where it needs to go.  So the question is, as you go through your career, which skills will you work at developing?  Sunblock anyone?

Note: You can read the article by clicking here.

Checklist for Change

A client recently sent me this article about the utilization of checklists as we were going through some discussions on the implementation of a new ITIL-derived change management process. 

What I love about it is that it has nothing to do with IT.  It's about operating rooms.  Yet the lessons still apply - and my client was wise enough to see the correlation.  At the end of the day, most of what we do, well, isn't surgery.  It can be complex and can be incredibly important and risky for the business, but most of the time it's not life or death.  So where we can find lessons from people or organizations who are playing where the stakes are that high, we should look at them carefully and ask ourselves how we might learn something from their challenges and solutions.

My client did just that.  If you read the article, though, there is an extremely important piece of information that is easy to miss.  The checklist is important - but the real value comes from verbally going through the checklist as a group.  It is this interactive and interrogative process that creates the true power of the checklist - and when that step is skipped, the checklist loses its effectiveness.

I think that this is a perfect corollary to the Change Advisory Board (CAB).  There has been a lot of push recently to this concept of a "Virtual CAB" - a change authority body that doesn't actually meet, but reviews and approves changes based on a review of the RFC by using some automation tool.  Don't get me wrong - I'm a fan of the "Virtual CAB" for minor, low-risk changes.  But I believe that their use is becoming too prevalent and organizations, in their zeal for automation, often miss the true point of the CAB - to discuss and evaluate the risk of the change with all stakeholders to ensure that the risk has been adequately quantified, mitigated and accepted.  It's tough to do that with a click of a button.

So perhaps there is a lesson to be learned here.  We should use a checklist to help the CAB ensure that risk has been mitigated and that RFC approval requirements have been met.  But to really make it effective, we must require that the CAB does it verbally.  Maybe by doing so, we will get that dialogue that supposed to occur and perhaps we will begin to get a more complete understanding of the true impact and risk of proposed changes.  And maybe, just maybe, the process will work a little bit better.

Read the article by clicking here and see how you think you might apply it yourself.

How to fix the innovation gap: A conversation with Judy Estrin

McKinsey has recently posted a video interview with Judy Estrin on the state of innovation and how companies need to be looking at driving greater innovation.  There are definite lessons to be learned for CIOs and IT organizations.  Check it out here.