<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>CIOforum</title>
	<atom:link href="http://www.cioforum.be/be/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.cioforum.be/be</link>
	<description></description>
	<lastBuildDate>Mon, 14 May 2012 08:39:46 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3</generator>
		<item>
		<title>Press Release : ‘New Association Launched To Create A Stronger Voice for CIOs in Europe’</title>
		<link>http://www.cioforum.be/be/2012/02/16/press-release-new-association-launched-to-create-a-stronger-voice-for-cios-in-europe-2/</link>
		<comments>http://www.cioforum.be/be/2012/02/16/press-release-new-association-launched-to-create-a-stronger-voice-for-cios-in-europe-2/#comments</comments>
		<pubDate>Thu, 16 Feb 2012 20:14:19 +0000</pubDate>
		<dc:creator>nouke</dc:creator>
				<category><![CDATA[Overview Sessions & News]]></category>

		<guid isPermaLink="false">http://www.cioforum.be/be/?p=1806</guid>
		<description><![CDATA[New Association Launched To Create A Stronger Voice for CIOs in Europe Chief Information Officers and IT user representative bodies across Europe unite under an Association banner.  Immediate aims include addressing European skill shortages and ensuring that the European Commission’s Consultation on Cloud Computing reflects business concerns over security, global harmonisation, accountability and vendor behaviour. Press Release CIOforum &#8211; European CIO Association &#8211; English Press Release CIOforum &#8211; European CIO Association &#8211; Nederlands Press Release CIOforum &#8211; European CIO Association &#8211; Français]]></description>
		<wfw:commentRss>http://www.cioforum.be/be/2012/02/16/press-release-new-association-launched-to-create-a-stronger-voice-for-cios-in-europe-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>CIOforum 2011 Year End event &#8211; &#8220;CIO 2020 “A generation gap?…”</title>
		<link>http://www.cioforum.be/be/2011/12/19/cioforum-2011-year-end-event-cio-2020-a-generation-gap/</link>
		<comments>http://www.cioforum.be/be/2011/12/19/cioforum-2011-year-end-event-cio-2020-a-generation-gap/#comments</comments>
		<pubDate>Mon, 19 Dec 2011 15:47:15 +0000</pubDate>
		<dc:creator>dvanhove</dc:creator>
				<category><![CDATA[Overview Sessions & News]]></category>
		<category><![CDATA[CIO 2020]]></category>
		<category><![CDATA[CIO Study]]></category>
		<category><![CDATA[IBM]]></category>
		<category><![CDATA[Saskia Van Uffelen]]></category>

		<guid isPermaLink="false">http://www.cioforum.be/be/?p=1747</guid>
		<description><![CDATA[Every year the CIOforum celebrate the end of the working year with an elegant evening for members and business partners. This year end event we talked about the CIOforum achievements of the past year and once again we have the honor to welcome a series of excellent guest speakers at a superb location. After the introduction and welcome by IBM&#8217;s Country Manager Jacques Platieau, our members and business partners were presented a very in-depth overview of the recent CIO survey conducted by IBM. Saskia Van Uffelen, CEO of Bull toke stage to talk about the CIO 2020 and why IT is Cool or need to be cool (again). This year we invited a few students to join a panel discussion to challenge our CIO members and ask question why they should consider a profession in I. The setting was excellent and also the dialogue between the youngsters and the &#8216;grey hair experts&#8217;. The evening was closed with a delightfull walking buffet, which was offered by our host and business partner IBM. Another successful year end event with more than 80 participants!]]></description>
		<wfw:commentRss>http://www.cioforum.be/be/2011/12/19/cioforum-2011-year-end-event-cio-2020-a-generation-gap/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>Why Apps, Infrastructure, And PMO Roles Fail.</title>
		<link>http://www.cioforum.be/be/2011/11/29/why-apps-infrastructure-and-pmo-roles-fail-2/</link>
		<comments>http://www.cioforum.be/be/2011/11/29/why-apps-infrastructure-and-pmo-roles-fail-2/#comments</comments>
		<pubDate>Tue, 29 Nov 2011 14:59:45 +0000</pubDate>
		<dc:creator>dvanhove</dc:creator>
				<category><![CDATA[CIO Role]]></category>

		<guid isPermaLink="false">http://www.cioforum.be/be/?p=1698</guid>
		<description><![CDATA[There are a number of roles in IT that can significantly change the organization for good or bad. Through a combination of surveys, interviews, and consulting engagements, we gathered in-depth information on the common reasons for failure across all roles, and the specific reasons for failure in individual ones. For this second report in the series, we focus on the operational roles and identify why infrastructure, applications, and the program management office (PMO) fail and what can be done to mitigate or avoid failure. OPERATIONAL IT ROLES FAIL INFREQUENTLY BUT WITH SIGNIFICANT CONSEQUENCES The success of the IT organization is determined, to a great extent, by the actions of the IT leadership in the following areas: applications, infrastructure, the program management office (PMO), vendor management, architecture, planning, relationship management, security, and demand management. For this second report in a three-part series, we focus on just the operational roles (i.e., those that build or maintain systems) of applications, infrastructure, and the PMO. To determine the frequency, impact, and causes of failure of these roles, as well as how to improve them, we surveyed 45 IT leaders, reviewed the organizational assessment consulting engagements of 32 companies, and interviewed 14 leaders of IT. 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. A few project delays were not enough to label the leader of apps as a failure. However, a consistent track record of late or cancelled projects, poor performance of core applications, and an antagonistic relationship with business leaders was. From this survey, we saw that, with the exception of the PMO, these operational roles had a relatively low frequency of failure. Infrastructure, in particular, was very solid. In contrast, survey respondents reported that the PMO has the second-highest frequency of failure of all the roles we looked at. In terms of impact, we found that applications had greater impact than any role other then planning. Infrastructure had a similarly high impact. Fortunately, the consequences of the high failure rate of the PMO were somewhat mitigated by its lower impact. In general, data from organizational assessments verified these survey findings. Applications Leaders Struggle To Balance Divergent Responsibilities And Skill Sets The overarching reason for failure of this role is tension between serving an individual business unit and serving the entire organization. Medium-sized shops, for example, have two or three apps groups reporting to the CIO. These groups are typically aligned with business units. The leaders of these apps groups must balance satisfying their business unit with supporting IT&#8217;s need to be efficient, in compliance, and responsive to the entire organization. A second fundamental source of failure is the need for the apps leaders to have strong technical and client management skills. Many are excellent at one but weak at the other. From assessments and interviews, we found that the consequences of failure of the leader of apps vary more than any other IT function we studied. However, the most commonly cited consequences were: consistently late projects, a high percentage of ad hoc projects and people dedicated to maintenance, a high degree of redundancy in systems and processes, highly customized applications, an antagonistic relationship with either business leaders or other parts of IT, and a highly provincial IT/client relationship. So what were the specific reasons why apps leaders failed? And what are the most effective tactics for avoiding failure? Starting with the most frequent reasons for failure, we found that they failed because they: Were unable to control the pipeline of work. This appeared in two ways. First, they were unable to educate business leaders on the real risks and costs of IT projects in order for these leaders to be more realistic in their requirements. Second, they lacked the credibility and skill to say no to business leaders or at least to modify their requests to be more manageable. For example, an HMO used its three applications groups as channels for work requests from the business. The leaders of these groups were excellent development managers but lacked the clout to do more than take orders from senior business leaders. Gradually, their organizations built up large portfolios of applications that shared data poorly, were expensive to maintain, and provided redundant functionality. Forrester recommends: Upgrade poor planning and project initiation processes, and gradually enable business leaders to own prioritization. Planning processes should align projects with business drivers and reject those that lack this linkage. IT should insert itself early in the project life cycle and educate business leaders on both the possibilities and limitations of technologies. Finally, the apps leader should provide the business with a decision-making mechanism for approving IT investments. Were too tactical and shortsighted. Apps leaders set up many of the core apps processes to solve short-term problems. One CIO stated, &#8220;We have trouble looking more than a few months down the road — and past the current problems.&#8221; In one case, a Midwestern retailer built up more than 600 applications, many of which were deployed to solve an immediate problem for an individual team. These apps were difficult to maintain, didn&#8217;t scale well, and created huge data sharing and security headaches. This portfolio had been built up over time by apps people who thought only in terms of solving their customers&#8217; immediate problems. Forrester recommends: Develop a picture of your future state and steps for how to get there. Make that future state tangible to the IT organization and specific to the individuals and their roles so they know where they fit in. Include in your steps to the future state projects that reduce the effort required to maintain existing applications, either by eliminating these systems, outsourcing them, or restructuring them to be more stabile. One healthcare company did this by developing the model for a future &#8220;greenfield&#8221; environment that was not encumbered by the company&#8217;s current limitations. It used this model to get people to think beyond their daily firefighting. Became advocates for just their business units. One of the most common observations from assessments was that apps leaders became allies only for the business units they supported. This has obvious advantages and disadvantages. In the short term, this can be good for that business unit, however, over the long term, this forms silos of applications, reducing the ability to share expertise, applications, or data. This fragmentation will gradually increase the complexity of IT, leading to large parts of apps groups dedicated solely to maintenance. For example, a city government consolidated applications groups from a dozen departments that had previously been independent. Though the apps leaders had a new boss, they continued to view all changes in terms of the impact to their department. Eventually, the CIO needed to move half the apps leaders to other positions in order to make progress on consolidation. Forrester recommends: Establish goals and measurements that favor the enterprise. Set up relationship managers, even on a part-time basis, to remove some of the client management duties from apps leaders. Get agreement from business-unit leaders that IT will evaluate business requests to determine if they can be solved by common systems rather than business-unit-specific ones. Have enterprise architects review these requests early in the project initiation process to determine the optimal technology platform. Had a poor interface with the infrastructure group. The perennial tension between apps and infrastructure is evident in the way these groups are measured: apps for functionality and infrastructure for robustness. Three-fourths of the organizations we assessed reported that project initiation, planning, project execution, and other processes were hampered by a cumbersome relationship between apps and infrastructure groups. Common problems included the need for apps groups to work with multiple infrastructure people for project estimates, change management, and problem solving. In contrast, infrastructure often criticized apps groups for not following QA (quality assurance) procedures or for inviting infrastructure people into the development process too late. Forrester recommends: Establish a group within infrastructure to provide the interface for estimates and project execution. Establish a process step to involve infrastructure people early on in projects, specifically during project initiation and design. Create a change management process within infrastructure that is largely designed by apps people but tracked by infrastructure. Infrastructure Leaders Stumble When They Lack Business Skills Or Are Overly Protective The leader of infrastructure is typically in charge of servers, storage, the data center, networks, the help desk, and desktop services. Most IT shops have a single infrastructure group. In a handful of organizations, infrastructure includes the functions of QA and purchasing. What does failure look like for the leader of infrastructure? First of all, it&#8217;s infrequent. From our survey and assessments, we found fewer failures within infrastructure than any other major IT group. The most common symptoms of failure include too many process steps, slow decision-making, an inability to fix underlying problems, a reactive or insular culture, and an antagonistic relationship with other groups, particularly apps. Occasionally, we found an infrastructure organization that was fundamentally unable to run things; however, this was rare. Infrastructure leaders failed for very different reasons from apps leaders. Business leaders were not as involved in or aware of how infrastructure operates and largely didn&#8217;t care as long as it worked. Therefore, infrastructure was not pulled in the multiple directions that apps or other, more client-facing organizations were. So when infrastructure leaders failed, they either lacked the political skills needed to justify investments or got overly protective of the infrastructure at the expense of moving quickly. So what were the specific reasons why infrastructure leaders failed? And what are the most effective tactics for avoiding failure? Starting with the most frequent, we found that they failed because they: Were too tactical or technical. Infrastructure leaders at multiple levels were frequently criticized for focusing largely on day-to-day operational needs in order to be &#8220;heroes&#8221; to their clients. In part, this was because they were measured largely on eliminating or reducing operational problems. However, in most organizations it went much further than this and became an ingrained cultural characteristic — people defined their worth by how quickly they could drop everything and fix customers&#8217; problems. More than other roles, the leaders of infrastructure had very broad spans of control — often eight or more people. This forced them to spend excessive amounts of time dealing with conflicts between people and with administrative issues. Forrester recommends: Establish goals, measurements, and rewards that encourage analysis of the underlying reasons for problems and fixing those. Simplify and automate, where possible, to diminish manual problem-solving responsibilities. Reduce the span of control given to the head of infrastructure to six or fewer people and encourage subordinates to run things on their own. Allow subordinates to make controlled mistakes. Showed poor business knowledge and skills. The effect of this is often felt over the long term. Business leaders don&#8217;t work as intimately with leaders of infrastructure as they do with leaders of client-facing functions such as apps. Therefore, this problem was not cited as frequently as others. However, the long-term implications of this are serious. Lack of business skills makes it difficult to sell infrastructure investments to business leaders, resulting in long-term problems with reliability, security, and performance. For example, the leader of a small infrastructure group within an educational services provider was an outstanding technical leader. However, his recommendations were frequently turned down because he lacked the skill and interest to translate his recommendations into business terms. Over time, the infrastructure became increasingly unreliable, driving business areas to build up their own infrastructures, resulting in even greater unreliability and, eventually, the replacement of the leader of infrastructure. Forrester recommends: Infrastructure leaders need to learn to speak in business terms when discussing infrastructure investments. They need to use techniques such as Total Economic Impact™ or other portfolio analysis methods to explicitly connect infrastructure investments to business goals. Built too much or too little process rigor. Large firms suffered from the layering on of too many cumbersome processes. Small firms, particularly fast-growing ones, suffered from the opposite — too little formality. We found that most firms, regardless of size, had a strong inclination toward adding processes to solve problems but only a weak tendency to ever look at whether these processes should be eliminated. Similar to growth in applications, growth in the number and complexity of processes can result in excessive bureaucracy. Forrester recommends: Large firms should periodically evaluate the inventory of internal processes and kill off or modify those that don&#8217;t provide sufficient value. Small firms need to anticipate the points when they&#8217;ll run into internal limits and selectively implement greater formality of processes. For all firms, internal processes shouldn&#8217;t be created by individual groups without some oversight, and the incentives should be more evenly balanced between adding versus reducing processes. PMO Leaders Fail Due To Lack Of Maturity And Undefined Scope For The Function The leader of the program management office (PMO) manages the functions of project management, methodology, and project oversight. In addition, we found that functions that didn&#8217;t fit anywhere else were commonly shoved into the PMO. Examples include portfolio analysis, process design, project initiation, and even vendor management. The symptoms of failure for the leader of PMO depended on which functions had been implemented. Most commonly, we saw that PMOs struggled in gaining conformance to their methodology, leveraging their expertise across the entire organization, bailing out projects in trouble, and efficiently tracking the progress of projects. The symptoms of failure of the leader of the PMO were the least consistent of all the functions we reviewed. As one CIO pointed out, &#8220;The PMO has failed in all possible ways.&#8221; There was tremendous variability and less maturity in the definition of the group&#8217;s scope, how the functions were to be implemented, how the group was to be measured, and even where the group should report. Not surprisingly, a high percentage of organizations were still unhappy with their PMO and had either given up on it or were trying different designs. The overarching reasons why PMOs failed stemmed from the difficulty of doing a broad range of functions adequately. Many of these functions, such as internal consulting or portfolio analysis didn&#8217;t have the lengthy trial-and-error history that the functions within apps or infrastructure had. A second major cause of PMO failure appeared to be that project management crowded everything else out. So what were the specific reasons why leaders of the PMO failed? And what are the most effective tactics for avoiding failure? Starting with the most frequent reasons for failure we found that they failed because they: Were buried by project execution. By far the most common problem was that the demand for project management crowded out everything else. An insurance company that also provided outsourcing services used its PMO for project tracking, methodology, and managing large projects. Because this group managed the outsourcing cutovers, they spent nearly all their time managing complex, high-visibility projects — and made little progress in areas such as project tracking, portfolio analysis, and methodology adoption. Forrester recommends: The PMO must have an organizational separation between project managers (PMs) who manage projects and those who provide project tracking, portfolio analysis, and oversight for the methodology. If those providing these non-project-management functions have to manage some projects, they need to set expectations and build time into the project plans to work on non-project responsibilities. Hadn&#8217;t clarified the role of PMs in the PMO. From assessments, we found that approximately 60% of PMOs included project execution in their scope. When this existed, there was confusion over when a PMO&#8217;s PM should be managing the project versus when a PM from another group should do so. At worst, this ambiguity made the PMO a convenient scapegoat for project failures. Forrester recommends: Typically PMs in the PMO were responsible for managing enterprise projects and consulting on others. Establish criteria that define what an enterprise project is and under what circumstances PMO PMs do not manage them. Furthermore, the PMO should define at what points in the methodology PMs from the PMO should consult with project teams on their projects and when they should pull back. Were unable to sell the methodology. In this case, the PMO attempted to enforce a near-religious adherence to its methodology. This resulted in the rest of the organization finding creative ways to bypass the PMO. For example, an asset management firm with a history of poor project execution implemented a comprehensive project management methodology. Though extensive pressure, training, consulting, and oversight were provided, practitioners saw little in it for them other than more paperwork and supervision. After two years, they had little to show for this effort other than a lot of paperwork. Forrester recommends: Use practitioners outside the PMO to collaborate in defining the methodology. Without this, the methodology will likely be both flawed and ignored. Furthermore, the implementation of the methodology should be done in pieces based on how much the organization can absorb. The initial pieces should focus on fixing the most immediate project management problems, typically project initiation, requirements definition, and deployment. Became homeless. This was a special case where the PMO reported outside of IT. This worked well when it was done to execute a companywide transformation project and had the attention and resources of the executive team. However, more commonly the executive that the PMO reported to had little knowledge (and often little interest) in the operation of the PMO and couldn&#8217;t provide adequate support for controversial decisions. A medical research company created a PMO reporting to the COO and run by a newly hired ex-consultant. The intention was to execute large, complex projects out of this group. However, the PMO came in conflict early on with the IT organization over the selection of systems, their design, project priorities, and the interface with the business. Making it worse, the leader of the PMO had poor support from other business leaders and only occasional support from the COO. Forrester recommends: Move the reporting of the PMO outside of IT only when it is leading a &#8220;change the business&#8221; project and has the attention of the executive team. In all other cases, the PMO should report within IT. However, regardless of where the PMO reports, business leaders should still own those projects that address a business problem. Used portfolio management tools poorly. The track record of PMOs or any other group using project portfolio management tools is weak. Often these tools are used as little more than electronic time sheets. However, during our assessments, IT leaders reported that the impact of misuse was relatively low, likely because their expectations of the tools were low as well. Forrester recommends: Don&#8217;t waste your time buying these tools if the organization is not committed to deploying them and providing training and support. Instead, focus first on developing key project portfolio management necessities such as standardized business case templates, an investment board, and project management skills and metrics. RECOMMENDATIONS OPERATIONAL IT LEADERS MUST BALANCE SHORT- AND LONG-TERM NEEDS The IT leaders analyzed in this report must balance their &#8220;day jobs&#8221; of building and maintaining systems with the need to fix underlying problems while planning for the future. Those CIOs that have been successful in running these functions: Select the right person. Choosing a leader with experience in balancing local versus global requirements, near-term problem solving versus long-term planning, and other potential organizational and process traps went a long way to avoiding failure. Furthermore, CIOs who are strongly biased to the strategic or tactical should ensure they have direct reports that balance out this bias. Develop incentives to motivate different goals and personalities. Many of the failures described in this report can be avoided by establishing the right incentives. However, people differ in their motivation. CIOs should know common motivators and their relative impact, as well as which specific factors motivate subgroups. Separate governance from execution. Several large IT shops are moving to plan-build-run or demand-supply organizational models. These models separate those functions that build and maintain systems from those that plan, and they have the advantage of enabling people to specialize in what they do best. Though many smaller IT organizations may not be able to afford the luxury of having an oversight function separate from execution functions, such specialization is necessary even for smaller shops to avoid failure and ensure separation of responsibilities. Build capacity to handle sudden changes in structure or scope of projects. The operational functions in this report are the ones dealing with most of the demands from end users. And the leaders of these groups are often pulled in multiple directions. Any major changes to the structure, scope, or measurements of these groups will require senior people with the extra time to design and implement those changes. Without this organizational slack, any attempt at significant change is largely a waste of time.]]></description>
		<wfw:commentRss>http://www.cioforum.be/be/2011/11/29/why-apps-infrastructure-and-pmo-roles-fail-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The CIO As Portfolio Strategist.</title>
		<link>http://www.cioforum.be/be/2011/11/29/the-cio-as-portfolio-strategist-2/</link>
		<comments>http://www.cioforum.be/be/2011/11/29/the-cio-as-portfolio-strategist-2/#comments</comments>
		<pubDate>Tue, 29 Nov 2011 14:54:03 +0000</pubDate>
		<dc:creator>dvanhove</dc:creator>
				<category><![CDATA[Value of IT & alignment]]></category>

		<guid isPermaLink="false">http://www.cioforum.be/be/?p=1696</guid>
		<description><![CDATA[As organizations undergo the transformation from information technology (IT) to business technology (BT), they will have to make many important decisions in the process of moving from the current &#8220;as-is state&#8221; to the &#8220;to-be state.&#8221; Complicating matters are two powerful and related trends: 1) rapidly emerging and disruptive technology paradigms such as cloud computing that are changing the economics of sourcing and empowered BT, and 2) tech-savvy business managers and staff provisioning their own technology solutions. A next-generation BT environment requires re-architecting and orchestrating the multiple technology portfolios including the service portfolio, applications portfolio, project portfolio, and asset portfolio. Successful transformation strategies will require a strong governance framework and a CIO capable of informing the decision-making in the role of portfolio strategist. TWO TRENDS COMPLICATE BT TRANSFORMATIONS IT organizations have faced mounting pressures to cut the cost of operations while at the same time influencing business outcomes by delivering new IT-enabled business change initiatives in ever-quickening cycle times. If these challenges weren&#8217;t enough, two major and related trends are further complicating the CIO&#8217;s efforts. Disruptive Technologies Change The Economics Of BT Provisioning The costs of providing IT-enabled business solutions have fallen significantly as a result of emerging technologies that have led to new paradigms for sourcing IT-enabled business change initiatives. The ability to use these disruptive technologies to reduce costs, increase business benefits, and speed time-to-value increases the number of potential initiatives under consideration at forward-looking organizations. These new technologies include: Cloud computing. Cloud computing, a form of standardized IT-based capability, is potentially the greatest disruptive change. The ability to incorporate Internet-based services, software, or IT infrastructure from an external service provider accessible via Internet protocols from any computer can reduce costs, simultaneously increase flexibility, and reduce the time to provision solutions. Virtualization. Virtual servers, disks, or firewalls that exist only in software can be created at the click of a button. Applications that use them can&#8217;t tell the difference between the physical and the virtual because they provide all the same services and respond just like the real thing. IT organizations can use virtualization to reduce IT operating costs while at the same time providing higher levels of availability and reduced provisioning times. Hosted solutions or software-as-a-service (SaaS). We estimate that in 2010, 7% of all software spending (including license revenues, maintenance revenues, subscriptions revenues, and software-vendor-provided training, support, and implementation services) came from subscription-priced SaaS products. By 2013, we estimate that SaaS will represent 13% to 14% of all software spending, more than doubling the market share in just three years. A SaaS approach enables organizations to deploy solutions much faster and at a lower cost than traditional methods. Mobile platforms. The rapid development and adoption of mobile platforms has created the expectation of information and applications available anywhere and anytime. Currently, mobile is mainly seen as a way to increase customer engagement, satisfaction, and loyalty. For IT, the challenge lies in the proliferation of diverse mobile devices including smartphones and tablets and their software environments including Apple&#8217;s iOS, Google&#8217;s Android, RIM&#8217;s BlackBerry, and Windows Phone 7 to name a few. Empowered BT Upsets The Traditional Governance Model These disruptive technologies that are increasingly easy to acquire and use are fueling the second trend: empowering business self-sufficiency. Tech-savvy business managers and staff will provision their own technology solutions, potentially cutting traditional IT out of the equation. Business self-provisioning marginalizes IT. The relationship between IT and the business in most firms is a reactive one, where the business scopes the change and IT determines whether that change is feasible. When the changes the business demands don&#8217;t fit with current solutions, IT becomes the department of &#8220;no,&#8221; and the business goes shopping elsewhere for its technology needs, creating pockets of &#8220;shadow IT.&#8221; The disruptive technologies described above will accelerate this process by making it faster and cheaper. The focus of technology innovation has shifted. People outside of IT — often in marketing, sales, and customer service — are innovating with new technology solutions to reach out to customers. More than half of US employees say they have better technology at home than at work, and 37% of US information workers are solving customer and business problems using technology that they master first at home and then bring to work. IT organizations must make two key governance decisions when considering where to invest time, people, and money in current and new IT systems and services: 1) where to source future solutions, and 2) who will lead the acquisition and deployment of the new systems and services. GOOD IT GOVERNANCE IS A REQUIRED COMPETENCY At its simplest, IT governance is about the decision rights around IT investments. It includes the structures, processes, and communications that describe who makes IT investment decisions, how those decisions are made, how the outcomes of those decisions are measured and communicated to stakeholders, and who is held accountable for those decisions. The challenge for organizations is that empowered BT requires a mature and robust governance framework that is integrated with enterprise governance and driven by the executive and business leadership. Furthermore, this governance framework must balance the need to ensure that decisions maximize value, are compliant with the enterprise architecture, and fall within risk guidelines without becoming a barrier to flexibility and speed. Unfortunately, in many organizations today, IT governance remains immature, fragmented, and still driven primarily within IT. Explicit Decision Frameworks Are Necessary In order to avoid anarchy and chaos, IT decision rights must be explicitly communicated and enforced to clearly identify who is responsible and accountable for the decisions and who has input into those decisions. An effective way to accomplish this is to create an IT decision rights matrix. This matrix was first introduced in research published by the Center for Information Systems Research at MIT. It describes five key IT governance decision domains — IT principles, IT architecture, IT infrastructure, business applications, and prioritization and investment — and the possible decision archetypes for making the decisions. Clearly articulating these decision rights removes any ambiguity and ensures that IT decisions will be aligned with the business strategy and optimized to return the most value while managing risk. The first step in maturing IT governance for BT should be the development of an IT decision rights matrix for the enterprise. For empowered BT organizations, complexity is managed through the governance decision domains: The IT principles domain provides the overall context. The business strategy ultimately dictates the role that IT plays — for example, whether IT is primarily a back-office support function or an enabler of innovation; whether IT will be centralized, decentralized, or some other structure; and what degree of standardization of processes and data is required. The architecture domain defines the ground rules. Empowered BT requires next-generation enterprise architecture to develop business capability maps, target architectures, planning scenarios, and road maps. This enables the organization to define a set of standardized business processes and services that the business can leverage. EA can support agility and fast response times by describing existing standard capabilities and processes that can be immediately leveraged through reuse while at the same time maintaining flexibility in the instances where existing architecture elements are insufficient. To ensure that EA is not circumvented, its involvement is made explicit at all levels in the organization. The infrastructure domain addresses sourcing. With infrastructure accounting for more than half of all IT spend for a typical organization and forming the core of IT capabilities, it is important to get it right. The new, disruptive technologies have increased the complexity of infrastructure decisions. Will infrastructure be in-sourced or outsourced or both; will infrastructure be built on external clouds, internal clouds, or some hybrid; and how much infrastructure will be shared across the enterprise versus serving a single business unit? Making the transformation from a legacy infrastructure to an empowered BT infrastructure will represent a significant opportunity to have a favorable impact on IT&#8217;s cost structure, time-to-market (cycle times), and value proposition, but it will also incur huge risks. The business applications domain determines value. Ultimately, the value from IT-enabled business change investments is realized through the business applications, since this is where the linkage to business outcomes occurs and where organizations can differentiate themselves from their competitors. Making decisions about business applications involves a tradeoff between innovation and discipline. Innovation is about creating applications that support strategic business objectives and increase customer value, while discipline is about maintaining architectural integrity and conforming to technology standards and road maps. For empowered BT, this is where provisioning decisions are made. By making the correct decisions about IT principles, architecture, and infrastructure, empowered BT organizations can enable increased levels of business self-provisioning resulting in accelerated time-to-market. THE CIO AS PORTFOLIO STRATEGIST Investment management firms, those that invest money on behalf of their clients, typically employ a portfolio strategist. The role of the portfolio strategist is to develop an overall investment strategy that optimizes the balance between return and risk based on current and expected future conditions. This requires a global and holistic perspective based upon an understanding of the current economic environment and forecasts, the expected direction of interest rates, the global political landscape, industry fundamentals, and commodity pricing trends, among other things. Armed with this knowledge, the portfolio strategist can make recommendations among a number of different portfolios including equities (stock of publicly traded companies), fixed income (government and corporate bonds), commodities, indexes, etc. and the recommended weightings in each portfolio. A Holistic View Is Required To Guide Decisions . . . Empowered BT requires the CIO to assume the portfolio strategist role for the BT portfolio. The CIO — with a complete understanding of the business strategy, operating model, and a global view across all of the business units, functions, and geographies — is in the best position to gain the holistic view across all of the BT subportfolios. This holistic perspective will enable the CIO to provide critical input in the form of recommendations to the key IT governance decisions that are required, including: Relative weightings of the portfolios. A holistic view of the portfolio enables optimization of the entire IT spend and ensures that the maximum value is obtained at an acceptable level of risk. Tradeoffs can be made between investing in running the business, growing the business, or developing new services to change the business. Sourcing strategies around services. Cloud computing creates opportunities to externally source infrastructure, platforms, and/or applications with the potential to significantly reduce cycle times and cost, enabling flexibility to scale up or down in response to changes in demand and to convert capital expense to operating expense. The sourcing strategies can be employed with both existing and new services. The CIO is in the best position to understand when, where, and what can or should be outsourced to the public cloud versus a private cloud or even a more traditional in-sourced approach. Provisioning strategies. The combination of growing technology savvy on the part of the business and the disruptive technologies cited earlier creates opportunities for the business to self-provision some IT-enabled business services. As long as enterprise architecture has been documented and infrastructure standards and road maps implemented and a compliance process exists as part of overall governance, enabling the business to self-provision solutions can lead to competitive advantage. The key is to understand where it makes sense and where it doesn&#8217;t and to provide the business with guidelines. Standardization versus customization. Standardized business processes and common data definitions promote operational efficiencies that can reduce costs and speed time-to-market; however, at the same time, they can inhibit new opportunities by preventing flexibility or be mis-aligned with local practices. The CIO with a global perspective can provide guidance and recommendations on how to balance these conflicting approaches. Going forward, CIOs have a choice to make. They can facilitate their organization&#8217;s transformation to BT and assume the role of portfolio strategist, or they can remain focused on the technology and keep responsibility for a decreasing technology portfolio because the drivers of transformation will not wait. . . . But An Integrated View Across Portfolios Is Missing The transformation to empowered BT requires making a number of critical BT governance decisions as discussed above. Making good decisions means making informed decisions (i.e., decisions that are based on the best possible information). The irony, however, is that when it comes to information about information technology, many organizations are lacking. Outside of IT budget data and some operational data, there isn&#8217;t much else. Even more mature organizations that have invested in IT management processes and tools often maintain the information in multiple silos and portfolios. The infrastructure and operations manager may have visibility into the infrastructure assets through an asset portfolio, the applications maintenance manager may have visibility into legacy applications through the applications portfolio, and the head of the program management office (PMO) may have visibility into new investments through the project portfolio, but no one has the big picture. All of the information resides in silos. Holistic portfolio management is a journey led by the CIO. It begins by acquiring knowledge of the entire IT environment through discovery and inventorying all of the assets, applications, and projects. For many organizations, this will require investment in IT management tools. But the tools are only as good as the information being entered, which requires behavioral changes on the part of IT staffers. Holistic portfolio management is a major organizational change effort, but it is required if IT organizations are going to successfully make the BT transformation. RECOMMENDATIONS GET STARTED ON A TRANSFORMATION PLAN NOW The disruptive technologies are already here and maturing rapidly, and empowered computing initiatives are well under way in some organizations. CIOs need to be proactive in developing their transformation plans before it&#8217;s too late and organic initiatives begin to sprout across the organization, leading to reactive, disjointed, and suboptimized results. Assess your maturity. The first step in a transformation plan is assessing your maturity in a number of key areas including IT governance, IT strategic planning, and IT portfolio management. Use the results of these assessments to identify areas to improve. Forrester has developed a framework and tools to assist organizations in assessing their BT maturity. Implement tools. Obtaining a holistic view of the BT portfolio requires the ability to see across all of the subportfolios and perform &#8220;what-if&#8221; analysis across a range of scenarios. While good portfolio management processes are a prerequisite, providing capabilities to aggregate portfolios, perform analysis, and create and communicate reports exceeds the capabilities of Excel and requires an investment in a portfolio management tool. Start the conversation. Begin to engage executive management and business leadership to raise awareness of the need for a strong governance framework on which to &#8220;hang&#8221; empowered BT. Be proactive and use the governance decision matrix as a tool to drive the discussions with an aim toward reaching consensus on the key decision rights based on the five key governance decision domains. Monitor and improve. Optimizing the BT portfolio requires a high level of maturity that can be gained only through a continuous process of monitoring and improving. Begin by indentifying key performance indicators (KPIs) that will be used to measure performance and setting targets to drive that performance higher. Create feedback loops to ensure that lessons learned along the way are incorporated into improving the processes.]]></description>
		<wfw:commentRss>http://www.cioforum.be/be/2011/11/29/the-cio-as-portfolio-strategist-2/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
		<item>
		<title>The IT Balanced Scorecard: Customer/Partner Metrics Revisited.</title>
		<link>http://www.cioforum.be/be/2011/11/29/the-it-balanced-scorecard-customerpartner-metrics-revisited/</link>
		<comments>http://www.cioforum.be/be/2011/11/29/the-it-balanced-scorecard-customerpartner-metrics-revisited/#comments</comments>
		<pubDate>Tue, 29 Nov 2011 14:45:19 +0000</pubDate>
		<dc:creator>dvanhove</dc:creator>
				<category><![CDATA[IT Strategy & Planning]]></category>

		<guid isPermaLink="false">http://www.cioforum.be/be/?p=1694</guid>
		<description><![CDATA[In the Balanced Scorecard framework, IT value is driven by satisfied customers. For many IT organizations, satisfying customers has become more challenging as the definition of an IT customer has grown to include many different constituencies both inside and outside the firm. At the same time, satisfying customers has become crucial because few IT organizations retain their monopoly status in light of the increasing competition from outsourcers, systems integrators, hosted solutions, and other external providers, platforms, and solutions (i.e., the cloud). Originally called the &#8220;user&#8221; perspective, in revisiting the subject, we have changed the name to &#8220;customer/partner&#8221; to more accurately reflect the expanded marketplace that IT organizations serve. When developing customer/partner metrics, IT needs to push beyond the usual internal customer satisfaction survey. Additional service delivery, applications delivery, IT/business partnership, and external customer satisfaction metrics should be developed as leading indicators of performance. THE IT ECOSYSTEM GROWS MORE COMPLEX IT organizations once served mainly internal users, but today they operate in a technology ecosystem that has grown increasingly complex and challenging, primarily as a result of two significant trends. These trends have forced IT organizations to expand their approach to developing metrics for the customer/partner perspective of the IT Balanced Scorecard. Most IT organizations are no longer monopolies. Not that long ago IT organizations were monopolies providing information technology solutions to a narrow constituency comprised of internal users. Over the years, that monopoly status came under competitive pressure as external service providers went directly to executive management claiming to offer superior service at lower cost. Initially limited primarily to outsourcing technology infrastructure, today&#8217;s portfolio of externally provided products and services includes everything from point solutions hosted by managed service providers to complete business process outsourcing. The definition of an IT customer has expanded. At the same time the supplier landscape was expanding, so too was the concept of an IT customer. This process accelerated with the advent of the Internet and the Web, which resulted in the development of external customer-facing solutions like eBusiness and is now at the beginning of yet another phase with Web 2.0 and the era of empowerment. Furthermore, some organizations take offense at the term &#8220;IT customer&#8221; to describe the IT/business relationship, preferring instead to be called partners to emphasize the shared responsibility and accountability required to deliver value from today&#8217;s IT-enabled business change investments. Changing IT Requires Changing The Balanced Scorecard Metrics The original user perspective focused exclusively on the internal IT customer or user and ignored the growing constituency of external customers, an approach that is no longer viable for most organizations. Outages of external customer-facing systems not only have loss-of-revenue implications but can also lead to reputational damage and brand devaluation. Sometimes, just making changes to the user interface can have far-reaching implications and weaken satisfaction. The new IT Balanced Scorecard must include external customers. Additionally, the original scorecard metrics were developed from the perspective of IT as a monopoly involved in implementing all technology-related solutions. The reality of today&#8217;s alternative sourcing options puts new demands on IT organizations around account and relationship management. CUSTOMER SATISFACTION RESULTS FROM DELIVERING ON THE VALUE PROPOSITION Satisfied customers result from the delivery of a value proposition — that is, something unique or better than they can get from someone else, where better can be defined in many ways, including attributes like lower costs, higher quality, deeper relationships, or improved reputation. According to the Balanced Scorecard founders Robert Kaplan and David Norton, as IT organizations mature, they progress along a continuum that starts with competency, moves to credibility, and ends with contribution: Competency is about fundamentals. IT customers have some basic expectations around service availability and reliability, service costs, and responsiveness to help desk requests. When IT organizations implement ITIL processes and define and deliver service-level agreements (SLAs), they are demonstrating basic competence. Credibility is about execution. As IT organizations establish their operational competency, they build on this by delivering projects that meet customer needs and are completed on time, on budget, and at a high level of quality. When they do this on a consistent basis, they build credibility. Contribution is about partnering. With competency and credibility established, IT organizations are in a position to move to the third stage, contribution. At this stage, IT becomes a strategic partner with the business and moves beyond merely supporting the business to actually helping to innovate new products, services, and/or business processes alongside the business. However, being a contributor IT organization comes by invitation; it is not something that IT can do on its own. CUSTOMER/PARTNER METRICS FALL INTO FIVE CATEGORIES When developing customer/partner perspective metrics for the IT Balanced Scorecard, the effort must go beyond just periodically measuring customer satisfaction, which is a lagging indicator (or outcome measure), and also include metrics that provide some leading measures (performance drivers) as well. In addition to measuring the satisfaction of both internal and external customers, the scorecard requires metrics to measure service delivery performance, applications delivery performance, and IT&#8217;s relationship with its customers/partners. Surveys Measure Internal Customer Satisfaction Customer satisfaction surveys can be an important method for assessing customer satisfaction, provided that they are thoughtfully constructed and administered. Forrester recommends conducting regular customer satisfaction surveys, preferably utilizing an objective third party. This will ensure that the survey captures relevant data and answers are more forthcoming since anonymity can be preserved by the third party. Supplement surveys with qualitative data by conducting regular interviews with key business leaders and facilitating periodic focus groups to both gauge customer satisfaction and obtain input into how things could be improved. Merely asking questions does not improve customer satisfaction; improvement comes from truly listening to customers&#8217; feedback and assuring them that their opinions count and will be acted upon. Suggested metric: internal customer satisfaction survey score. A well-constructed customer satisfaction survey can provide solid quantitative data to measure overall customer satisfaction as well as gain an understanding of areas for improvement. Surveys Also Measure External Customer Satisfaction Just about every organization today delivers some IT-based products and services directly to external customers. This includes government agencies with eGovernment initiatives like the New Jersey Motor Vehicle Commission&#8217;s online automobile registration renewal, academic institutions like Phoenix University providing online degrees, and banks providing online bill paying. For some firms, like Amazon.com, the entire business model is based online. The advent of Web 2.0 and the proliferation of mobile devices add yet more customers and more complexity. It&#8217;s not unusual for an IT department today to have more external customers than internal customers, customers who are utilizing their systems 24 hours a day, seven days a week, all over the world. When internal customers are dissatisfied, they may grumble and complain and they may eventually look outside for services but that is the extent of the damage. When external customers become dissatisfied because they can&#8217;t access your website to pay bills or order a product, it can damage the company&#8217;s reputation, especially if they use social networking tools to vent their frustration. Suggested metric: external customer satisfaction survey score. Organizations should regularly survey external customers about their user experience with the firm&#8217;s customer-facing systems and utilize external data from third-party web monitoring providers. Service Delivery Measures Competency As IT organizations compete for their customers&#8217; business, they are themselves transforming from &#8220;stewards of technology&#8221; to internal service providers by adopting ITIL processes, implementing IT service management, and developing service catalogs to describe the portfolio of services they provide. For each of the services IT provides, it should negotiate with the customer to establish an SLA that defines the expected performance of the service. IT can then measure service delivery performance in terms of meeting those SLAs. Suggested metric: SLA performance. By rolling up the actual performance of all of the individual SLAs compared to their targets, you arrive at the percent of SLAs that meet or exceed their expected target. However, this would treat all services as equal, which is typically not the case. For example, an outage of a mission-critical service is not the same as missing the delivery date for a printer. Organizations may wish to use a weighted number based on importance, restrict the metric to only key services, or develop several tiers of services based on their criticality to the business. Project Execution Measures Credibility Since IT exists to serve the business, a fundamental measure of customer satisfaction would be derived from its ability to execute projects and deliver applications that meet the needs of the business and deliver value. A measure for applications delivery performance should be incorporated. Project execution performance can be measured across four dimensions: project quality, project schedule, project budget, and project scope. It follows, then, that application development projects that deliver their full scope, on schedule and budget, and meet quality expectations should equate to high levels of customer satisfaction. Suggested metric: healthy project index. The simplest index can be constructed by averaging together the performance of each of the four dimensions. For example: The healthy project index equals the average of the percent of projects delivered at full scope (based on an end-of-project survey, the percent of projects delivered on time (based on the negotiated project schedule), the percent of project delivered to budget (based on the negotiated project budget), and the percent of projects meeting quality expectations (based on defects or change requests within the first 90 days). IT/Business Partnership Measures Contribution Another measure of customer satisfaction with IT concerns the level of partnership between IT and the business units. Does IT function purely as a support organization or order taker, executing projects to support a business unit, or is IT really an integral partner with the business and involved in joint strategy planning? Do projects have shared accountability, or is IT alone to succeed or fail by itself? An IT organization that is competent and credible is more likely to be invited to become a partner, although this is also a function of the industry and strategy. There are a number of metrics that can be used within the IT Balanced Scorecard to measure the degree of IT/business-unit partnership. These include: Suggested metric: existence of dedicated relationship managers. Does each business and functional unit have a designated and dedicated relationship manager? Is the relationship manager actively engaged at the senior management level? Does the relationship manager participate in the strategic planning process? Suggested metric: percent of programs with joint accountability. Does each program have a representative from both IT and the business unit sponsoring the program as part of the team? Do they equally share accountability for the success or failure? Suggested metric: percent of programs reviewed by a steering committee. Good IT governance requires a steering committee to evaluate and approve business cases for new investments and to review and prioritize existing investments. Does a steering committee exist, is it comprised of the business leadership, and is it active in investment management? RECOMMENDATIONS CIOS MUST ACTIVELY PROMOTE CUSTOMER SATISFACTION Customer satisfaction is a litmus test for value from IT, especially in today&#8217;s competitive environment, because unhappy customers will soon take their business elsewhere. Customer satisfaction is essentially a daily plebiscite on the CIO&#8217;s performance, yet many CIOs (and IT organizations) fail to measure it regularly. As part of the IT Balanced Scorecard, CIOs should: Regularly solicit feedback from internal and external customers. Quarterly surveys of both internal and external customer satisfaction should be supplemented with monthly management interviews and user focus groups to provide a steady and current picture of satisfaction with IT. Employ a mix of leading and lagging metrics. Surveys, interviews, and focus group results are outcome measures that tell you how you did; these need to be augmented by leading indicators to help identify potential problems before it&#8217;s too late. SLA performance and project execution metrics can be good leading indicators. Make the metrics actionable. Each metric in the scorecard needs to have a senior IT executive named as the owner, making that person accountable for the performance. When performance falls short of the target, the owner is responsible for determining the root cause and developing an action plan to get back on target. Close the loop. Too many times organizations conduct surveys and solicit feedback from customers and that&#8217;s the end of it. If you expect your customers to take the time and effort to fill out a survey, be interviewed, and/or participate in a focus group, they deserve to hear the results and the plan to address any issues or problems that are uncovered. Failure to close the loop will quickly lead to steep decline in participation and most likely a drop in customer satisfaction.]]></description>
		<wfw:commentRss>http://www.cioforum.be/be/2011/11/29/the-it-balanced-scorecard-customerpartner-metrics-revisited/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>

