Forrester recently gathered in-depth information on the common reasons for failure across the strategic IT functions of vendor management, architecture, planning, relationship management, security, and demand management \u2014and what can be done to mitigate or avoid failure. In our research we defined failure as underperformance on expectations sufficient to require a change in the leadership of the group or a redesign of the group itself.\nVendor Managers failed by exercising either too little or too much control. The most common reason, too little control, resulted from VMs distributing far too much decision-making and oversight to others in the organisation. Too much control was seen when they took a hands-on approach to managing vendors but lacked sufficient expertise or capacity.\nWhen Enterprise Architects failed, it was primarily because they became either pushovers or tyrants. When they were pushovers, we saw the buildup of overly complex technology environments, confusion over which tools to use, redundant applications, and systems that wouldn't scale. Less common was when architects became tyrannical. When this happened, we saw over-engineered IT processes, end users bypassing IT to get what they needed, and systems that were robust but lacked business value.\nPlanning failed primarily because it lacked organisational credibility, particularly for long-term planning, and because planning activities were crowded out by more operational concerns. The most common reason for this were limitations in the planners' abilities and the fact that planning was often a part-time function of very busy people. The most common result of planning failure was an IT organisation swamped with projects and other duties that focused primarily on immediate or narrow problems.\n4 steps in developing a business technology strategy\nThere are two overarching reasons why Relationship Managers fail. On the one hand, they go 'native' and become purely advocates for their business groups. The other is that their role becomes much too tactical and, at worst, an extension of the help desk. The consequences of failure of the RM function were a poor relationship between the business and IT; excessive customization of applications; and a large, complex portfolio of systems.\nThe most common underlying reason for Security failure was that security leaders lacked the skills to determine the appropriate level of risk needed and then sell this to the organisation. Security leaders often passionately advocated for procedures that the rest of the organisation viewed as excessive. The inability to convince others and their apparent inflexibility marginalized security leaders and reduced conformance to standards.\nThe overarching reason for Demand Management failing came from the demand side. Those implementing this function had little oversight or control over IT requirements from the business. They often lacked the ability to set up mechanisms to control these requirements and forced IT into a largely reactive position. However, there were two underlying reasons for failure. One was that DM is implemented by multiple people in a disconnected way. Second is that DM is not a mature discipline supported by well-known best practices.\nStrategic Roles Must Balance Facilitation With Top-down Control\nForrester recommends strategic roles to strike a balance between telling people what to do and merely providing information so others can make the decisions. If there's too much top-down control, the IT organisation will bypass these roles. If there's too little, things won't get done. However, this doesn't mean that all roles are the same in how they guide decision-making. Some will succeed largely through persuasion, others through a stronger hand. Though every organisation is somewhat different in how these strategic roles operate, to be successful:\nRelationship managers, architects, and planners should use bottom-up decision-making. These roles will have little success if they are autocratic. The best planners have other people do most of the planning. They provide information, a framework for decision-making, and other mechanisms for businesspeople, and others in IT can develop plans. However, there are times when each of these roles needs to make a decision if others can't. Architects should provide information and mechanisms for others to decide on standards; however, when the time required to make a decision is beyond reasonable, architects need to close down discussion and make the call.\nVendor managers need to align their style with the need for cost reduction.Most organisations start a VM function to reduce the costs of vendors. To build credibility and take advantage of low-hanging fruit, VMs need to quickly cut loose vendors who are retained solely because of history, personal connections, or momentum.\nSecurity should be more top-down in forcing decisions.None of these strategic roles should be dictators. However, security experts typically need to step in more often and sooner to force a decision. The complexity and esoteric nature of security issues require security experts use their personal credibility to drive a decision.\nReinforce structurally weak roles.Planning, architecture, and relationship management are structurally weak. They lack large organisations and budget control, and they don't build or maintain systems that support the business. CIOs need to reinforce their base of power through access to senior people, decision-making authority, and selecting people for their ability to influence without formal authority.\nAbout the author:\nMarc Cecere is Vice President and Principal Analyst at Forrester Research serving CIOs. Marc blogs at: https:\/\/blogs.forrester.com\/cio.