We Still Don’t Know How To Manage IT

I just finished listening to the recent press conference of Secretary of Defense, Robert Gates, on his planned restructuring and rationalization of the Department of Defense. I was struck by his description of the IT function within the Department as inefficient and the duplication of basic IT capabilities across the organization. It sounded as if every command at all levels had their own independent IT functions.

This in and of itself is not surprising in a large bureaucracy, but it does cause one to wonder who is running the show. There is an overall Department CIO and most likely many Command level CIO’s. I’m sure they all want to protect their turf but there is a more important public service responsibility to run IT in as cost effective a manor as possible using the technologies available today.

Addressing this problem requires that senior management at all levels understand two basic principles of managing IT. First, the value of IT is delivered through applications and the design, development or purchase of these applications needs to be close to and under the control of the end users. Second, the technology tools supporting these applications (data centers, servers, networks, desktops, mobile devices and most support functions) need to be managed at the enterprise level of the organization. The reason is simply that there are enormous economies of scale in acquiring and managing these resources.

One additional reality is that end user demands drive the need for IT resources and this demand needs to be controlled in two ways. First, the enterprise needs to make sure the capability being requested doesn’t already exist within the organization to avoid duplication. Second, truly new capabilities need to be justified by a strong business case.

So what does DOD need to do to get it’s hands around the issues it faces? Here are some ideas:

1. Consolidate data centers into an overall DOD network. EDS and all the major outsourcers have known for years that there is an optimal size for a data center, and all suboptimal centers should be closed and their functions transferred to the enterprise’s data centers. I’d did exactly this years ago at McGraw Hill and we generate substantial savings, though I admit it was a difficult political job. I also supported doing this in Oregon’s state government, proving the politics can be overcome if the rational is strong enough.

2. Consolidate networks which are a major IT expense and in most cases duplicative and overlapping.

3. Virtualize servers where ever possible. We all know that servers dedicated to a single application are typically underutilized and that the technology now exists for servers to support multiple applications.

4. Centralize the purchase of desktops and mobile devices to gain the purchasing economies of scale.

5. Centralize all support functions into centers of excellence.

I would not be surprised if DOD could cut it’s IT cost by as much as 50% without negatively impacting service. This was exactly my experience at McGraw Hill when I was asked to rationalize the IT organization in the early 1980’s.

The principles for effectively managing IT in large organizations is not a mystery and they have been proven over and over again. Unfortunately, there have been classic failures in applying these principles, the Texas and Virginia debacles come to mind. It’s essential that leadership at all levels clearly understand they are wasting valuable resources that as Secretary Gates said can and should be redeployed to meet the organization’s primary mission, goals and objectives. Selling these principles to the organization’s leadership and then executing these principles is the primary mission of the Department’s CIO.

I would appreciate your thoughts on this blog through your comments or you can contact me direct at any of venues below.

William A. Crowell
Wcrowell@asuret.com
LinkedIn: Bill Crowell
Twitter: billcio

We Need Outsourcing Marriage Counselors

CIO Magazine had a very interesting article by Stephanie Overby published this week entitled “Don’t Mess with Texas: 7 Lessons from State IT Outsourcing Disasters”. Her 7 lessons learned from IT outsourcing debacles in Texas, Virginia and Indiana included:

• You Get What You Pay For
• You Get What You SLA For
• When the Going Gets Tough, The Tough Go Public
• You Can’t Sue Your Way to a Better Relationship. But You Can Try
• Outsourcing Means Never Having to Say You’re Sorry
• Outsourcing Will Not Cure Internal Inertia
• If At First You Don’t Succeed, Try Again. And Again

The article goes on to say “It took San Diego County two outsourcing contracts—and three different CIOs—before it got its outsourcing deal on the right track”, which is a reference to a May 2006 article that Stephanie wrote (“Government Outsourcing: San Diego Tries to Learn from Contract Mistakes”).

The problem with Stephanie assessment, especially the idea that San Diego got it right the second time around, is the belief that the outsourcing contract is the basis for success. My argument is not that having a sound contract is a bad idea but simply that any third party relationship has to be based first on a solid foundation of mutual respect, empathy and trust.
The contract is like a prenuptial agreement, if things don’t go well it’s the basis for resolution of any disputes. Once the marriage is consummated and the deal signed, the players on both sides need to work on developing their relationship.

The starting point for this relationship is mutual respect. The client needs to understand that they have hired expertise in IT from the outsourcer because IT is not their organization’s core competency and that their organization has made the outsourcing decision based upon a belief that the outsourcer will provide more efficient and effective IT services. Anyone in the client organization that is not committed to these fundamental principles should not be involved in the outsourcing relationship.

From the outsourcers perspective, they need to demonstrate from the get go their core competency in IT and clearly document the ways in which they are improving the efficiency and effectiveness of the IT services they are providing. The profitability of their relationship should be the result of the superior services they are providing and not the principle goal of the relationship. Here again, any member of the outsourcing vendor that doesn’t embrace these principles should be removed from the account.

Empathy is a second essential element of the third part relationship. The client needs to understand that their outsourcer is not a charity and needs to generate a reasonable profit if the relationship is going to be sustained over the long run. The outsourcer needs to understand their client’s cost concerns and make sure they are clearly demonstrating that their services are competitive. Empathy implies flexibility on the part of both parties. The client’s demands must be reasonable and not place an unfair burden on the outsourcer and the outsourcer must be willing to give when there are issues with the quality or effectiveness of the services being provided. If the outsourcer has over promised the services they can provide for the price they quoted, not an unusual situation, then these issues need to be addressed head on. The question can best be addressed by determining a fair price and an appropriate discount that reflects the outsourcer’s prior commitments.

If mutual respect and empathy have been established, then the conditions exist to build the third leg of the stool – trust. Trust clearly takes time to develop and is the most valuable element of any relationship. Any actions by either party that would violate the others trust is a strategic relationship issue and needs to be effectively addressed by the senior management of both parties. Nothing can cause a relationship to unravel faster than the loss of trust.

If your considering outsourcing or have already entered into an outsourcing relationship, develop a sound contract and then put it on the shelf. Focus on developing a solid relationship based upon mutual respect, empathy and trust, and my bet is you’ll never need to refer to the contract again or at least only in the most unique circumstances. If problems develop, consider working with a marriage counselor before ending up in a failed relationship.

William A. Crowell
wcrowell@asuret.com
twitter: billcio
LinkedIn: Bill Crowell
My Blog: http://bcrowell.wordpress.com/

Why is being a CIO such a tough job? The role as Change Agent

In my experience when you join an organization at the CIO level you are most likely being hired as a change agent. You’re being asked to fix a dysfunctional IT unit, lead a major systems modernization effort, establish an IT strategy for the organization or fix a failed project. Seldom if ever do you join a stable organization with the goal of implementing a well-defined IT strategy. Your role by definition is that of an agent of change. In this context I’ve asked the question, what are the pros and cons of the change agent role?

Since being a change agent is typically a central part of a new CIO’s role, it makes sense that we need to understand the change process and where we are in that process. Abbie Lundberg’s recent blog entitled How to Survive in a World of Constant Change presents a simple and straightforward change model that I’ve applied throughout my career, without even knowing I was doing so. The model has three stages:

1. Unfreeze – preparing people for change.
2. Change – implementing the change.
3. Refreeze – assuring the change becomes the “new normal”.

As I look back, when I’ve taken the time to unfreeze the organization and make sure people understand the problems we face and the opportunities that fixing the problems enable, then the changes can be developed and implemented on a collaborative basis by a team committed to the changes. I’ve not focused specifically on the refreeze phase of the process but it makes sense that once the changes are implemented people need time to adjust to the new normal.

The challenge for the CIO is to fulfill the change agent role without getting pigeonholed as a techie or Mr. Fix-It. Therefore, before diving into fixing specific problems, the IT organization should collaboratively develop a strategic plan with significant input from the business. The plan should clearly define:

1. The current situation with specific examples and data that support the team’s conclusions. Defining and communicating the problems created by the current situation is an excellent way of unfreezing the organization from long held and in many cases spurious beliefs.
2. The future state providing a vision of where we want to be and the benefits of getting there. This is a second element of unfreezing the organization and preparing them to implement the changes that it will entail.
3. A detailed implementation plan laying out what will be accomplished, when, by whom and the estimated costs and benefits. This becomes the blueprint for change, sets expectations and provides a baseline for measuring and communicating progress.
4. A control cycle that reports progress, lessons learned and updates to the plan. This is essentially the refreezing process designed to demonstrate a new level of expected performance from IT.

It’s been my experience that joining an organization, as the new CIO, positions the individual to be a major agent of change. However, the drawback is that your peers view your plate being full as a defensive measure to keep you from examining their operations and recommending specific changes. If people don’t perceive a clear need to change they will in my experience resist change.

All too often we in IT think in terms of all the ways we can apply technology before allowing the organization to unfreeze. We need to understand the problems or challenges that the organization faces before we offer solutions. Moreover, these solutions need to clearly address the problems or challenges and equally clearly define costs/benefits in business terms. Specifically, how will the solution enhance customer satisfaction and revenues, lower operating costs and/or reduce investment in assets required to operate the organization.

In summary, to maximize the opportunities that the change agent role provides and minimize the drawbacks take time to unfreeze the organization, provide a clear vision of the future and the path for getting there and allow time for the organization to refreeze and adjust to the new normal before continuing the move forward.

William A. Crowell
wcrowell@asuret.com
Twitter: billcio
LinkedIn: Bill Crowell
My Blog: http://bcrowell.wordpress.com/