topleft
topright

CIOZone.com Platform Blog

A Blog to discuss the underlying technologies used for the CIOZone as well as commentary on our experiences in using them.


Oct 29
2010

10 Mistakes CIOs Make When Designing IT Units

Posted by Bill Gerneglia in Untagged 

Bill Gerneglia

The following is from a report by Forrester Research

 

CIOs frequently change the structure of the IT organization to reduce costs, improve services, or increase responsiveness. Getting the organization design right is essential; the wrong design can degrade business relationships, reduce effectiveness, and damage culture. Forrester analysts have evaluated and helped redesign hundreds of IT shops. From this experience and an in-depth review of 25 organizations, we compiled 10 common organization design errors that significantly hinder the effectiveness of organizations.


Gross IT Design Mistakes Cost CIOs


A good design for IT consists of processes, structures, and a culture that all support the direction of the business (see endnote 1). A bad IT design sets up barriers that hamper a business' movement in this direction. Most IT shops are striving to improve how they contain costs, manage services, introduce new technologies, and execute projects. And in many firms, CIOs are going beyond this to improve enterprise projects and services, establish partnerships between lines of business and IT, and increase the effectiveness of their vendors. The most serious mistakes in the structure of an IT organization run counter to these goals and create significant obstacles to the business' progress.



Forrester measures the magnitude of impact of design mistakes based on their breadth, depth, and duration. In terms of breadth, a design flaw that impacts multiple business units or geographies is more severe than one that affects a single group. For depth, a mistake that creates compliance problems is more significant than one that generates minor inefficiencies. Finally, a flaw that causes problems for years is worse than one that the organization overcomes in a few weeks.


The top 10 mistakes in the designs of IT shops, from highest to lowest impact, are:


1. Conflicting culture and structure. When there is a conflict between the design of the organization and its informal norms and behaviors, the design will fail.


Example: A catalog company failed with collaboration because of its culture of autonomy. The global CIO of this 200-person IT shop set up a management committee to prioritize IT investments. However, before the creation of the management committee, investment decisions rested with the CEO - who made unilateral decisions—and the leaders of individual business units—who made decisions for their units independently. After two meetings, business leaders lost interest, and the CIO disbanded the group. As a result, the company's history of deploying narrow solutions with poor integration continued.


2. A management style that conflicts with IT goals. The choice of a bottom-up (i.e., frontline employees make decisions) or top-down (i.e., senior management makes decisions) decision-making style must match the goals of the organization (see endnote 4). Example: A large life insurance company created a small vendor management (VM) function to quickly reduce vendor costs, but the VM function it chose never met this goal. The business chose a facilitative style where VM merely provided information on vendors and relied on numerous other groups to manage them. While some vendor relationships improved, the plan did not realize cost savings; the style of VM chosen had too little oversight and control to make significant changes quickly—a necessity for getting the lowest vendor costs.


3. Metrics that don't support the direction of IT. You get what you measure and reward. Measurements that are out of sync with the goals and principles of the organization will drive the wrong behaviors.


Example: A financial services firm asked for leadership but measured tactics—and received tactical performance, not leadership. This organization measured its IT architects regularly, based on 15 to 20 detailed tactical elements, causing the IT architects to focus primarily on checking off items on this list and neglect the company's need for technology leadership. By using metrics that conflicted with its goals, the organization lost an opportunity to lead the movement to new technology and confirmed the widespread view within the organization that architects were merely techies without business savvy.


4. Weakened strategic functions. Architecture, planning, vendor management, and other nonoperational functions are structurally weak. They lack the traditional levers of power: large budgets, management of key systems and services, and ownership of customer relationships. CIOs further weaken these groups in a variety of ways: by dividing and distributing them among multiple groups; by having them report low in the organization; by preventing their ownership of or involvement in key processes, such as project initiation; and by insulating them from real-world responsibilities.

 

Example: A travel company diluted the power of its architects, resulting in a loss of strategic thinking. This company distributed architects to infrastructure, applications, and other functions within IT. Dispersing them among multiple development and infrastructure groups forced them into daily firefighting and project work that prevented them from developing standards and processes that had long-term value.


5. Overly fragmented functional groups. Fragmentation occurs when organizations slice functional groups, such as applications development, into small pieces where everyone must do everything, including requirements definition, development, testing, and maintenance. This leads to a lack of specialization that reduces efficiency.


Example: A media company chopped up its applications groups, thereby reducing the quality of their output. This shop divided its 150-person applications organization into 11 groups organized by a mysterious combination of customers, products, geography, and technology. With so many people using such a wide variety of technologies, tools, and methodologies, nothing was done well, particularly in areas of testing and reuse.


6. The implementation of transition at the wrong pace. Moving too quickly or too slowly to a new structure is problematic. Quickly changing to a new organization without adequate planning and participation will result in confusion over responsibilities, breakdowns in customer relationships, and generally poor designs. Converting too slowly creates anxiety as people wonder if they'll have jobs and who their bosses will be.


Example: An engineering firm planned a redesign for more than a year and lost productivity; at the other extreme, a retailer reorganized too quickly, losing important interfaces and key roles. In the first case, an 800-person engineering shop spent 10 months just in the assessment phase of an IT redesign, and self-preservation calcified the organizational joints as people wondered if they'd have jobs, what their jobs would be, and who would be in charge. In contrast, a CIO at a European retailer shocked his staff by reorganizing three months after starting the job. His hasty restructuring caused long-term customer interfaces to disappear and key roles, such as testing, to fall through the cracks.


7. Fragmented and informal management of services firms. Companies often make the mistake of having multiple groups manage consultants and outsourcers as a part-time job. This results in inconsistent and inefficient selection and oversight of vendors.


Example: A global builder dispersed the management of services vendors, which led to a variety of problems. The CIO of this company let each IT group select and manage consultants as they saw fit. Most that did this took on the task part of the time and very infrequently, leading to poor vendor selection and high costs. This lack of professionalism also prevented the organization from gradually improving its management of services firms.


8. Weakly structured and managed enterprise projects. Enterprise projects are demanding because they require the coordination of business units that often have conflicting priorities. A frequent mistake is to run enterprise projects with a small group that merely coordinates the activities of those executing the project. This slows implementation and increases the difficulty of integration.


Example: A global insurer used volunteerism to execute an enterprise project but found that the business units involved had trouble focusing and agreeing once it came time to implement the enterprise group's plan. This company set up a team of four to execute a project that combined multiple products from three major business units. It created the plan, gained agreement, and provided direction for people within the business units to execute. However, progress slowed to a crawl as the business unit teams struggled to agree on project specifics and were continually pulled back to firefighting within their departments.


9. Functional segmentation that creates barriers, reducing coordination. Separating some functions, such as requirements definition from implementation or vendor selection from contract management, causes loss of accountability and excessive hand offs.


Example: The CIO of a food services company separated maintenance from development, setting up both functions as direct reports, and ended up with disparate groups that did not work together or communicate effectively. This separation resulted in maintenance groups that were unprepared to support applications built by development and development groups that built applications that were not structured to be easily maintained.


10. An excessively broad span of control. Having too many direct reports forces IT leaders to spend excessive amounts of time on narrow issues.


Example: One government infrastructure leader created a structure with 14 direct reports and soon found himself spending most of his time coordinating between subordinates or dealing with personnel issues, with little time left for working with peers or superiors.

Comments (0)Add Comment

Write comment
You must be logged in to post a comment. Please register if you do not have an account yet.

busy




White Paper Library

Copyright © 2007-2014 CIOZones. All Rights Reserved. CIOZone is a property of MMINC Digital Inc.