The Evolution of IT Governance

Friday, February 22, 2019

Business-IT Strategies

Vol. 14, No. 2


Business Technology


The Evolution of IT Governance

by Rachel Mendelovich

In the past few years, the managerial area of demand management, portfolio

management, and IT governance have become more and more popular.

Organizations are adopting these processes to better manage their expenses,

reduce cost, and formalize an often chaotic relationship between IT and the

business. This Executive Report suggests an approach, based on business

technology management, to manage this relationship effectively. Mastering the

relationship between IT and the business is crucial for organizational success.



Business Technology Management:

The Evolution of IT Governance




Rachel Mendelovich


  1. What and Who Exactly Is  "the Business"?


  1. So What Does IT Think  About the Business?


2  And How Does the Business Feel About IT?


3 . So What Is IT Governance and What Is Project Portfolio Management?


6.  How Can the CIO Lose By Implementing IT Governance?


6 . How Can the Business Lose By Implementing IT Governance?


7  Is IT Governance Really a Lose-Lose Situation?


8  Enter Business Technology Management


13   Summary


13   Endnotes


13   About the Author


Lately, the voices calling for the CIO to be "closer to the business," "understand the business" and "provide the business with value-added services" are becoming increasingly louder. The future, they say, belongs to the CIO who will be smart enough to navigate between technology constraints and business needs. This "new era" CIO should be first and foremost a businessperson. No longer do we expect the CIO to be only a technology-oriented, infrastructure expert, or even a brilliant manager. Today, it's all about understanding business processes and being able to respond to them. CIOs must convert IT into a true revenue generator and influence the way the organization realizes its strategy.

However, the challenge of being able to do so does not - unfortunately for the business units (BUs) - lay on the CIO's doorstep alone. The ability to harness technology against the ever-changing business needs is a joint responsibility, involving both IT and the business. While IT should indeed have a full grasp of the organization's strategy, needs, processes, and limitations, the business should be deeply involved in the investment choices made by IT and ensure those investments collaborate with organizational goals. Unfortunately, in today's typical business environment, it seems that neither IT nor the business really has an incentive to jump head first into each other's world.

But before we dive into that challenge, lets first define "the business."




It is common to think of the business as one big entity with defined goals, needs, processes, and practices led by one CEO who outlines the strategy to be heeded by all. Well, an organization's life is hardly ever that simple. The fact of the matter is that the business consists of many people and many opinions (sometimes more opinions than people) as well as various agendas, needs, fears, and, of course, organizational politics. These elements combine into what we often like to call "the culture" of the organization. This culture can be thought of as the playground in the business technology game. It sets the basic rules, the choice of weapon, and the tactic to be selected. But, if the culture is the playground, then who, aside from IT, are the player?

The answer that jumps to mind is naturally senior management. After all, senior management consists of the CEO, CFO, CTO, and a whole bunch of CxOs. Win their approval, and you can claim victory - yet still be dead wrong. Whatever process you're trying to implement, it is important to ensure that you have support from senior management; however, focusing attention solely on these players would prove to be a grave mistake. Decision making, in general, and IT-related decision making, in particular, are made among various levels of management. Therefore, midlevel management along with senior management are all players, and each should be recognized and well understood.


IT is overwhelmed with numerous changes and

frequent demands by the business, often coming

by way of a flood, with the business requesting a

"this minute" solution to an entirely new need.


Now that we have accounted for all the interorganization players, let's examine the outer ones. All organizations are subject to external influences. Be that the board of directors, investors, suppliers, or an elusive entity called "the market" (aka Michael Porter's Five Forces1). All of these are part of the business and can play a vital role. More often than not, these outer forces influence choices made by the business, directly influencing IT as a result. For example, let's say a new competitor has joined the arena and has created a "blue ocean"2 in order to survive and be relevant. Consequently, an existing organization may need to make some drastic changes to its own strategy to remain competitive. Those changes will affect everyone and everything in the company, including information systems and the processes they automate.


"Frantic," "indecisive," "technology-disabled," "fantasy-driven," "doesn't know what it wants" - these are only some of the statements provided by IT people when asked to describe their customers (i.e., BUs). And this is hardly a surprise. In general, IT processes are characterized by long durations and time-consuming efforts. Once assigned to a task, the IT project manager (PM) is first asked to "understand the need" (aka requirements management). Only when the PM feels the requirements have been fully defined will he or she move to the next phase, drafting the functional design (i.e., high-level design) and technical design (i.e., low-level design). Just completing these two documents requires the PM to pull together a whole bunch of people and listen to their perspectives. This can include GUI designers, security specialists, architecture designers, development teams, QA teams, the CTO, database administrators, and systems administrators. Of course, the more involved, the longer (and more frustrating) the task becomes. Add to that the need to comply with bureaucratic standards (e.g., ISO, ITIL, COBIT, CMMI) as well as imposed technology (due to consolidation considerations), and you wind up with a long, tiresome task with a low success rate.


By the time the PM concludes with the designs, months may have passed, and the business needs - which rarely sit and wait - have likely changed, resulting in a tired, frustrated PM. But even if the changes are minor and the coding phase is able to commence, by the time IT is ready to deliver the system to the business, the system may no longer be relevant and either massive changes are required or the system will die quietly, leaving IT personnel worn out and confused and the business needs unfulfilled.


While the above description may sound a bit overdramatic, one needs only to look at project failure statistics, particularly IT projects rates, to see that there is merit to this claim. There are many ways IT has tried (and continues to try) to cope with what it deems a "violation of the initial agreement" between the business (represented by referents) and its own people. Business referents are kindly asked to sign the requirements document with the hope that they will not change their minds later, while a business PM is assigned to collaborate with the IT PM in the hopes that this joint effort will bring about less surprise. Furthermore, efforts are underway to define methodologies for change management, and lean/agile methods are being adopted to embrace change. But despite this growing trend, IT is still overwhelmed with numerous changes and frequent demands by the business, often coming by way of a flood, with the business requesting a "this minute" solution to an entirely new need.



So now we have a snapshot of the requirements IT is trying to meet. But for every requirement IT deals with, there are myriad others it simply can't. Due to limited budget and resources, the CIO will likely choose to neglect those requirements that he or she feels are either too risky, too expensive, or simply not worth it. So while those BUs are lucky enough to have IT agreeing to meet their needs, they are often left dissatisfied due to long duration and/or a partial solution, while the rest are forced to look elsewhere entirely for solutions and left to believe that IT is merely a black hole sucking the money from the organization and providing nothing solid in return.

One might claim that with BUs being labeled "customers," low satisfaction is merely expected. Nowadays, customers, in nearly all areas of life, expect an instantaneous response time, high quality, cheap solutions, and zero tolerance to breaches. Attempts to moderate these expectations in the form of service-level agreements (SLAs) have helped over the years but have not provided the desired effect. More often than not, IT is still perceived as inefficient, separate from business, and self-nurturing.

In any case, having the CIO choose which initiatives to respond to and which to neglect - for valid reasons or not - is a source of countless complaints, escalations, and dissatisfaction. The most frequent claim is that IT simply doesn't have the tools to judge which initiatives are truly business imperative and which are merely whims. Therefore, any decision made by the CIO rarely stands a chance for approval. To complicate things, recall the playground scenario described earlier. For instance, consider two managers of the same seniority applying for a desired role (one involving a promotion). Both are trying their hardest to display results and achievements. Let's assume one manager's IT initiative is being addressed, while the other is being neglected. It's not hard to predict the battle zone that will emerge, including claims that the CIO is politically motivated or infected.


In this scenario, one would expect the CEO (or someone from senior management) to pick up this "hot potato" and decide which initiative to pursue and which to leave be. And there are certainly cases in which the decision-making process is done this way, mostly for highly expensive and cross-organizational initiatives such as enterprise resource planning (ERP) and customer relationship management (CRM), but those are usually initiated by IT to begin with. However, senior

management simply can't vote for every single demand -nor should it. A mechanism allowing for decision making should be put in place, and we call this project portfolio management (PPM), which is a vital part of what is known as IT governance.



IT governance is defined as a discipline, originally from regulation compliance needs, intended to monitor and govern IT performance and risk management; that is, every service provided by IT must be monitored and measured, and its achievements must be transparent to all stakeholders.

However, a substantial part of this discipline is devoted to ensuring that the use of IT resources is allocated toward the best interest of business stakeholders and that any decision making regarding the use of IT resources is effective. All parties under this doctrine are accountable to investment decisions; nobody can make independent decisions without responsibility attached to them. This process is known as project portfolio management. The term "portfolio" is used in the economic domain to describe various securities (e.g., shares and bonds) and assets (e.g., real estate) meant to meet specific investments goals.

PPM in the IT arena is a relatively new concept, borrowed from the economic world, describing the various investments made by IT (both capital and labor) to achieve business goals. In other words, PPM is meant to bridge the two worlds of IT and the business by creating a common understanding and language regarding business goals on the one handand IT constraints on the other, thus formalizing an interaction between the two in order to achieve various goals under given constraints.

The PPM process goes through four major stages

(see Figure 1):

Define and


Business Drivers



and Cost

Define Alignment

of Initiatives with

Business Drivers


Figure 1 - Four stages of project portfolio management (PPM).




1. Define and prioritize business drivers.

2. Recognize initiatives and cost.

3. Define alignment of initiatives with business drivers.

4. Prioritize.

Define and Prioritize Business Drivers

The first step to create a solid portfolio must be the clear and measurable definition of business drivers. Business drivers are the building blocks of strategy. They reflect the goals and accomplishments the organization is after. These drivers define the desired future and point out the direction the company will follow.


Business drivers are the building blocks of

strategy. They reflect the goals and accomplishments

the organization is after.


A good business driver will be defined as a reflection of the goals the organization would like to accomplish. These drivers will be achievable, measurable, and valid for at least a year. Any individual (be that an employee, a customer, or vendor) looking at these drivers will have a full understanding of the future state the firm is aspiring to be in. A bad business driver will be vague and will not have any operational aspects that are required in order to be able to realize or even measure it. In other words, a business driver should be SMART:



Simple - should be focused and clear.

Measurable - should be able to state whether it has been met, and by how much.

Achievable - should be relevant.

Result-oriented - should provoke actions and achievements.

Time-bound - should be realistically achievable within a given time frame, known to all involved parties.

In most organizations, high-level business drivers are vastly defined. Drilling down to different departments can reveal how high-level goals are not being broken down to local, department-oriented goals. Let's look at an organization defining its major goal as "increase profit by 20%." This goal can be translated in different divisions in different ways; for example:.

Marketing - penetrate the Asia and Pacific market, which holds huge market potential.

Sales - increase sales by 20% in Europe, Middle East, and Africa.

Operations - reduce operational cost by 20%.

HR - reduce HR cost by 20%.


IT governance (and PPM) requires divisional drivers to be as clear, and as measurable, as organizational drivers, if not more. Divisional drivers will allow for an understanding of whether or not an initiative is aligned to business goals and thus allow drivers to be prioritized accordingly. Once defined, business drivers should be prioritized so that the end result, for each division, is a set of drivers listed from most important to least. The method by which the drivers are to be prioritized is less important (there are many) as long as the method is commonly used by all divisions. In some cases, this method is integrated into the PPM tool (PPM enables prioritizing drivers through pair comparison); other times, it is a matter of subjective decision making made by the head of the division. All methods are acceptable as long as they are commonly used by all.


Note: There are many organizations in which the business drivers are hierarchal, meaning a BU inherits the higher unit's drivers and then adds up its local drivers. In these cases, initiatives will need to align with both the higher BU's business drivers as well as the local ones.


Recognize Initiatives and Cost

Initiative is merely any requirement made to IT that calls for resources being invested to reach realization. Initiatives vary from the smallest change request to the most complex system. To cope with such a large spectrum, there's a need to define what is "under the radar." For example, one may define that initiatives below US $50,000in cost and/or two months' development in duration will be considered a change request (not even an initiative) and these types of change requests could be added up into one initiative called "CR Repository" with one "price" tag. Same goes with defects or small initiatives such as business performance management (BPM) capabilities or team sites. The price tag for each initiative should hold both capital expenses (e.g., consultation, hardware, software) and labor (e.g., person-months) deferred by skill sets (e.g., QA, R&D, training).



In some organizations, the process of recognizing initiatives also promotes the recognition of risks, constraints, dependencies, and other metadata that can later be used to define priorities. In this stage, it is important to differentiate between capital expenses (CAPEX) and operational expenses (OPEX). While OPEX is a forced-in expense required to "keep the lights on," CAPEX are true investments that will be prioritized against business drivers.


Define Alignment of Initiatives with Business Drivers

OK, so now we have the well-defined, prioritized business drivers and all the initiatives outlined, along with their cost. At this stage, we can start defining alignment of each initiative with the business drivers. Again, there are many ways to define alignment. One effective methods is by "confronting" each initiative with every driver. In this method, the business representative (preferably a senior executive) of each division is asked to grade alignment per driver for each initiative (see Figure 2)

In the example in Figure 2, the HR division has five initiatives. Each is confronted against each of the four drivers of the HR division. The result is a decision regarding whether the initiative aligns with the driver at the levels of (1) extreme, (2) significant, (3) medium, ((4low, or (5) none. The next step would be to translate the description of alignment into a numerical value that is easier to deal with when prioritizing. One may choose any method for translating alignment into a numerical value. Most PPM tools will provide this functionality, but it is fairly easy even with Excel. (Note: Figure 2 also shows values of cost and labor) .


Once the first three PPM stages are performed per division, the PPM process owner will have a reasonable understanding of the cost-benefit ratio for each initiative and will thus be able to demonstrate the most beneficial initiatives, given a certain budget, per each division. Benefit Let's return to our HR example from the previous section to examine the cost-benefit ratio (see Figure 3). Figure 3 - Sample cost-benefit ratio.

Section D in Figure 3 represents the section holding the initiatives with the most positive cost-benefit ratio, while sections C and A represent the initiatives with the worst cost-benefit ratio. In this example, the HR division will do well to invest its IT budget in initiatives 1, 2,and 3, which promise the greatest value per dollar, and neglect investing money in the expensive initiative 4,which promises medium-to-low added value. The decision of how many initiatives to bring forth to realization depends, of course, on budget constraints. Many PPM tools today, such as Microsoft PPM and CA Clarity PPM, provide solid what-if solutions to facilitate decision making.




So Why Doesn't IT Governance Work?

Well, all this seems easy enough and makes sense. Both IT and the business profit from a logical process that enables logical decisions. No longer does IT have to tolerate the capricious business, nor does business have to tolerate the arrogant IT. So it would be fair to assume that IT governance, in general, and the PPM process, in particular, have spread around and are now implemented in all organizations, at least small to medium-sized businesses, right? Wrong!


Initiative Drivers Cost (Capital) Labor (Person-Month)

Driver A Driver B Driver C Driver D Hardware Software Consultant R&D QA Training

Interface to ERP Extreme Significant Medium Low $100K 5 2 1

Statistical app Low Low Medium Significant 10 12 5

Org scorecard Significant Extreme Extreme Medium $50K 2 1

Implement DMS None Medium Low Low $500K $30K 30

Org portal Medium Extreme Low None $300K 1 1 1



©2011 Cutter Consortium Vol. 14, No. 2 BUSINESS-IT STRATEGIES




What is the problem, then? Why do IT governance departments fail to be established in the first place, or even when they are, why do we not hear of major successful PPM implementations every other day? In fact, how many organizations actually go through one version or another of a PPM process? The answer is: not too many, and certainly not enough.

One can claim that success in this area is only in a matter of time, or that portfolio management hasn't yet proven its value, but the unyielding truth is that it's on nobody's agenda. In fact, PPM goes against both the CIO and the business's agendas in what seems to be, at first glance, a contradiction to common sense. To examine this claim, let's try to figure out what is it the business and the CIO stand to lose by implementing PPM.


By creating an atmosphere of separation (and

confusion regarding IT), the CIO can create his or

her own kingdom, where the CIO is the sole ruler.



Actually, the real question is "How can the CIO not lose?" To better understand the recoiling from adopting IT governance, let's try to portray two - and for the benefit of our little exercise - radical images of the CIO and why IT governance is as alien a concept as Star Trek to both types.


The Autocratic CIO

If the CIO is the king of the castle and given full mandate over IT resources and budget, then IT governance is merely a washed term to describe a reality in which decisions regarding how and when to allocate resources are made by others (namely, business managers), and the way the CIO realizes those decisions is monitored and measured constantly - might as well strip away all authority and be done with it.

You may wonder, where's the drama here? Where's the big leap in understanding? After all, it's not like IT is not managed, and IT performance is not evaluated in much the same way as any other department. Why would the CIO feel adopting IT governance is one step away from losing his or her autonomy and authority?


The answer is very simple. Since it is much more difficult for senior management to manage when there's hardly any real transparency, adopting IT governance can be perceived, at the very least, as a leash by which to monitor (govern) the CIO's performance.


When talking about IT, one should keep in mind that CEOs are normally not ex-CIOs, and, in most cases, have a financial or marketing background, not a technical background (though this trend will be less applicable in years to come). Thus, it's not difficult to the average CIO to be evasive or fire back at a business representative whenever criticism comes along. By creating an atmosphere of separation (and confusion regarding IT), the CIO can create his or her own kingdom, where the CIO is the sole ruler. Why would this CIO want to mess this up?

Even in the world of vast technological change over the past few years, where business and management have changed dramatically, IT is still, in many organizations, a frightening and confusing domain, better handled by experts. Thus, it is a world where the autocratic CIO can still prosper.


The Savior CIO

Unlike the autocratic CIO, the savior CIO is all for transparency and joining forces with the business. However, this CIO views the business as if it's just a little kid, wanting "this and that" without ever knowing the consequences of requests, and someone - meaning the CIO - must save the business from itself. For this type of CIO, handing the keys to IT investment decision making over to the business will lead to chaos, and although asking business representatives to handle such decisions is a nice idea, it simply isn't realistic, more so for nonprofit or government organizations. The BU simply can't (or won't) think in the same manner as the CIO.



Unlike IT, in which a single person runs the show, the business consists of many individuals, each motivated by different agendas, so it's harder to portray a specific persona. However, we can describe a typical business culture and dissect how IT governance adoption would come about in such an environment. Again, let's consider two extremes.


The Wild West

The Wild West organization allocates IT resources to the CIO. As alluded to earlier, giving the resources to the CIO to decide what to do with this can be equated to letting the "cat manage the cream"; here, the business representatives are left indifferent to IT expenses and constraints. When the IT budget is the CIO's problem and the technology constraints are a foreign language, the business is free to demand whatever comes to mind without giving second thought to cost or benefit. In this land, business representatives would just as well not hear about IT hardships, and why should they? One business manager is as free as the next to ask for automation of nearly everything and anything, and if the CIO declines … well, that's what escalations are for.


The Charge-Back Organization

In this type of organization, each department has a different P&L and a charge-back model is implemented. Here, IT is in competition with any external vendor providing IT services. So if a BU is after a particular IT solution and is being refused by the internal IT department, then all that unit needs to do is go out to the IT market and purchase the required solution, whether or not it serves organizational strategy.

In some cases, the charge-back model is the catalyst for a defeated IT, with no mandate to stop whims or unrealistic adventures because the business departments are free to roam the IT service provider market for IT solutions should internal IT fail to satisfy business needs, imaginary or real. In the charge-back model, the business "owns" the IT budget and, as long as the desired outcome is delivered, the department manager can spend IT-allocated money however he or she sees fit.

Needless to say, internal IT is asked, after the fact, to take the solution provided by the external IT provider and house it on its servers, provide maintenance, and support and fix defects. So, if you were a business department manager in such an organization, would you care about "this or that" IT governance process?



When either the business or the CIO holds the keys to the IT budget and resources, and the business doesn't have to concern itself with questions of "Do we have enough resources?" or "Is it important enough?" or even "What was done in other departments, and can we just reuse existing solutions?" and the CIO doesn't have to reveal the way he or she allocates resources or give up any control over them, then nobody is accountable. A good governance process is bound to change this type of environment, so why adopt it? In other words, when no one really wants IT governance, what chances does it have?


Regulation Compliance as an Incentive

Regulations such as SOX have made the above question irrelevant in many organizations, as compliance is mandatory, and the organization must heed or pay heavy fines; these organizations are bound to establish governance processes sooner rather than later. I've often heard CFOs say that if they have to choose between investments that will create a profit of $20 million or investments of the same sum that will enable regulation compliance, they'll choose compliance investments without a second thought.


Indeed, regulation is a powerful incentive to adopt governance processes, and it is fairly easy to see that organizations subjected to regulations (the financial sector as an extreme example) are far ahead of other organizations in this area. In fact, one can dichotomously divide organizations into two groups: one bound to regulation (e.g., early and heavy adopters) and the other not bound (e.g., late and lean adopters).


When the IT budget is the CIO's problem, the business

is free to demand whatever comes to mind

without giving second thought to cost or benefit.


What Problems Do Governance Adopters Face?

Organizations trying to implement any governance process, and PPM in particular, face problems, and things are hardly rosy. As described earlier, the implementation of IT governance goes through several steps in an effort to create an understanding of the organization's goals and how IT can serve those goals. Whatever the ultimate goal, be that profit, or public service, or even world peace, there are various ways to accomplish that goal, and each BU will contribute a different angle. But who's to say which department serves the goal better, or more importantly than others?

Answering this question is at the very heart of a successful governance process. Let's say the IT has a budget of $20 million. And let's assume each department outlines its subgoals (driven by organizational goals), and initiative alignment to those goals are determined (see Table 1).

At first glance, it appears that HR initiative A is the most cost-beneficial ($36,000 with 63% alignment to business goals). But who's to say that 63% alignment to HR business goals is better than the 19% alignment at a cost of $71,000 for marketing's initiative B, or the 44%





Table 1 - Sample Alignment Rates per Departmental Initiatives Along with Cost


Department Initiative Alignment Rate Total Cost

HR A 63% $36K

B 55% $419K

C 21% $100K

Operations A 13% $200K

B 59% $590K

C 49% $85K

Marketing A 71% $150K

B 19% $71K

C 32% $300K

Sales A 50% $900K

B 44% $22K

C 8% $190K


alignment at only $22,000 for sales initiative B. In other words, when it comes to allocating resources based on business goals, how can we determine whether achieving the goals of the HR department is more or less important than achieving those of sales or operations?

Now we're back to square one: if IT is the one to determine which department will get more of the IT budget, then it's just "same old, same old." To sum it up: you're doomed if you don't adopt governance, and you're doomed if you do.

Another reason some business managers aren't enthusiastic (to say the least) about this process is that without it they can gain more. Let's assume we have a very vocal operations manager. Let's also assume that the politics is such that this manager has very strong relations with the right people in the right places, and the IT manager would just as well not go to war with him. It is not hard to guess what will happen. This manager will get almost everything he asks for, whether or not his requests are aligned with the business strategy and goals. Adopting a logical process eliminates emotional and politically based decisions


What Can Be Done Differently?

A hint to the reason that IT governance is in this catch-22 cycles lies in the terminology: IT governance suggests that it's IT's agenda to solve the puzzle, where IT holds the resources and IT needs to figure out how to allocate them. IT governance also suggests that it's better to involve the business and have a formal process in order to increase accountability, but it places responsibility over the entire process, from beginning to end, on IT's shoulders.

Indeed, when an IT governance unit exists (whether it's an individual or a group), it reports to the CIO; this is hardly a surprise. IT governance is taught in CIO courses and presented at IT conferences. Tools are suggested to CIOs and IT managers. Articles in the subject are published in IT magazines, and discussions are led by IT personnel. Consequently, IT governance ignores the business in the most vital decision - whether or not to adopt it. As unlikely as it sounds, the decision of whether to implement IT governance, which holds the potential to gravely influence the business, is made and controlled by the CIO with the business having little to no say in the matter. Here's where business technology management (BTM) steps in.



At its very heart, business technology management seeks to unify business and technology decision making at every level in the organization. BTM is an evolved IT governance concept, where business and IT are in tune in an effort to realize the organization's strategy.3 In fact, BTM practice seeks to improve the governance process so that IT is doing the right things, doing the right things efficiently, and doing the right things well

- see Figure 4.




Effectiveness Strategic AlignmmentEfficiency

Doing the right things effectively

Doing the right things efficiently

Doing the right things

Effectiveness Strategic AlignmmentEfficiency

Doing the

right things

effectively Doing the

right things

efficiently Doing the

right things

Figure 4 - Business technology management (BTM).


BTM is achieved through the following eight



1. Organization. This refers to the establishment of appropriate organizational structures; essentially, establishing a structure in which every staff member understands the scope and responsibilities of his or her role and understands the structure of which they are a part.

2. Information. This emphasizes the value timely information has in enabling effective decision making and puts in place a structure of data and metrics to allow for the best use of that information.

3. Technology. Appropriate use of technology can enable timely information sharing, improve coordination between members of an organization, and make processes easier to execute.

4. BTM capabilities. A capability is defined as a competency achieved as a result of combining each of the above dimensions and creating repeatable management processes. BTM defines 17 such capabilities, grouped into four functional areas.4

5. Governance and organization. These capabilities ensure that business technology decisions are effectively identified and executed; essentially, by developing an organizational structure that meets the needs of the business, gives consideration to regulation, and manages risk appropriately.

6. Managing technology investments. These capabilities ensure that the enterprise understands its current IT capabilities, what is currently available, and what is being worked on for the future. They also ensure that executives select the best technology initiatives to advance the objectives of the business.

7. Strategy and planning. These capabilities ensure that CIOs make the most appropriate moves to synchronize technology and business, both reducing complexity and planning for future developments.

8. Strategic enterprise architecture. These capabilities ensure that appropriate information exists that can describe current and future business environments and enable executives to make plans and implement strategies that will simplify the business technology environment within the enterprise.

If we don't address the issue that those running IT

and those running various business departments

perceive governance as a threat to be eliminated,

then the concept doesn't stand a chance.


How Is BTM Any Different From IT Governance?

For starters, regarding terminology, BTM manifests a holistic view, grouping together the business and technology into one term. But the fact is, conflict between IT and the business still stands whether we call it IT governance or business technology management. Regardless of terminology, if we don't address the issue that those running IT and those running various business departments perceive governance as a threat to be eliminated, then the concept doesn't stand a chance.


One way to manage the risk of "power of people over processes" (in this case, people can kill any process, regardless of its value) is to come up with a publicity campaign to explain the value. According to this way of thinking, if you can convince the population that the suggested process is for the greater good - and come up with plausible "what's in it for me" angles - everything will be just fine. The problem is such campaigns are very costly, and generally ineffective in our cynical world. Those who feel the process is a waste of time will probably continue to think that way, and those who feel the process is a threat to their position, job security, or prestige will proactively poison others and actively oppose it. So what can the organization do?


It's All About the Money


The main goal is to create a mechanism by which the IT budget per BU (probably above a certain size; small units will be associated with larger ones) will be defined for each year (or, in some cases, for multiple years at a time) in accordance to its perceived contribution to the realization of the organizational goals or based on size (depends on business strategy). For instance, let's assume the organization is willing to invest $200 million in IT during 2011. And let's also assume the business goal is to increase profit (for simplicity, we'll consider only one goal, though it's obvious organizations have more). Now, in our imaginary organization, the CEO allocates the IT budget in the way Table 2 Illustrates.


There are, of course, other ways to allocate the IT budget; for instance, allocating a certain percentage from the total budget of every BU to IT. But in the end, what we want to end up with is each BU devoting a certain sum to IT expenses and investments. The decision should be made by the CEO, not the CIO or the BU, and it should reflect BU size (i.e., the number of people in the BU that should benefit from IT services) and the priority level, in terms of IT, toward the realization of organizational goals. Following the same example,

Table 3 is a good visualization.



Table 2 - Sample IT Budget


Business Unit IT Budget

HR/Admin $10M

Operations $35M

Marketing $85M

Sales $70M


Table 3 - Sample IT Budget vs. Business Unit Size

and Priority Level to Organizational Goals


Business Unit Size Effect on

Org. Goals

IT Budget

HR/Admin 100 IPs Low $10M

Operations 400 IPs Medium $35M

Marketing 200 IPs Critical $85M

Sales 180 IPs Very High $70M



Once the budget is allocated, some ground rules should be outlined:

  • The IT budget is managed by the BU through a BTM

referent answering to both the BU and the BTM unit.

  • The IT budget can only be spent internally (so that no

mandate to seek solutions with external IT providers

will be granted).

  • Investment making is subjected to IT policy and can

be vetoed by IT. The veto decision can be revoked

only by a defined senior-level manager accepted by

all (preferably the CEO or CFO).

  • Out of the BU budget, a certain percentage

(normally decided according to BU size) is transferred

to IT for OPEX. There is no place for BU

judgment in the matter.

  • Decisions regarding IT CAPEX investments are

made by the CIO and are not subjected to the same

priority-setting process as BU investments.



Placing such a mechanism, with the above ground rules serving as key elements, is a surefire way to ensure true BTM in which business and IT are in sync far more than the common IT governance process discussed earlier. Let's consider why.


The IT Budget Is Managed by the BU Manager

The motivation behind this key element is that the organization needs to create accountability for the spending of the IT budget among BU managers. There can't be a process in which someone is allowed to ask for whatever he or she wishes without taking under account the cost and implications. To better understand this key element, think about children and how we educate them about money and spending. If you want your children to appreciate the value of money, you don't simply satisfy them with every little whim or provide them with all the toys on their wish lists. On the contrary, many parents set up allowances so their children can make decisions about how to spend their allowance, knowing full well that if all is spent, nothing will be left for their next whim. The business technology playground is much the same. Once responsible for their own IT budgets, BU managers will make better decisions as to how to spend the allocated money.


In other words, each BU will have to allocate an individual to be responsible for that unit's spending (be that purchasing or development spending; internal or external). This person must ensure the BU's IT budget is spent in a balanced way (so that the BU will not find itself without any budget left at midyear). The following will need to be considered when making IT budgetary decisions:

  • Balancing OPEX and CAPEX
  • Balancing purchasing and internal investments
  • Earned value over time
  • Compliance to IT policy
  • Alignment to BU and organizational strategy
  • ROI (according to IT policy)


While reporting to the BU manager, this role will have to also report to a cross-BU authority; namely, the BTM department.


What exactly is the BTM department? It is a unit, reporting to the CEO, with deep roots in both IT and the CFO office. This unit is responsible for the implementation of governance processes across the board. Each BU should allocate someone (doesn't have to be full time) to work with this unit. This unit should have the authority to bridge business and technology needs and be given the responsibility to realize the BTM concept. We will discuss specific roles and responsibilities of the BTM department later in this report.


The core value of BTM emphasizes the transfer of authority from the CIO to the business and the BTM unit. However, this transfer does not mean the CIO will be any less important, as the following sections illustrate.


The IT Budget Can Only Be Spent Internally


IT is the only unit in the organization that has the full understanding of cross-organizational needs, existing solutions, and redundant needs and implementations. Moreover, IT is the unit that will ultimately have to take responsibility over the solutions provided to the business and provide ongoing maintenance and support. Hence, limiting a BU's "purchase" to the internal IT department is the only logical path. Let us imagine a situation where each BU shops for solutions elsewhere. It is not unlikely to assume that this will lead to multiple technologies, approaches, and applications that will eventually need to interact with each other. It doesn't take an IT expert to understand the inefficiency of such a platform.


But this is only half the story. If IT is to improve its performance, it needs to know that the business is counting on it. Having the option to U-turn to another provider, regardless of how effective IT is, only creates an atmosphere that IT is not gravely important since BUs can always go elsewhere. In business, as in life, the key to improvement lies in the level of support and the sense of value and appreciation you receive.


The core value of BTM emphasizes the transfer

of authority from the CIO to the business and the

BTM unit. However, this transfer does not mean

the CIO will be any less important.


Investment Making Is Subjected to IT Policy

As said earlier, IT should have a say in what is developed, not only in the how. The question is, however, what is the depth and level of this input. While input should always be strong and effective, it should also be incorporated into a well-understood, agreed-upon policy. This policy can include various statements, such as:


  • Specificity regarding duration. For example, projects

more than eight months in duration will have a project

manager allocated from the BU and a steering

committee with a senior decision maker allocated

as chairman.

  • Level of aggregative risk in which IT is willing to

be exposed. In other words, if IT commits to several

projects for which the accumulative risk level is x,

then IT is entitled to reject any further risky projects

in a given year.


The above are, of course, just examples to items that can appear in the IT policy. But policy should be determined per each organization, based on culture and involved parties.


Maintaining IT policy will achieve two things. First, IT will not be considered (by BUs or IT) a rubber stamp, forced to approve and commit to any initiative. This is a prestige issue that is important for morale and the CIO's sense of control over his or her unit. But far more important, without a policy, the organization will be left with a castrated IT with little to no impact, deprived of any ability to be gatekeeper. Thus, IT policy can incorporate the understanding of the value IT has in seeing the bigger picture and can set the foundation for the business and technology relationship. This relationship can be characterized by the following statement:


The BU is responsible and accountable for the IT expenses

in its unit; at the same time, IT is responsible and accountable

to maintain a policy that will allow the BU to exercise

its responsibility in a manner that benefits the entire




A Certain Percentage Is Transferred to IT OPEX

and Organizational Foundations In today's organizations, whether or not they implement IT governance processes, IT is typically given a budget to deliver new systems and services while maintaining existing ones. The IT budget manager is authorized to pay OPEX and allocate the remaining budget to the business or technical initiatives to be pursued. OPEX are expenses the CIO has no choice but to pay(e.g., SLAs). On top of these expenses, IT is responsible to provide fundamental capabilities to the entire organization (e.g., exchange services, document management, task management, ERP, CRM). These capabilities are provided by organizational applications. All beneficiaries should pay the cost of these capabilities based on a load model. An important understanding should be that while BUs are asked to pay the cost of these functions, they have no judgment call regarding rates.


Keep control over technical issues (which are the

CIO's domain, after all) in the hands of the CIO

and undermine any political-driven decisions.


What is the load model? The expenses described above should be allocated to the BU's IT budget based on some method defining the distribution of expenses over the organization (which can be part of IT policy). The expense distribution policy can be viewed as a tax, paid by each BU to cover OPEX. The most trivial load model is based on size. More sophisticated models will take into account the number of service requests or the number of existing applications per BU. Whatever the model, IT should be its owner, and the BUs should be agreeable parties.


A relevant question regards how the load model will work in the cloud computing environment? In cloud computing, most services can be priced in a far more

simpler way. In fact, the load model can be eliminated all together, and a per-person cost can be established. In an organization employing cloud solutions, almost all services in the service catalog can be mapped to state who is using which service and how much he or she consumes.


Decisions Regarding IT CAPEX Investments

Are Made by the CIO Alone

While business investment decisions are made in a formal process, the initiatives that are cross-organizational are determined by the CIO and his or her staff. These investments will affect the entire organization and are technical in nature. The ultimate reasoning here is to keep control over technical issues (which are the CIO's domain, after all) in the hands of the CIO and undermine any political-driven decisions in that arena. That means, a BU cannot simply refuse to take part of "this or that" cross-organizational initiative. For instance, let's imagine that IT decides to upgrade its Oracle ERP version. Let's also imagine that this upgrade is a project that will take five months to achieve and will cost $300,000. In theory, the organization's delivery department (or any other customer-facing group) can claim that there's no benefit for such a system and, therefore, refuse to pay its share for the upgrade. Such a "democracy" will kill almost every organizational initiative. Therefore, the mandate for organizational investments should be in the hands of the CIO with the supervision of the BTM unit.


The BTM Unit


The BTM unit can be diverse in size (ranging from a one-person show to a group of people) as long as some key elements are fulfilled:

  • Its place in organizational hierarchy provides closeness to senior management. (Most of its authority will come from this closeness.)
  • It has extensive budget for implementing governance processes. The budget is an indication to BUs, as well as to IT, of the value management places on this unit.
  • It is deeply rooted in the CIO arena, as well as the CFO's, and can bridge technology with finance.


Roles and Responsibilities

The following checklist describes the roles and responsibilities of the BTM unit:

  • Takes responsibility for the implementation of

the governance process.

  • Acts as gatekeeper in business technology decisions.
  • Acts as a mediator in conflicts regarding BTM.
  • Sets load model and ensures buy-in from all BUs.
  • Monitors BU expenses.
  • Defines ROI/EVP targets.
  • Assists in defining IT policy and ensures compliance.
  • Takes responsibility for regulation compliance

and quality assurance.

  • Takes responsibility to ensure a tangible business

strategy (top-bottom).

  • Sets capacity and resource-allocation model.
  • Provides tools and management dashboards for monitoring and controlling expenses, resources, and strategy alignment.
  • Takes responsibility for organizational risk analysis and mitigation plans.
  • Takes over planning and control processes to provide yearly and multiyear plans and realizations.


The BTM unit should be politically strong, well budgeted (to provide "carrots" when needed), and within proximity to the CEO (to use the "stick" if needed). A weak BTM unit is not equivalent to no BTM unit - it's even worse!



Governance solutions are synonymous to accountability, transparency, audibility, and traceability. These are the building blocks of a stable, success-driven, and growing organization. At the same time, these are the attributes people tend to fear and reject for they go directly to our insecurities and ego. To bind an organization to governance processes - and ultimately business technology management - is not an easy task, but it's a must. It is the very thing that differentiates a successful firm from a stay-in-place one. In this report, we examined the complex relationship between business and IT in realizing strategy, but the fact of the matter is, we can also apply induction of this process to the relationships between product marketing and customers (where customers are initiating demands and the business decides what and when to perform), or any other delivery organization. At the end of the day, any demand-to-supply process that combines business and technology needs a BTM framework.





3The principles behind BTM have been developed and refined by BTM experts working with such think tanks as the BTM Institute ( and IIBT - International Institute of Business Technologies (


4See Technology_Management.



Rachel Mendelovich has 17 years' experience in IT, with more than seven in top managerial roles. During her career, she has held positions in various companies, including large global organizations, small startups, product companies, and retail companies. Recently, Ms. Mendelovich led the implementation of IT governance processes in the Israeli government and is a known lecturer in the field. She holds a BA in computer science and an MBA from Hebrew University (Israel). She can be reached at


©2011 Cutter Consortium