Strategic Direction


Regardless of whether you primarily view IT as a financial asset or as a product (which is itself is a topic of much philosophical debate) the fact remains that, from the simplest standpoint, it has intrinsic value and it can produce value. Therefore, its proposed allocation and actual assignment should be governed in the same manner in which you would manage a portfolio of assets or of products: being careful to consider balance, financials, risks, benefits, life term , and the like. Many can accept the basis of this argument. What is not well understood , and what this chapter explores further, is how the critical insights necessary to do so effectively can be found in the models generated during the activities of BTM.

The CIO is the Ultimate Portfolio Manager

As the role of the CIO has shifted alongside that of IT, one of the responsibilities that has risen to the forefront is setting the company's strategic direction with regard to technology. To manage this direction, CIOs need to be able to prioritize initiatives, justify decision-making, measure risk versus return, and allocate resources in a way that maximizes their impact upon the business. The fact that this isn't yet standard practice can be readily evidenced through industry surveys:

- 89% of companies are unable to adjust and align their budgets with business needs, other than once or twice a year.

- 66% of IT organizations are not "market-ready." They have no idea of their performance profile in terms of costs or business value generation.

- 89% of companies are flying blind. They have virtually no metrics, except for finance (which is sort of like flying a plane by monitoring the fuel burn rate). [1]

Most CIOs find it challenging to set strategic direction because of three factors. First, it is difficult to gain critical and timely insight into IT. Second, it is necessary to maintain alignment with the business as conditions change or new directions emerge. Finally, the CIO needs a consolidated view of the resources under their purview before they can set direction. Together, these three factors are driving many CIOs to adopt portfolio management techniques for setting strategic direction. In basic terms, this means gaining an aggregated view of IT investments across the enterprise, measuring them against established criteria, and then striking the appropriate balance within the portfolio that best serves the strategic goals of the enterprise.

One overriding concern for portfolio managers is to balance the risk and value in their investments. In one form or another, applying this balance is quite familiar to the CIO's peers from finance, marketing, sales, and product development. If IT is to be managed like the rest of the business, it needs to follow this same path , with the CIO playing the role of the IT portfolio manager. This doesn't mean, however, that IT can be reduced to purely financial metrics. IT is engineering-based; a company can't simply turn their CIO into a financial analyst and expect him or her to manage strictly by a spreadsheet.

Discounted Cash Flow or Cash Cows?

Portfolio management can be an equally important technique whether you choose to consider IT an asset or a product. Companies that ask their CIO to either report directly to the CFO or to function as a fund manager who doesn't shy away from financial accountability probably fall into the asset camp. Chances are that they will gravitate towards portfolio management techniques that are inherited from traditional corporate finance management. This type of portfolio management has roots reaching back to the 1950s with Markowitz's Modern Portfolio Theory and to the 1970s with Black and Scholes' Real Options Valuation.

The product camp, on the other hand, tends to prefer a more market-centric approach to portfolio management that draws upon the Ansoff or Boston Matrix to strategically plot and manage product portfolios along composite dimensions, such as risk and value or growth and share. The inherent risk for this camp is that complex IT investment decisions may not easily reduce to a four-, six-, or nine-quadrant box (see Fig. 8.1, which compares an asset camp technique ”discounted cash flow ”with a Boston matrix from the product camp).

Figure 8.1. Discounted cash flow (an example of an "asset camp" approach) versus the Boston matrix (a "product camp" approach)

Regardless of which camp companies fall into, however, the IT portfolio helps them to evaluate the risks and rewards of their investments as an integrated whole. By analyzing parameters including risk, return, capabilities, competitive intensity, market variances, and others, they can measure and understand the assets (or products) for which they're responsible and determine which to pursue , which to abandon, which to invest more heavily in, and which to simply maintain.

The general principle that is driving companies towards IT portfolio management is a simple one. An automotive company wouldn't manufacture a car without first undergoing a comprehensive analysis and design process to determine if the car would sell in a given market, how much it would cost to manufacture, what price it should garner , what features and functionality it should have, how long it would take to produce, what resources would be consumed in its production, where the break-even point would be, how it fits in relation to the rest of the product line, what the relative life cycle and maintenance requirements of the vehicle would be, what competitive or environmental conditions such as new industry regulations would have an impact, and so on. And a corporation shouldn't decide to invest in a particular technology without following the same general rules.

The point of this chapter isn't to carry on an exhaustive discussion of how to use any of the aforementioned methods ; there are plenty of websites , articles, papers, and books that cover each, and describe how to apply them from A “ Z. Nor is the point to endorse any one vis-  -vis the others. Each organization is different, and so there is no "one- size fits all" answer for managing the IT portfolio. The point that you should take away from this chapter is that, generally speaking, portfolio management of one sort or another provides a mechanism for the CIO to plot strategic direction. As you will see moving forward, it helps companies answer the essential question, "Are we doing the right things?" more accurately.

Not Just Financial Measures

IT has always been subject to financial scrutiny. But much of the analysis has concentrated only on a partial picture, and has resulted in the impression that IT has overspent and under-leveraged its investments. If you are not convinced, just check with any CIO that lost a budget arbitrament (if not a career post) by managing solely by the numbers. This is a mistake. IT portfolio management shouldn't be reduced solely to financial measures. It's simply not as easy as plugging numbers into a spreadsheet and making inferences from that. Just look at where relying on the sacrosanct measure, ROI, has led the industry. For years , IT projects have been subject to approval based upon the merits of expressly quantified ROI. The line of thinking has been that ROI somehow equals project success ”work the math, and as long as two plus two equals four, things should turn out right. Unfortunately, countless projects have failed miserably and cost companies millions of dollars (if not shareholder value), despite being justified according to supposedly solid ROI assertions. That's not to say that ROI as a tangible measure is intrinsically flawed and should be discarded altogether. It is an important indicator when formulating IT investment strategies, but it is just one piece of the puzzle. Of equal, if not more importance, are intangible measures.

Intangibles are more qualitative and thus more subjective in nature than tangible measures. Tangibles include operating costs, income, assets, liabilities, profit margins, return on assets, and other measures that lend themselves to being expressed as financial ratios. Intangibles on the other hand, comprise a diverse range of measures, which may include strategic fit, goal alignment, opportunity costs, customer connectivity, competitive threat, return horizons, business impact, process optimization, intellectual capital, skills, and innovation among others.

There are three problems with only relying on tangible measures. First, there is a cultural proclivity to "work the numbers" to make them say what people want them to say. Second, tangible measures are largely reactive, while intangible measures lend themselves to forward-looking views, since they often drive the tangibles. (Intangible measures often contribute directly to productivity, profitability, and ROI, for example.) Finally, many of the benefits that follow from IT projects are hard to define in the direct, financial terms that tangible measures require. For example, a company may notice that after installing a sales force automation platform their revenue increased over previous quarters . But this says nothing about how much of the increase is due to the software and how much is the result of other factors such as a growing market or a new compensation structure for the sales team. What IT is, meaning its life as a capital or physical asset, warrants evaluation with a tangible set of measures. But the majority of what IT actually does falls more into the sphere of the intangible.

A good balance of tangible and intangible measures allows IT portfolio managers to anticipate the potential value of technology investments by providing:

- Visibility into future risks and causal relationships

- Safeguards against slippery -slope conclusions

- Counterweights to over-inflated promises and expectations

- Flexible accommodation for rapidly changing environmental influences

By formulating a more holistic picture of the potential value that resides within and that can be generated by the IT portfolio, CIOs can offer their business counterparts more realistic valuations of IT investment returns.

A Single View

One primary advantage of utilizing a portfolio approach is that it provides a single view into diverse IT initiatives that, after the recent wave of decentralization, may be spread across 40 or more business units occupying hundreds of locations. That alone is of tremendous management value for the CIO, whose responsibilities generally span multiple organizational and budgetary silos . Such an aggregated view typically encompasses the following categories, although a different or further stratification can occur depending upon the organization:

- Infrastructure (e.g., networks and hardware)

- Applications (e.g., commercial off-the-shelf or in-house)

- Information (e.g., corporate and customer data)

- Processes (e.g., value-chain activities)

- Human capital (e.g., skills or experience)

- Relationships (e.g., vendors or contractors)

These IT resources are then associated with projects that have specific attributes assigned to them, such as an owner, schedules, milestones, allocated resources, a budget, costs, risk, expected returns, scope, status, priority, and other criteria that can be useful for tracking or applying weighted scores. Projects are further classified into programs (which represent logical groupings of projects) that help portfolio managers utilize a working framework for balancing the portfolio, identifying similar projects to avoid "apple to orange" comparisons, and creating an additional layer of abstraction for the office of the CIO from possibly hundreds of staggered or parallel projects (see Fig. 8.2).

Figure 8.2. A portfolio can consist of projects and sub-projects that can be grouped into programs to identify similarities

In this manner, CIOs and their extended team are able to view aggregated cross-sections of information about the state of their IT investments for holistic ”not stand-alone ”decision-making. So, for example, the CIO could use this method to quickly assess all the instances where a particular vendor's solutions were slated for use across the year's remaining projects in order to ultimately strengthen purchasing leverage. Or, they could determine that core infrastructure investments are currently under- funded in relation to the projected increase in demand that will occur as a consequence of adding a new subsidiary business location. Or, they could find out what the distribution of IT spending is across all the departments that IT supports. It may be trite to say that trying to decipher this information otherwise would be like looking for a needle in a haystack, but that is truly the case.

As a best-practice precursor to this type of strategic planning, a baseline assessment of existing IT resources needs to be in place. Recall from the activities of BTM that the very first step is to identify a current enterprise model that describes the organization's as-is state. Since this enterprise model contains the complete set of artifacts enumerated in the categories bulleted above, it helps to construct the portfolio. This baseline assessment is not to be confused with an asset inventory that would be assembled for the purposes of managing an asset's life cycle from procurement to retirement. An inventory, although useful, has limitations in this case. First, the baseline assessment is intended to assess the level of fit between a company's business requirements and its IT investment mix. An asset inventory, by design, will not produce this kind of insight. It would be insensible to base a go/kill decision for a project on a rank list of assets. Second, the asset inventory doesn't take into account the majority of the aforementioned categories, such as processes. The vast store of information that is needed to conduct such an analysis is better derived from the enterprise model, as it describes the allocation of the full range of categories in relation to the business objectives that they support and the critical interdependencies that exist between them.

From the Bottom Up

Analysis is the heart and soul of any portfolio approach; it's where managers make the final call about how to allocate investments in the portfolio. At the same time, analysis is far and away the most difficult step in the process. A common criticism of applying portfolio techniques to IT is that it is done in a vacuum , and so managers aren't necessarily equipped with the underlying data they need in order to effectively evaluate opportunities, threats, and constraints. You can't measure what you don't know about. Consider how effective the practice of CRM, which aggregates data about customers into an overarching view for strategic analysis and action, would be in the absence of sufficient underlying customer data. Customer lifetime value (CLV), which helps companies determine the most profitable customer segments, is one of the most essential metrics in CRM analyses. Without having access to the disparate data that combines to calculate this metric ”such as frequency of purchase, amount of customer spend , and cost to acquire and service the customer ”it is nearly impossible to assess CLV. The same would be true for conducting effective IT analyses in the absence of any supporting information.

This vacuum is partially attributable to a gap between the IT portfolio and the resident data. The data is either buried in a spreadsheet or project plan or it is locked away in the heads of personnel that perform specialized functions. In any event, this presents a secondary set of complications. The more difficult it is to assemble the required data, the less likely that it will be maintained or even gathered in the first place. The focus then also shifts from the analysis of pertinent data to the collection of it. Charles Popper of The Program on Information Policy Research at Harvard University states it thus:

Relying upon ad hoc, manual methods to collect and process data, with support from standard productivity tools, is certainly possible, but if more effort is expended on data collection and correction, then less time and fewer resources are available for the analysis and decision-making needed to manage the portfolio and its projects. [2]

The final complication is that the greater the distance between data and analysis or the more times information is translated during the course of moving from one point to the next , the greater the likelihood that inaccuracies and misinterpretation will occur.

The models produced during the activities of BTM help to alleviate these data difficulties. Business model definition, process optimization, and technology automation surface the critical underlying data elements that are necessary for applying both tangible and intangible measures to the portfolio. The data elements that are generated as a natural by-product of these activities provide managers with visibility into a wide range of insights that is otherwise missing. These can be insights regarding hidden costs, direct and indirect benefits, requirements (capital, functional, human), process capabilities, mix (customer, supplier, vendor, technology), performance, time-to-market schedules, trade-off implications, standards and quality compliance, feasibility, etc. When funneled up, these insights enable portfolio managers to draw appropriate, non-skewed conclusions in relation to risk and return. That is not to say that it is incumbent upon portfolio managers, be it the CIO or his or her delegate, to sift through the minutiae. Rather, they benefit from the cumulative reasoning that occurs throughout the design activities and have a means to follow the cookie crumb trail of validated assumptions if necessary.

Consider a simplified example: The current year corporate strategy of a large manufacturer entails a directive for increased profit margins via global expansion in a particular market. Executing on this goal requires the development of a series of integrated strategies across the functional domains of the company. From there the decision has been made that product X has the greatest potential for distribution and sales. A central initiative (initiative A) to the business unit's strategy is to connect with key suppliers to reduce the cost of materials. The challenge for the office of the CIO is to set a strategic direction for technology that will achieve that objective given the stated parameters (e.g., budget, time) for initiative A, and to meet it within the context of the company's other running objectives.

The office of the CIO has the IT budget allocated among non-discretionary (maintenance and operations), discretionary (consolidation and upgrade), growth (strategic), and venture (innovation) categories. These categories are likewise broken down into respective projects and programs. Any IT strategy that is devised to meet the objectives of initiative A (along with the associated projects/programs) must be evaluated with respect to its strategic fit with the other categories.

A cross-functional team of business and IT analysts proposes automating regional supplier relationships. But is this the direction that IT should be taking both for the initiative itself and for the portfolio on the whole? The CIO must be sure of this first, before he can sell it to the business unit co-sponsor.

The data that is required to validate this proposal comes from the activities of BTM, since they help to quantify the project's cost, risk, and expected benefits (see Fig. 8.3). The activities validate that automation will lower sourcing costs (business model definition); sourcing and approval processes will have to change while procurement managers, demand planners, and purchasing agents will need to be retrained (process optimization); a new procurement application will need to be purchased; and a consulting partner will need to be contracted to integrate the platform with the legacy financial system and supply chain systems (technology automation).

Figure 8.3. The models produced during the activities of BTM provide the underlying data for analyzing the IT portfolio

By using the data derived from these activities, the office of the CIO can make informed assessments of the proposed project's specific risk and value. Next, they can balance criteria like project cost to hedge against unforeseen fiscal constraints, term length to allow the department to address perceived long-term trends without gambling entirely on an untested concept, and scope to mitigate against dramatic changes in the business. The CIO or a member of the PMO can then extend the initial project analysis to determine fit with the overall IT portfolio investment mix. By calculating the tangible and intangible measures derived from the business, process, and technology models, the team is able to demonstrate that their project aligns with corporate objectives and fits within the allocated spend for the IT investment growth category. In this way, the CIO can be assured that IT is doing the right thing and can ultimately demonstrate it to solicit business unit buy-in.

Navigating and Negotiating

Beyond providing the raw data to analyze IT investments, the models produced during the activities of BTM facilitate two additional objectives that relate to strategic direction:

- Monitoring the portfolio to periodically reanalyze risk and value

- Communicating decision-making criteria to other stakeholders

Monitor and Periodically Reanalyze

Even after being given the green light, most project methodologies define gates through which an initiative must pass in order to progress. Gates often coincide with traditional project milestones (such as the selection of a technology vendor), but can also be triggered when total costs exceed a pre-defined amount or in response to ongoing project audits . These are good opportunities for the IT portfolio manager to re-evaluate his or her investment in the project. Assessment should never be a one-time event. Changes in the risk or value of an IT project (and by proxy the whole portfolio) can quickly occur, for example, as the result of a new competitive positioning for the company or a shifting business landscape. Recall from Ch. 1 the continual stream of changes encountered by Patrick Flynn's team in their customs -clearance system project. The decision criteria to stick with the project might have been dramatically different had there been visibility to these shifts in the business climate earlier in the process.

Until this point, the practice of managing by exception ”whereby managers take corrective actions based upon proactive notifications of problems ”has been traditionally difficult. It requires that key decision-making information about the project remains up-to-date at all times. Generally, standard approaches to project management result in managers receiving lagging updates concerning a project's status. The models developed during business model definition, process optimization, and technology automation can help to overcome this challenge, because they capture an accurate snapshot of progress throughout each step of its design. Decision criteria can be associated with individual elements in the model, and when the model changes, the criteria can be updated in real time to determine if an exception should be highlighted. This helps identify projects early on that are out of variance so that portfolio managers can recalculate their risk and value assessments.

Communicating through Visual Aids

The process of managing the IT portfolio is ultimately about determining the strategic direction in which the IT department is headed. As such, it's the office of the CIO that is the ultimate portfolio manager, and the IT department that needs to be responsible for making sure that investments are aligned with overall business strategy. Keep in mind, however, that the CIO doesn't have sole budgetary control over every IT expenditure. Projects may be initiated and ultimately funded by the business units for whom they are intended, or by an IT investment committee comprised of the CIO, line-of-business sponsors, and representatives of the CFO. This means that senior IT leaders need to work with other stakeholders from the business to develop business cases and secure funding. It is far more likely that a line-of-business sponsor or a financial executive will give the go-ahead if they can assimilate how the project will serve their aims. Again, the business, process, and technology models developed during BTM can play a crucial role here. One of the key advantages of modeling that Ch. 4 discusses was that models are powerful tools for visualization. They can help participants at the negotiating table to separate the map from the territory and safeguard against funding determinations that may be shortsighted or that may be driven by the individual that wields the most power.

MIT professor Peter Senge's seminal work, The Fifth Discipline , addresses how impasses occur between departmental or functional areas of responsibility owing in part to the fact that people carry with them ingrained "mental models." [3] People vigorously defend these models, which contain their hidden beliefs and assumptions. Historically, IT has had considerable difficulty in changing the mental model that the business holds regarding IT's efficacy. This leads to perennial conflict when it's time to negotiate, especially if neither side is particularly fluent in the other's language. With three-quarters of the IT budget traditionally being allocated to keeping the business up and running, it's always a struggle to agree on how the remainder of the pie should be divided up to achieve the organization's goals. This is even more so the case in times of economic softening when executive decision- makers are required to take apart budgets and trim excess fat. The outsourcing craze of the 1980s when IT itself was viewed as excess fat still sends a shiver down a few CIO's spines.

The models created during the activities of BTM can be used to eliminate any entrenched biases and objectively demonstrate how IT plans to align to the business ”and how it arrived at its conclusions. These models represent fact, not fiction . By using the models as a point of reference in the negotiations, IT can't be accused of "voodoo economics" and business units can make intelligent concessions according to the dictates of a level playing field. In addition, models, through their visual nature, also provide a common language, allowing an easier exchange of information to occur between the two domains. Traditionally, each domain has had difficulty in understanding the other. Models, however, create a shared language that can reduce the likelihood of misinterpretation between the "bureaucrat" and the "technocrat." At the end of the day, both sides need to come together to prioritize and allocate IT spend in a manner that benefits the corporation as a whole, and models can help foster the rapport and dialogue necessary to do that.

Governance Pop-Quiz

"If you are CIO of a global business, just keeping track of the myriad of IT initiatives across the business units, and aligning these with each other and with corporate goals, is very challenging. You have to make sure that initiatives are consolidated and that you have some sort of perspective going forward, not just looking at the historical performance of the business but looking at the potential future performance. Really, you should be considering how your answers stack up to the following questions:

- Do you have a mechanism to communicate in the same language as the CxO community?

- Can you demonstrate how you are aligned with the directions the business wants to go?

- Has your world become more complex than a spreadsheet can handle?

- Do you have a good picture of all your existing resources?

- Do you know the relationships and dependencies between the business portfolio and IT assets?

- Can you explain your technology portfolio to business management?

- Do you know where new vendor offerings fit and may help you?

- How do you assess costs, risks, and the impact of changes before you commit to building systems?"

Howard Smith, CTO, CSC Europe



The Alignment Effect. How to Get Real Business Value Out of Technology
The Alignment Effect: How to Get Real Business Value Out of Technology
ISBN: 0130449393
EAN: 2147483647
Year: 2001
Pages: 83
Authors: Faisal Hoque

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net