The CIO in a large insurance company was under pressure. Business executives were complaining about the IT department's opacity, unresponsiveness, and poor understanding of their business strategies. They were frustrated that they couldn't control IT's priorities, and they didn't understand why many of their requests weren't being fulfilled.

There was even a trend toward decentralization. Many business units had started their own little IT groups, which the CIO disparagingly called "shadow IT." (Of course, the shame was his, not theirs. These groups only existed because business units didn't want to do business with Corporate IT.)

In response, this CIO dedicated a group to each client business unit, and divided his engineering staff among them. Each group was relatively self-sufficient, with all the skills needed to deliver any applications requested by its assigned business unit.

These senior managers also served as the primary liaisons to those business units.

Reporting to the CIO were:

• Janice, Sales and Marketing
  
• Bill, Finance
  
• Henry, HR and other Corporate functions
  
• Eugene, Engineering and Manufacturing
  
• IT infrastructure and operations

This client-aligned structure was akin to decentralization, but with formal lines of reporting remaining within Corporate IT.

He felt this structure would appease the business units and stave off further decentralization. He also felt it would help him hold his senior managers accountable for business results and client satisfaction, with no opportunities for finger pointing.

For a while, this structure seemed successful. For example, Sales and Marketing clients felt that IT was more responsive to their needs. It wasn't that Janice's staff worked any harder. But since clients understood the limits to their resources (the people in her group) and could control their priorities, they were more understanding when Janice explained that she couldn't do everything they wanted because her group was busy with other projects for them.

Clients also felt that IT better understood their business. Since Janice and her staff worked with the same clients day after day, a better partnership developed.

At first, clients were happy and the CIO felt less "heat" from his executive peers.

But then, dissatisfaction reemerged. Here's why....

Weak at Relationship Management

The client-liaison function was a part-time job for Janice. But with a big group to manage, she didn't have much time to spend with clients. At best, she provided a point of contact. But she didn't add much value to clients' strategic thinking.

To make matters worse, Janice faced a conflict of interests. While she was able to maintain good relationships, the advice she offered was biased by the capabilities of the applications engineers that happened to be in her group. Regardless of clients' real needs, she only delivered traditional applications.

Limited Collaboration

Her engineering function was sub-optimized as well. Janice needed a variety of technical specialists in her group to satisfy her clients' needs. So did her peers. Each technology sub-specialty was scattered among the various client-dedicated groups.

This limited their professional exchange. When Janice's staff ran into technical challenges, they might not have known that someone in another group had already figured out the answer. Even if they'd heard of others' work, their peers were busy with other priorities. Costs rose and response times slowed as everybody reinvented solutions to common problems.

Dis-integration Costs and Lost Synergies

All clients needed information about money, customers, employees, and products. Over time, this structure led to multiple general-ledger systems and multiple records for the same customer. Synergies were lost as the company lost a single view of its customers, its resources, and its suppliers.

Meanwhile, there was little impetus for standards. The people in Janice's group built systems that were optimal for their specific clients, not for the enterprise as a whole. When the company sought cost savings through the consolidation ("rationalization") of applications, they found it difficult. Few of the existing applications could be used more broadly.

Reduced Specialization

This structure also reduced the engineers' ability to specialize. Each group had to produce every type of application needed by its clients. With reduced specialization, costs rose, quality suffered, and response times slowed.

Furthermore, the pace of innovation slowed. They couldn't hire an expert in an emerging technology when there was only enough demand for one person to be shared across the whole enterprise. They had to wait until demand grew to the point where each business unit alone could justify the headcount.

As a result, business opportunities were missed. For example, Janice didn't have specialists in web and mobile applications that would have allowed customers to review and edit their accounts. They missed opportunities to build customer loyalty, just as competitors were hot on the trail of the "digital enterprise."

Slippery Slope to Decentralization

Due to all these problems, this customer-aligned organization didn't deliver the advantages of its size. It performed no better than a number of small decentralized groups. It wasn't long before business-unit executives demanded decentralization of the applications engineering function, rightly pointing out that there was little benefit to centralized reporting.

This CIO had failed to gain the benefits of being one organization. In truth, this was an organization that didn't deserve to stay together because it wasn't adding value.

Abstracts Free library

Books Speech abstracts

NDMA coaching/consulting services

UP.... NEXT PAGE....