Transforming IT

European Business School Launches IT Transformation Study

The European Business School, one of the top business schools in Germany, has announced a new study on IT Transformations.  It will be conducted in conjunction with German software maker Software AG and will focus on how global organizations are "realigning their global IT landscapes to strengthen their competitive position in the long term."

This is another clear sign that true, business-driven IT transformation is real and is taking root as a major area of focus for enterprise organizations around the world.  Read the announcement here: European Business School Conducts Research on IT Transformation.

Politics & 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

The Myth of IT Transformation?

Is IT Transformation just a pseudonym for cost cutting?  Is it just a big word that big consulting companies use to sell even bigger projects?  That's what some of the comments on a blog post from last year in CIO Insight claim.  In the blog post - and most importantly in the comments - there was a very healthy dose of skepticism thrown out there.  I happened to stumble across this a year after it was posted, but found that it still represented a very valid question.

At CastlePointe, the concept of IT Transformation is central to everything we do - we even use it as part of our tag line.  But what is it?  Or at least, what does it mean to us?  I think that's a question that deserves an answer.

To start, we definitely do not believe that IT Transformation is simply another name for cost-cutting.  In truth, an IT Transformation effort exclusively or primarily focused on cost-cutting is almost certain to fail.  Why?  Because a successful transformation effort always begins and ends with people - and it's pretty hard to get people engaged if all you're really trying to do is take a hack at them.

IT Transformation is not a solution or a destination.  The goal is not to "become transformed."  We believe that IT Transformation is a process.  More specifically, it's a process that seeks to alter an organization's behaviors - and sometimes the culture itself - to build organizational capabilities and align itself with its strategic needs and goals. 

That means that a transformation effort is not a goal unto itself, but rather a mere means to achieving the strategic (and sometimes tactical) imperatives of the organization.  While it is true that you can often assume some generalities about IT organizations that are going through a transformation process (they are generally seeking to instill process discipline, they are likely moving to a service orientation, they are seeking operational efficiency, etc.), these are only common characteristics and building blocks of a transformation effort.  But the effort will fail if it is not rooted in specific and tangible business objectives. 

The goal, then, of a transformation effort is to identify those behaviors or cultural elements that are inhibiting the organization from achieving its goals and to engage the whole of the organization to change them.  It is about creating a vision for how the organization should function and then enlisting the organization to make that vision a reality. If this has been done effectively, you will have successfully connected the strategic with the tactical and created a customer-centered and performance-driven orientation within the organization.

So yes, the term IT Transformation can mean different things to different people.  But rather than being a source of weakness, this is actually a source of strength if used properly.  The openness to apply this broad concept and process to a variety of both strategic and tactical goals makes it an extremely valuable and powerful tool for the IT leader. It enables him or her to create a nimble, learning organization that knows its strengths and weaknesses, consistently seeks out gaps between where they are and where they need to be and has the capability to rapidly and dynamically transform itself to fulfill its mission.

The Future of the CIO Role?

I read a recent article from CIO magazine that was very thought provoking.  It reports on the finding from their 2010 State of the CIO survey and makes the case that progressive CIOs are spending more time and energy working directly with customers and driving direct revenue from IT services - and most importantly, that this is where the future of the CIO role is going.

I have mixed feelings about this.  On the one hand, I'm a huge believe that CIO's should really view themselves as CEO's of IT services companies who are providing a set of services to a group of customers.  I believe that it is a paradigm that positions IT in a manner that can enable it to provide significant value to the business in a meaningful way.  From this model, it is not difficult to imagine the "CEO" of IT developing a new product offering whose customer is, well, the customer.

In some cases, this may very well be a true expression of the paradigm.  Particularly in information-based industries, IT is often providing a product that is directly consumable by the customer.  But I also believe that there is a risk here that the true foundation of this paradigm gets lost in the rush to deliver a direct IT revenue source.  Many of the examples offered in the article were not, in my opinion, true IT services.  Instead, they were IT-enabled services of the business.  In such, IT was not providing these services directly to the customer by themselves, but was truly partnering with another part of the company to enhance services or the customer experience. 

Don't get me wrong.  I think that every CIO should read this article and ask themselves what they need to be doing to move their organization further in this direction.  But this must be done without losing sight of the paradigm and the grounding it provides.  If IT is to be run as a business, then it will provide a wide range of services to a wide range of customers.  Just because a service that IT provides is consumed internally, doesn't mean that it is not valuable.  Every service has a customer - whether internal or external - and IT has a duty to ensure that the customer's needs are understood and that the service is provided efficiently and effectively to meet the needs of those customers. 

This article is simply demonstrating how that might be done in partnership with a business unit to meet the needs of an external customer, but the fundamental process and approach should be universal.  If you are providing an on-demand CRM service to your company's sales and customer service teams, the process should be the same - your "account managers" should be meeting with senior executives to understand their needs and value model, your "product managers" should be spending time with the consumers of the service to understand how it may be improved and to identify new services that can extend the value of the current service offerings and your "production teams" should be relentlessly looking for ways to reduce the transactional cost of providing the service. 

So, should IT executives be actively looking for ways that they can extend the value of IT services to the customer and potentially drive direct revenue for the business?  Absolutely.  But in my opinion, that process should merely be an extension of how they design, provision and deliver their services to all customers - internal and external.

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.

The Fuss and Hype over CMDBs (aka "myCMDB")

We may have finally reached the pinnacle of CMDB hype with Managed Objects' release of their new product, myCMDB.  While I have been somewhat of a fan of Managed Objects, this one just has me completely baffled.  The press release hype is talking about bringing 'Web 2.0' to the CMDB.  Huh?

It seems to me that this is indicative of a general trend to make the CMDB so much more than it was ever meant to be...and in so doing make it more and more difficult to actually make it work.  Managed Objects is certainly not alone.  It seems as though there is a virtual land rush out there to see who can cram the most different types of data into the CMDB.

Call me a simpleton, but here's my take on effective CMDB implementations:

1. Keep It Simple - CMDBs (and really the Configuration Management System (CMS) - so we can avoid this whole discussion of one really big CMDB!) should be a relational representation of the core and critical assets that IT utilizes to deliver services.  Each organization needs to determine how deep that needs to go to be effective, but there is a definite balance point that must be found.  The more detailed the data, the harder it will be to keep it accurate.  So, the key point is to get the level of detail just "good enough."  IT people are sometimes their own worst enemy here - once we get a hold of this, we want to put everything under the sun in this wonderful, magical database.  Remember that we can provide access to additional detail and related information through the federation model, but when we are talking about what should be considered a CI there must be relentless restraint to keep the data model as simple as possible while still delivering data relevant to the delivery of service - just good enough.
2. Relationship Trumps Granularity - I always find it fascinating that so much effort is put into defining CIs to an excruciating level of detail, but little effort is put into mapping the relationships between CIs.  The truth is that it is in understanding the relationships that the true value of a CMDB/CMS will be found.  I believe that a CMDB/CMS that defines CIs at only a very, very high level, but maps their relationships effectively will provide significantly more value to an organization than one that contains infinite levels of detail about each CI and its various changes in state over its useful lifetime, but which cannot describe the relationship between each CI and others in the delivery of service.  Get this one right and everything else will fall into place.
3. Process is Still Key - ITIL is all about process (well, v2 anyway).  But when it comes to the CMDB/CMS, it seems that we throw process out the window.  Yes, I'm a big believer in discovery tools and application mapping applications.  But when it comes to maintaining the CMDB, nothing will take the place of a rigorous process.  Anywhere that there is a change to a CI, process should dictate how the CI data is updated in the CMDB.  This should be a key process activity tied to Change and Release Management.  It should also be incorporated into the Standard Change process that might be executed as a function of Incident Management.  The key point, though, is that if your CMDB is falling out of sync, it's a process failure.  Can tools help?  Sure, but nothing can take the place of a well executed, well managed process.

In the end, IT and the many wonderful ITSM vendors must resist the temptation to turn the CMDB/CMS into something that is delivered in and for itself.  It's not.  The CMDB is nothing more than a tool that provides appropriate and relevant data during the execution of a process, in the delivery of a service so that those responsible for the execution and delivery can do so effectively and efficiently.  A well implemented CMDB/CMS is one that becomes virtually transparent.  The data you need is available when and where you need it to get the job done.  If you're having to interact with your CMDB data directly - "Web 2.0" or not - well, you're kind of missing the point.