Status Check

In response to those who have inquired about the lack of new posts (and those who haven’t and are curious), here’s a quick update.

As you know, I’m currently doing IT Strategy consulting work via the ITST web site, DeMatteo Monness, GLG Councils, and Primary Insight. Those engagements take me on short notice to client locations for indefinite periods of time. I also continue to look at new full-time IT executive opportunities, which entail preparation, travel and interviews.

Recently, an exciting new project has surfaced, working with a few partners and potential investors on a start-up business. We’re developing the business plan and a path forward for the proof-of-concept, so it is very time consuming (I haven’t started a new business since Fresh Approach, in the early ‘90’s and had forgotten how much work it is).

Given that it is a new venture, I’m bound by a non-disclosure agreement and really can’t discuss the initiative in detail. What I can say is that it is a “Green” business, utilizing a web presence that offers information, goods and services.

For the near future, ITST posts will continue to be sporadic and very much focused on topics that are either reader-inspired or new business-related, so be sure to email me with suggestions.

Thanks very much for your patience and understanding, and please stay tuned for more information on the new initiative.

The Missing Triangle – Framing the Transformation

One of my more astute readers has pointed out to me that all of the documents in the Library are referenced in a link from one of my posts except for one, the IT Transformation Triangle.

First, I’m flattered that anyone has read the blog that consistently and thoroughly to be able to notice that omission.

Second, I’m somewhat surprised to see that it is true. The materials in the Library are there to support the posts in some fashion. The post using the Transformation Triangle was edited a bit too severely and I ended up omitting the reference link. I’ll attempt to explain the use of the diagram outside of my originally intended reference.

To be successful, transformational programs of work must be defined along workstreams that are readily understood by, communicated to, and executed by IT folks. The triangle icon is the mechanism that I commonly use to help accomplish this.

Please note that it is far beyond the scope of this post to capture the entire body of work for an IT transformation. The intent of this post is to explain the Transformation Triangle and its use in framing, communicating and managing an IT transformation program.

The Transformation Triangle is comprised of four smaller triangles representing the various dimensions of the transformation: Process, Technology, Organization and Management Systems. The first three categories are for changes within IT. The fourth category is for changes that are external to IT and are done in cooperation with other staff departments, most commonly HR, Finance and Procurement.

The Process Triangle represents the changes to IT processes that will take place as part of the transformation. Presuming that the changes are to support a transformation to a services-based strategy, they are usually in the following IT functional or governance areas (in no particular order):

•    Portfolio & Demand Management
•    Solution Design & Delivery
•    Service Delivery & Support (Service Management)
•    Enterprise Architecture
•    Program/Project Management
•    Sourcing/Supply Management

Each of these areas will have a set of processes to be defined and matured within the overall transformation plan. Each of the work teams accountable for the definition and implementation of processes will have their work captured and reported in this category.

In a similar fashion, the Technology Triangle represents the changes to IT technology that will be needed to support the changes to process and architecture that will take place as part of the transformation. Initially these tend to be the implementation of software and support tools for program/project management and various service management functions (e.g. Service Desk). Later, they tend to be standardization efforts sponsored by Enterprise Architecture and additional tools for other areas as needed. Each of the work teams accountable for technology-related change will have their work captured and reported in this category.

The Organization Triangle represents the changes that will be made to the organization from staffing, skills, structure and sourcing dimensions during the transformation. These are discussed in BES-6. This category tends to be the one that is of most interest to the organization (as well as the one that causes the most angst) during this period. Each of the work teams (generally the IT leadership team) accountable for organization-related change will have their work captured and reported in this category.

The Management Systems Triangle represents the changes that will be made with the assistance of other staff functions to support the IT change agenda. For example, if there are new roles in IT that are defined by the transformation plan, HR will need to assist in the creation of  new job descriptions, slot the levels and define the compensation for these new roles. If a new service costing strategy is defined, Finance will need to assist in the modification of cost centers and create new mechanisms for assignment of cost to the new services. Each of the work teams accountable for changes to management support systems will have their work captured and reported in this category.

When embarking on an IT transformation journey, the Transformation Triangle is a great tool for the initial framing and ongoing communication and management of the IT Transformation for several reasons.

First, it provides a logical structure for categorizing the work that will be going on across the department, as well as other staff functions. It exposes the breadth and variety of the work on process, supporting technology and organizational elements of change needed to accomplish a successful transformation to the organization. This structure enables crisp, consistent communications to be developed during the transformation program.

Next, it fosters a common understanding and lexicon for the transformation program. As it becomes familiar and the transformation Vision is communicated, IT begins to see itself in a different way, as a service organization supported by process and technology, and is purpose-built for that mission.

Finally, the Transformation Triangle can be used to illustrate the continuous nature of change over time. It is an ongoing cycle that is responsive to the changing needs of the business and optimization of the IT function.

Cloud Computing Commentary

Please comment on Cloud Computing with GPU Intensive Apps (current state and future viability).

Admittedly, this topic isn’t my long suit. Cloud Computing is kind of the übercategory for delivery of IT capabilities over the Internet. Most of the business offerings in that category aren’t computationally intensive, particularly for graphics.

When thinking Internet-delivered capabilities, I’m presuming some sort of thin device on the client-side. That doesn’t generally mesh well with a heavy-duty GPU and the corresponding bandwidth requirements to feed it. Is this for Internet delivery of multimedia gaming or other real-time graphics applications?

Perhaps I’m just a troglodyte, but I don’t see this in the present Cloud Computing environment and would be somewhat apprehensive about opining a future without knowing more specifics. Reader comments are most welcome.

SaaS Commentary

Please comment on Software as a Service (current state and future viability).

At the risk of placing myself firmly in the pantheon of IT curmudgeons, I think that SaaS is another new name for an old concept. In 1993, we referred to this sort of thing as an outsourced or hosted application (admittedly not particularly sexy names).  IT lexicon purists may split hairs over the use of a common code base, but fundamentally it’s the same thing.

In my view, SaaS is simply another way to add a particular business capability. There are certain conditions where it makes sense to adopt this approach. For highly differentiated capabilities, it probably isn’t a good option. For more standardized capabilities, it is. Lower investment and speed of implementation are also generally considered as advantages for SaaS solutions.

There are other considerations as well that would be built into a scorecard that would be used to rate the suitability of a SaaS solution versus other options. Again, it’s all about what you are trying to accomplish and what that means about how you should do it.

Obviously, SaaS is and has been a viable option for provisioning capabilities. In the future, my opinion is that it will most likely be subsumed into the larger utility or cloud computing category.

SOA Commentary

Please comment on Services-Oriented Architecture (current state and future viability).

Services is one of the most overused and least commonly defined words in IT today (discussing Services in both SOA and Managed Services contexts at the same time makes for a challenging conversation). A close runner-up is Architecture.

Having them both in the name of an IT construct still somewhat frightens me.

My comments today on SOA will be brief. I believe that SOA is a new, fancy IT-ism for an older concept called Enterprise Architecture carried to its logical conclusion or goal.

Enterprise Architecture is all about common business services as instantiated in technology. That happens via an end-to-end EA process reaching back to the business. SOA simply articulates that differently. The technology behind them is the same.

I’m not sure if SOA has the staying power of EA. If pressed, I’d speculate that SOA would eventually diminish in the IT lexicon, as EA efforts are successful in reaching the same goal using processes in place now.

The CIO Role, etc.

Thanks to all who submitted topics and questions. The pipeline is healthy and I believe that there is a good mix of technology, management and leadership subjects for your consideration. Please keep the suggestions and comments coming!

Today’s topic comes from an old (old in the sense of having known him for a while, not in the sense of “aged”) colleague. He writes:

“I have a topic for your site that might be of interest – The role of the CIO.  I have noticed that the CIO role is becoming a prerequisite to the COO or CEO position.  It appears many CIO’s are coming from the business vs. growing up through the ranks of IT, and take the role to bolster their resume.  With IT such a critical component of today’s businesses, the CEO is expected to have a strong understanding on how to direct the expensive and limited IT resources.  I see the role CIO of old shifting to that of the CTO for IT careerists.  Assuming this premise and carrying it on to the next level what are the critical skills in managing technology going forward.  It would seem that outsourcing and integration expertise would be at the top of the list. – your thoughts?”

There are a few subjects here that are interesting to ponder.

•    First, is there really a CIO to COO or CEO career path?
•    Second, are more CIO’s coming from the business versus growing up though the IT ranks?
•    Third, is the CTO role more of the “top IT leadership” job for IT folks than the CIO role?
•    And lastly, what are the critical skills for IT leadership going forward?

It’s not clear to me that there is a CIO-to-CEO career path, although I do believe that there is or was a CIO-to-COO executive career path. Because of the heavy reliance of operations on technology, it makes sense that the two would become one over time. In some companies, I’ve seen this sensible progression give way to the CIO reporting to a “Head of Shared Services” function, along with Finance, HR and Procurement, which I do not think of as a traditional COO role.

Why is this being done? In those organizations that have adopted this model, I believe that it is because the value proposition of IT has not been delivered upon and the information technology contribution to competitive advantage is perceived by the business as relatively low. Therefore, the IT organization is seen in a similar role as the Finance and HR support organizations and managed accordingly.

There have been some instances where business executives have been given responsibility for IT and either added or taken the CIO title. In the cases that I am aware, it seems to be born from IT being perceived as being out of alignment with the business for an extended period of time. Attempts to address the situation with new CIO’s have either had little or no success, so a successful business executive is then brought over to IT or is given responsibility for the function in addition to their current role.

In the cases that I have seen where the titular CIO is a business executive, the CTO or head of IT Service Delivery is responsible for the IT “factory” and is accountable for delivering on the IT value proposition as defined by the CIO. The role is that of a CIO, despite lack of the formal title.

This leads to another question – can a business leader effectively lead the IT function without any background in it?

If  you were a CEO, would you have a CFO who didn’t have a background in Finance?

If you were a CEO, would you have a COO who didn’t have a background in Operations?

I could go on, but I think that you get the point.

Why should IT be any different?

Whatever the title, if the CIO role is indeed to maximize the value of Information Technology to the business, I believe that knowledge of technology and its application thereof, is essential to success. The question of who has the title is more of a level-based question driven by the role of IT and its value proposition to the business. Therefore, whatever the title, I still see the CIO role as executive level for the IT careerist.

In terms of critical skills for managing technology going forward, I believe that knowledge and understanding of a services-based model (reference link) and how to apply it in the real world is a prerequisite for any successful executive in a CIO role.  That opens up the possibility of effectively multi-sourcing services in an efficient manner as the value proposition for IT services dictates. Please note that the service-based model is not only for what you would think of as IT Commodity Services, but also includes IT Solutions Delivery and the IT Business Relationship Services.

To support the managed services and multi-sourcing strategies, outsourcing and integration are two important capabilities for any CIO and to that short list I would quickly add deep skills in Organizational Change Management. With change as a constant, the ability to lead through it is essential to the success of any IT executive.

Cost Redux

Blog Queries: Why are my IT costs seemingly so difficult to capture and explain, especially in the context of business drivers and consumption?

 This is what I’ve heard a number of executives refer to as the “black hole” phenomenon. IT seems to be a great hole of expense where little or nothing quantifiable in terms of information as to what is produced for it comes out. The Managed Services model for IT is neatly addresses this issue.

 Simply put, in this model instead of managing itself by technology, IT manages itself by services, recognizable and purchasable by the customer. These services may be sourced internally, externally or in some combination that helps to optimize its value proposition (check FAQ’s for Value Proposition).

 Once the Managed Services model has been operationalized, IT is running like a business, where customers buy services at a certain service level and cost. Whether or not the company chooses to institutionalize a chargeback mechanism for services used by each business unit or not, the information will be available for a business unit leader to see how much of what services their business is using and respond appropriately to manage the cost.

 Related follow-on question: What about new solutions – like projects? How does that work in a Managed Services model?

 In the Managed Services model, delivery of projects (delivery of business solutions) is a service, like the delivery of a desktop computer. There are different processes for the creation of requirements, estimation of cost, business case development and delivery, but it is an IT service nonetheless (including performance metrics and measures).

 Please refer to the diagram on “Basics” for a high-level visual.

 

 

Focus and Change

Blog Query: From your previous post it appears that my IT will have to transform to successfully support my business change agenda. How can IT both support my critical business change objectives and transform itself at the same time?

A difficult challenge comes when the business has a critical need for the IT change enabling capability at the same time that IT is transforming itself. To be successful, IT needs clear focus on what needs to be delivered for the business, so that the IT transformation program can run in parallel and shape its deliverables to best support both business objectives and IT transformation objectives.

Similarly, I would suggest that one of the most important factors determining the success of the business transformation is the ability to focus on the investments necessary to achieve the business transformation goals across functions and business units.

For this, a new process is generally needed for the various business units to classify their investments in common categories aligned to strategic directions and financial goals. Then, standardized business cases can be developed and compared between initiatives within categories.

This process begins with bottoms-up identification of desired projects by business unit and the development of categories that will be used to group the investments. Next, a tops-down investment allocation by category is needed, with an eventual investment proposal created by category based on strategic focus, competitive analysis and operational readiness

Sound complex? Not really.

Let’s say that there are currently 400 business unit proposals, some requiring major IT investment, with a projected capital spend of $150M.

Our executive committee determines that given our strategic direction, all investments will be classified as Cost-Cased, Revenue-Based, Risk-based or Customer-based. The business cases will be built to reflect the goals for each category. The CFO informs us that due to current capital conditions that our total spend can only be $100M across all categories. After intense discussion about strategic direction and priorities, it is decided that the $100M will be initially allocated across categories as follows: 

• Cost – $50M
• Revenue – $25M
• Risk – $15M
• Customer – $10M

Each category now has an initial investment allocation, and each function and business unit is now accountable for classifying investments into these categories and creating corresponding business cases. Each investment should have an executive committee sponsor and a senior business leader accountable for the veracity of the business case (usually the function or SBU leader – remember these are business investments, some with an IT component).

Now that we have investments by category with comparable business cases, each category team (the full executive committee or a subset) can prioritize the investments as either above the funding line or below. Once that is accomplished the initial proposal for each category is submitted to the executive committee for review, discussion and approval to proceed. Once this approval is given, all functions and business units will be operating off of the same investment list, including IT.

The ongoing responsibility of the category teams is to track the progress of approved investment projects, review and prioritize new investment proposals, and report issues and opportunities back to the full executive committee.

Once this process is established, we can be reasonably certain that our investments are aligned with strategic direction and that we are all executing with the same priorities. 

Note that this, like any process will occur over multiple budgeting cycles, so at any point a category will have committed funds overhang from work in process as well as future year commitments. The $100M total and tops-down distribution are current year examples for discussion.

Clarifying Change

Blog Question: When you are talking about change (or transformation), is it for the business, IT or both?

When I am writing about change (or transformation) it can be in the context of business change, IT change or IT enabling business change. At times, IT must transform itself before it can effectively support the business change. 

IT has the role of being the most critical component of large-scale business change. IT enables common method and process across an organization of any size at a pace generally constrained only by the ability of the organization to manage it (think OCM). Unfortunately, the way that most IT organizations have grown up, they are unable to successfully execute this important role in a consistent fashion.

At some point in the life of a thriving enterprise (I think that Andy Grove’s “strategic inflection point” where something fundamental changes in the environment without it being particularly apparent applies here) it becomes more important for a business to execute across functions than within functions. At that time, purpose-built IT solutions that effectively support individual business functions with their own applications, data and infrastructure (you may have heard of these as “silos”) are inadequate to respond to the challenge of being the enabler of cross-functional business change.

Fortunately IT can transform itself to be able to execute effectively across silos, but it takes a paradigm shift in the way that IT operates to be able to do it. Implementing a Managed Services model, with its established process frameworks, is an effective way to accomplish this transformation.