Leaping Onto The Change Bandwagon
In most organizations where I have recently consulted, business executives are dissatisfied with IT. This dissatisfaction is usually because IT isn’t delivering what the business wants or needs, or it is perceived that IT costs are not in line with the value being delivered.
Last year’s BES posts expressed high expectations by executive leadership for IT to deliver on both critical business imperatives and cost improvements. Sadly, it would appear that this has not happened.
Whether real or perceived, this is an important problem to address because IT is now seen as contributing to the failure of achieving important business objectives and wasting significant budget dollars on low-value activities.
The size of the problem varies, and therefore the executive leadership appetite to address it does as well. But if it is a big problem, with critical business objectives missed and/or IT costs way out of proportion to the services provided, then why isn’t the problem being fixed?
The answer almost always can be classified as one of these three statements:
• We are planning to fix the problem.
• We are in the process of fixing the problem.
• We have tried to fix the problem and it hasn’t worked.
When pressed for more detail about how the fix will be approached, or what actions are being taken, the response is usually an IT-centric one that focuses on process and organizational change.
Frankly, and from experience, I believe that an IT-centric approach to solving the problem is fundamentally flawed and will invariably lead to the result in the third statement.
Which brings us to the point of today’s post – the introduction of a new series.
Entitled “Business-Centric Change” this series will describe an approach to solving the problem (captioned in the first paragraph) of “IT isn’t delivering what the business wants or needs, or it is perceived that IT costs are not in line with the value being delivered” that is business-centric and IT-led.
Like BES, the BCC posts will appear weekly (or so, depending on my schedule). The first – entitled “The Problem” will be on the site next week. I hope that you enjoy the series and remember that your feedback and comments are always appreciated.
My First Attempt at Political Technology Commentary
President Obama will soon be appointing a Chief Technology Officer for the country. This has been known and discussed as one of the major features of the Obama ’08 Technology Plan (still available for review at the campaign web site).
This is an interesting “new” position. Our Federal Government already has a top-of-the-house Chief Information Officer role (the Administrator of the Office of Electronic Government and Information Technology at the Office of Management and Budget) that seems to have accountability for most, if not all, of the responsibilities articulated in the CTO role. Per the plan, CTO will specifically:
• Ensure that our government and all its agencies have the right infrastructure, policies and services for the 21st century
• Ensure the safety of our networks and will lead an interagency effort, working with chief technology and chief information officers of each of the federal agencies, to ensure that they use best-in-class technologies and share best practices
• Focus on transparency, by ensuring that each arm of the federal government makes its records open and accessible as the E-Government Act requires
• Focus on using new technologies to solicit and receive information back from citizens to improve the functioning of democratic government
• Ensure technological interoperability of key government functions
Both CIO and Deputy CIO roles also exist at other levels in the vast Federal Executive Agency structure and many of these people are members of the Federal CIO Council.
Also, the nation will be getting a new head of the National Cyber Security Center in the Department of Homeland Security (a.k.a. “Cyber-Security Czar”) as part of the new administration as well. That position should not be confused with that of the CIO of the Department of Homeland Security.
If you’re beginning to become confused as to the structure of IT in the Federal Government, you are exactly where I am on that subject (although that really isn’t the point of this post).
Outside of the articulation of the new CTO role and its responsibilities, the rest of the plan is a statement of how technology (not just information technology) will be used to accomplish some important transformational goals. All of them to some extent rely on a critical enabler – the existence of a digital high-speed communications infrastructure – that is listed as a specific goal in the plan as well.
So the new administration appears to be tasking the new CTO with critical interagency work, the creation of a digital infrastructure and is planning to “Employ Technology and Innovation to Solve Our Nation’s Most Pressing Problems” (another technology-enabled set of goals) in the plan.
Sounds like a challenging job! Unfortunately, given my own experience with the way IT is structured in the Federal Government, I don’t believe that it is positioned for success as it is currently envisioned.
As noted earlier, CIO leadership is at multiple levels in the Federal Agency structure. A federated-style CIO Council exists, along with designated leaders for important activities, like Information Security. The initiatives that the new CTO is responsible for cut across Agencies/Departments and no authority (or budget) currently exists to accomplish them. Add to this the overlap with the Federal CIO (OMB) job and/or its limited success with inter-agency technology governance, and I just don’t see how the new role can be successful without substantial reengineering of IT decision-making authority.
In the private sector, this would take the form of a negotiation between the various IT groups about governance (architecture), funding (budget authority) and investment for IT for each IT service domain. A simplified decision-making authority matrix to be drafted might look something like this.
Translated to the task at hand, the IT groups participating would be from the Agencies (representing LOB IT), Departments (representing business-domain specific IT, like Treasury), the CIO Council (representing central IT to-date), the OMB CIO (ditto) and the CTO (ditto).
Their mission would be to agree on who gets to makes the decision on architectural direction, investment, and spending for each domain. The groups would need to normalize a bit, perhaps with a future state diagram showing one combined central IT organization under the CTO (?) consisting of the various architectural domains (Enterprise Architecture), an interagency Program Management Office, perhaps some sort of Managed Services Organization and Security function. The key would be to have strong support and sponsorship for this as the single central (?) Federal IT Organization.
Therein lies the major problem as I see it. As loathe as I usually am to come up with organizational solutions to technology problems, I believe that this case may be an exception. The new CTO role, if it is to be successful, should be a direct report to the President – a Cabinet-level position. Otherwise, it will lack direct political linkage to its sponsor and be at risk of becoming another great idea that languishes (like in the private sector) because the legacy structure will not allow it to move forward.
I’m sure that many of you have experiences where a position or program of work was less than successful because of its positioning within the organization. Given this is my first foray into this subject area; I’d love to hear your thoughts one way or another on my thinking here.
Also, because I’m quite confident in the ability of our Federal Government to “find” information on the Internet, I very respectfully offer the following:
Dear Mr. President,
Congratulations on the new job! Hope the move is going well and that you and your family are getting settled in the new place.
The information that you’ve seen on my site regarding the new CTO role is intended only as a suggestion. I’m sure that there are many things that you are working on to ensure the success of this new role.
That having been said, if you happen to wish to discuss this further, or perhaps need a special consultant on the matter, please give me a call on my mobile (224-234-8682) or email me at www.itstraighttalk.com and I’ll be happy to assist at my special new inaugural rate.
Thank you for your time.
Best Regards,
Eric Davis
(From FAQ) I’ve heard a lot of talk about the Value Proposition of IT. What is it?
Value, at least economically speaking, is simply what you receive for what you are spending. In determining the value of IT services, depending on the business and the particular service, that value may have other dimensions than cost. The value proposition of IT depends on the services offered by IT, the measures of value articulated for these services by the business, how well IT is delivering against those measures and the weighting of that performance across services.
For example, I would suggest that for commodity services, where industry standard measures of service quality exist and may be benchmarked against, that the main dimension of value is cost at the standard service level. For delivery of business solutions or capabilities, the main dimension of value may be speed to implement (versus the most economical method), thus enabling a business advantage in time to market. For other services, quality may be the most important dimension of value to the business.
The business plays a key role in ensuring that the appropriate value proposition is defined and realized. IT can help frame the discussion, but it is the business that has to articulate the appropriate weightings for the dimensions of value. From that information, and agreed-upon measures, an objective scorecard may be built and maintained to determine how well IT is delivering against that value proposition.
(From FAQ) Isn’t IT transformation to a managed services model a big deal – and what about the people in IT?
Before going further, let’s make an important distinction between transforming to the managed services model and outsourcing or multi-sourcing. One is not the other.
Implementing a managed services model gives you the tools to run IT like a business. That includes the ability to source services in different ways (insource, outsource, multi-source), but does not require it. The changes for IT people during the implementation of a managed services model are primarily in roles and responsibilities that correspond to new or modified service delivery processes. People’s jobs are changing. When implementing a multi-sourcing strategy, jobs are at stake.
The transformation to a managed services model is a big deal. It involves fundamental changes to processes, organization and technology. Extensive support is required from the Finance and HR functions. Customers of IT will interact differently with IT in procuring services. It’s a lot of change. In my experience, IT people can learn and operate successfully in the new paradigm fairly quickly – a matter of a few months – so long as the management team invests heavily in time to communicate the vision and value of the new managed services model (not just speeches, true interactive sessions) and provide training.
Implementing a multi-sourcing strategy is much more difficult to manage from a staff impact perspective. Presuming that you have already done the diligence and have a compelling case to pursue significant outsourcing of services, my advice is for full disclosure as soon as you have any sort of timeline for the process. If you are in an IT leadership role, you will soon find that your communications and staff interaction on this topic consume the lion’s share of your time. It’s time well spent, since you’ll want to minimize attrition – particularly of your best people, who know that they have options and can easily make a move.
Unfortunately, the answers that IT people most want to know (what happens to me, specifically) aren’t generally available until the end of the process. That is deeply unsatisfying to someone who is directly impacted. What I’ve found to be of value is to communicate throughout the process about what the various steps of the process are and will be known when.
The bottom line is that people will have choices to make and a time frame in which to make them. If someone is in the outsourced services scope, then the choices are generally pretty straightforward:
- A non-IT role at the current company
- An IT role that is not in-scope at the current company
- An IT role with the company that the services are sourced to
- Severance Package
- Retirement
The timing of when each of these will be known and available varies; so impacted staff will probably have multiple decisions to make. HR will be your best friend in helping to manage the information and processes for the various options.
Successful transformation programs invest heavily in an Organizational Change Management program of work that runs in parallel to the transformation workstream. These efforts are mostly communications-based and are vital in keeping the IT group informed and engaged during the transformation.
One of the most important points in these communications is that the transformation to a managed services model does not mean that IT jobs are being outsourced. In fact, unless both the goals of the business and IT transformation are best met by outsourcing as soon as possible, I would strongly suggest against the two efforts (IT transformation to a managed services model and IT outsourcing) being done as one – and then even so, I would caution that it will be a very bumpy ride for both the business and IT.
Again, the transformation to a managed services model positions IT to be able to source its services internally, externally or in any combination along the sourcing continuum. I believe that this multi-sourced model is the only way for IT to be competitive from cost, service quality and capability dimensions in today’s continuously changing global technology marketplace. However, it is highly advisable that the managed services structure first be in place and operational before implementing a multi-sourcing strategy.
Be prepared that no matter how well you communicate and execute this process, you will be the least popular person in IT for some time. Read Colin Powell’s Leadership Presentation – particularly the last page on “Command is Lonely.” It may help you though a difficult time.
2009 Greetings and Housekeeping Notes
Hello Everyone,
I hope that you all had a great holiday season and are now well-positioned for a prosperous 2009!
Before getting to the new posts for this year, I wanted to give you all a heads-up on two changes to the site. This week, I’ll be moving the posts on the FAQ page to the main blog page and deleting the FAQ page (it wasn’t being hit often and hadn’t been updated since the site launch). Also, I’ll be implementing a a new Theme to freshen things up bit (nothing radical, just something a bit brighter). After those items are taken care of, we’ll get to the new posts for 2009.
Thanks for your continued interest, and keep those comments, questions and suggestions for new topics coming!
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.
-
Archives
- September 2009 (1)
- August 2009 (1)
- July 2009 (2)
- May 2009 (1)
- April 2009 (1)
- March 2009 (1)
- February 2009 (3)
- January 2009 (5)
- December 2008 (4)
- November 2008 (1)
- October 2008 (5)
- September 2008 (5)
-
Categories
- BCC
- BES
- Blog Question
- Business Value Discovery
- CEO Questions
- Change
- CIO Role
- Cloud Computing
- Cost
- CTO
- Culture & Values
- Decision Making Authority
- Enterprise Architecture
- FAQ Query
- GSA
- Housekeeping
- Introduction
- Investment
- IT Roles
- MADI
- OCM
- Operations
- Political
- Problem
- Request
- SaaS
- SOA
- Solution
- Solutions Delivery
- Supply and Demand
- Transformation
- Value
-
RSS
Entries RSS
Comments RSS

