Chapter Eleven. Financial Management

Accounting is all about tangible assets. But given similar financial resources, these types of assets can be purchased by any company. Tangible assets provide organizations with a basic, off-the-shelf capability or platform for competing against other organizations. Intangible assets such as systems, software, processes, training programs, and research and development (R&D) represent investments that provide future value regardless of accounting reporting convention.

Joe Stenzel¹

1. Joe Stenzel, Lean Accounting: Best Practices for Sustainable Integration (John Wiley & Sons, 2007), Kindle loc. 2144–48.

There are three reasons why this is the longest chapter in the book: The ability to secure funding is often one of the weakest skills among IT professionals; money is the universal language of business and therefore can serve as a unifying force to bring disparate groups together; and effectively managing financials, especially related to intangible assets such as data quality and future flexibility, is very hard.

By emphasizing commercial disciplines, we are seeking to ensure that the Lean Integration team (the Integration Competency Center) does not become isolated from the business environment that sustains it. Credibility is established by not only operating a successful ICC, but also being perceived as doing so as measured by the willingness of the parent organization to support the program financially.

This chapter addresses specific practices for making capital investments to drive continuous improvement, using financial metrics to enable cross-functional alignment and support, and using chargeback accounting to fund ongoing operations in a sustainable fashion.

In essence, running a shared-services function such as an Integration Factory or an ICC is very similar to running a business. The factory or ICC offers services to multiple internal customers and encourages adoption of standards by meeting customer needs through demonstrated value. The free-market economy offers an excellent example of how to build a vibrant, responsive, and sustainable business. While an internal business is not in it for the “profit” (at least not for itself), it can leverage many of the foundational elements that make the market economy work:

• Contract law: For an ICC, this translates into having well-defined services (e.g., written commitments) and keeping the promises that are made to internal customers.

• Common currency: An ICC implements this concept through internal chargeback accounting or transfer prices; while no real money changes hands, it nonetheless serves as the basis for measuring the ICC’s value.

• Regulatory environment: The organizational equivalents are internal policies and standards; an ICC may be responsible for governing certain integration standards that apply across functional groups.

Table 11.1 provides an outline of four levels of financial management maturity as they relate to integration initiatives. This table can be used as a tool for assessing an organization’s current level of maturity and for establishing a desired target maturity level.

Table 11.1 Financial Management Maturity Levels

Challenges

Regardless of which economic model is used, an ICC that relies on shared IT infrastructure will need to make periodic investments to sustain the shared environment. To be clear, we are not referring to minor enhancements, ongoing maintenance, or minor process improvements, but rather to efforts that require a significant investment in human or financial capital in order to eliminate waste or reduce cycle times. Examples of significant investments include

• Metadata-driven tools to automatically generate or deploy integration solutions

• Factory dashboards to streamline information flows and reduce cycle time

• Rationalization of databases and establishment of an enterprise data warehouse

• Investment in data quality tools

• Major software upgrade of an existing shared-services environment

• Implementation of a high-availability grid computing infrastructure

• Technology refresh of a distributed integration system

These types of investments require funding that falls outside the day-to-day operations of an ICC. Although an ICC may operate for a year or more without requiring a major investment, eventually a significant investment is necessary. The questions that inevitably arise relate to how organizations should fund these efforts or even if and when they should undertake them in light of all of the other demands on limited capital resources.

Many ICC teams struggle with the issue of securing funding for infrastructure investments for which the need seems intuitively obvious to them. For a number of valid reasons it is difficult to create a business justification for a shared IT infrastructure. Some of the key challenges are outlined in this chapter.

It is also particularly crucial for ICCs to be able to change organizational behavior. A desired change may be simply to have certain activities performed by a shared-services function rather than individually by each enterprise silo; or it may involve aligning customer processes and business metrics across lines of business. In any event, while leading change in a large organization is not easy, it can be accomplished with an appropriate campaign. The following sections explore the underlying culture and forces in place that can cause roadblocks to change, and set the stage for how financial management practices and measures can break down those barriers.

Lack of Competition

The general opinion of a customer of an internal shared service is that external providers deliver better value as a natural outcome of competitive pressure. The perception is that internal providers either lack motivation or are resource-constrained and have little capacity for making process improvements. Standardization does allow a process to be well defined and executed, but it also introduces rigidity, which is the enemy of innovation.

So the first challenge to address is the danger that complacency will pervade the day-to-day operations of the ICC. From the moment of its inception, the ICC has to demonstrate that it is the most cost-effective option for delivering the required services.

Functional Silos

Enterprises are generally subdivided into a number of functional areas such as marketing, sales, distribution, finance, and human resources; these are commonly referred to as “silos” or “stovepipes.” Deep knowledge of its own data and processes exists within each functional area, but little is known about other functions. Given the complexity and scale of the activities that are required for most enterprises to function, it is simply impossible for any one individual to understand all of the details. Yet the overall efficient operation of the enterprise requires a common understanding of data and seamless interaction across multiple functional teams.

The existence of functional silos and the absence of an end-to-end view are the root causes of the following types of issues:

• Production outages caused by unintended consequences of data/process mismatch

• Retrospective data cleanup efforts

• “Fire drills” to capture holistic snapshots for regulatory, compliance, or senior management reporting needs

ICC personnel need to free themselves from the “bunker mentality” and be proactive in the building and understanding of processes and functions throughout the enterprise. By definition, ICCs are chartered to optimize the whole; that means the staff will constantly face resistance from one functional area or another.

Supply and Demand Mismatch

Resources for a centralized function like an ICC tend to be budgeted on an annual basis, resulting in a capacity that is relatively stable and fixed. This conflicts with the demands of the project portfolio, which can fluctuate dramatically over the same period and therefore are difficult to predict in advance.

The resultant mismatch between supply and demand is the root cause of the perception that shared-services functions are unresponsive and inflexible.

For example, Figure 11.1 shows a flat line of about ten FTEs (full-time equivalent staff) representing the number of staff budgeted for the ICC for a one-year period. The wavy line shows the number of FTE resources that are required at various times throughout the year to respond to the demand for ICC services. In this example, the months of January through March are problematic since the ICC staff may be sitting idle. This could be a benefit for the ICC since staff may be able to use the excess capacity to perform some process improvement activities, but it could be a negative factor if senior management is looking for places to reduce head count. May and June are also problematic since there is a demand for 60 percent more resources than are available. In this situation, the ICC director has only three options:

1. Refuse the additional work.

2. Lower quality on all of the work so that ten staff members can get it all done.

3. Make the staff work evenings and weekends to get all the work done.

Figure 11.1 Demand and supply mismatch

None of these options is ideal, and all can have long-term negative consequences.

Conflict of Incentives

As described earlier, organizations are complex, so they are divided into functional silos. Each silo is rewarded and motivated to optimize its own operation; however, optimizing the whole may require sub-optimizing the parts.

Gaining the maximum benefit across an enterprise requires each silo to make trade-offs that may impact individual staff incentives and rewards. The conflict of interest (goals) between the silo perspective (trying to optimize the function) and the enterprise perspective (trying to optimize the whole) is the root cause of enterprise gridlock.

Diseconomies of Scale

One of the main reasons for centralization is to gain economies of scale. For example, multiple groups within an organization may perform similar activities but with varying degrees of efficiency and consistency. Centralizing the activities makes it easier to standardize and streamline the work, and thereby reduce the cost per unit of work, while improving quality and consistency. Centralization also allows scarce expertise to be consolidated.

Less well understood are the diseconomies of scale that can arise through centralization; for example, diseconomies of scale arise when the per-unit cost increases as the volume of work increases. The reasons for these diseconomies include factors such as

• The cost of communication between the central group and the rest of the organization

• Top-heavy management within the central group becoming isolated from the effects of their decisions

• Organization inertia and unwillingness to change entrenched processes

• Hidden costs of standardization (e.g., maintaining canonical models)

The fear of diseconomies of scale is the root cause of indecision about centralization/decentralization. ICC management must organize and guard against factors that drive diseconomies.

Change Is the Enemy of Operations

Business groups and IT groups have fundamentally conflicting objectives; whereas business is focused on the immediate competitive advantage, IT (especially the operations function) is focused on stability and “keeping the lights on.” The business demands investments to drive innovation, which in turn drives change. To the IT group, change is the enemy of stability and is a problem to be controlled in order to safeguard daily operations.

The ICC has to be flexible enough not just to accommodate change but also to welcome it when an opportunity arises to improve operations. Indeed, the ideal position for a growing and dynamic organization is at “the edge of chaos”—maintaining control while in a state of constant rapid change. ICCs generally serve both constituents: business units that are driving investments in innovation, and operational units that are striving for stability. It is for this reason that ICC capabilities such as metadata repositories, architecture models, and configuration management databases are so critical. These capabilities provide the foundation for processes that support the effective management of change while controlling risks.

Inability to Communicate Value to Stakeholders

The value of a strategic investment such as an ICC needs to be communicated to the stakeholders (IT and/or business) so that they understand and appreciate it. IT personnel encounter a number of difficulties in communicating value to business leaders:

• The use of technical language that business people don’t understand

• Inconsistent language across various lines of business (LOBs), making it hard for IT staff to understand business terminology

• The tendency of IT staff to describe their activities and how work is done rather than focus on the outcomes (what) and the benefits (why)

• The difficulty of translating “soft” benefits such as future flexibility of a given design into “hard,” quantifiable business benefits

The inability to communicate IT value to business stakeholders is the root cause of reduced IT credibility. These communication difficulties are compounded by the use of synonyms and homonyms across the business and IT worlds. Different labels may be used for the same concept; and even more confusing, the same label may be used for quite different concepts.

Given that IT is delivering a service to the business, the onus is generally on ICC personnel to learn the business terminology.

Difficulty in Obtaining “Good” Data

The absence of data for metrics and quantified value propositions is the reason many proposals fail to secure approval. Yet such data is difficult to acquire for a number of reasons:

• Data may simply not be captured (e.g., the amount of time call center staff spends resolving customer data quality problems).

• Data may be captured inconsistently in different organizational groups (e.g., group A does staff time reporting by project phase but group B does it by staff activity).

• The data is not well defined and the people (or person) who know how to interpret it are too busy with other activities (e.g., the project manager who understands and could explain the staff time reports is totally consumed with getting the project completed).

• The owners of the data may be unwilling to share their information because it could be embarrassing or shine a light on some issues that they don’t want highlighted.

There is no easy solution to the problem of acquiring the data that establishes the case for a Lean investment, and yet a full review of the available data is a prerequisite of the proposal. This should include metrics from the development and operation of existing integration applications. The key issue with metrics in demonstrating value to stakeholders is not their volume but their quality. “Low-level” measurable metrics (often activity-based) need to be aggregated to the more compelling outcome-based metrics.

Mismatch of Budget Horizon and Project Life Cycle

Many organizations establish their project investment portfolio on an annual basis and have little (or no) portfolio for multiyear initiatives; it is difficult to obtain funding for projects (or programs) that cut across budget-year boundaries or require several years to complete since they fall outside the “normal” project governance process.

Moreover, since corporate priorities and market pressures commonly shift from year to year, the original business case may no longer be relevant or compelling.

The mismatch of budget horizon and project cycle is the root cause of the project portfolio being focused on tactical short-term solutions that leave the tough problems unresolved. These are precisely the kinds of problems that a strategic resource such as a Lean practice is designed to address.

Organizational Support Diffusion

By definition, shared infrastructure programs require stable and broad-based organizational support. In the dynamic working conditions of the modern enterprise, this is difficult to secure.

For example, let’s look at a typical integration initiative that requires ten teams (functional groups or application teams) to work together for one year. There are typically three levels of stakeholders on each team: area director, team manager, and front-line staff. Below the director level, often more than one individual is involved. Assuming that each of the ten teams has on average 5 people (a total of 50), after 12 months of promotions, transfers, and general churn, very few of the 50 will be in the same role. So there may well be few remaining in the core group who actually understand the need for the ICC and are prepared to support it.

Despite organizational changes, a Lean team must be able to build cross-functional support and sustain it indefinitely.

Activities

The financial management competency includes the following key activities:

1. Developing business case justifications for investments in the integration infrastructure of an organization and in the ICC itself. These efforts may be infrequent or relatively small in the case of incremental quick wins, or they may represent a major campaign in the case of a “making the wave” business case style. In any event, these efforts are periodic and don’t follow a fixed schedule or pattern. Refer to the next section of this chapter on Business Case Development for additional details.

2. Determining the chargeback accounting model both for ongoing main-tenance/operations services the ICC provides to the enterprise and for project-based services. The choice of models available is often constrained by the internal accounting practices and policies of the financial organization. Nonetheless it is absolutely critical that the ICC director make it a top priority to

a. Learn how the financial systems and processes in the organization operate

b. Understand how organizational and individual behavior is influenced by the accounting practices

c. Develop techniques to compensate for the negative effects of the chargeback model

d. Challenge the status quo and encourage changes to the internal accounting controls

3. Establishing key metrics and reporting for an ongoing campaign to build and sustain broad-based management awareness of and support for the ICC. These metrics should definitely include financial ones, but they may also include other key economic indicators such as internal customer satisfaction, process improvement activities, and other quality and efficiency metrics.

Business Case Development

Establishing an ICC or shared infrastructure takes money, resources, and management attention. While most enterprises have requirements and defined standards for business case documents to justify projects that involve a financial expenditure or significant organizational change, integration initiatives present unique challenges that are associated with multifunctional cross-organizational initiatives.

Most IT personnel are quite capable of articulating the technical case for the degree of centralization that the ICC, standard technology, or shared integration system represents, but proving the business case is likely to be more challenging. As the technical case alone is unlikely to secure the required funding, it is important to identify the departments and individuals that are likely to benefit directly and indirectly from the implementation of the integration strategy.

These ideas provide a systematic approach to researching, documenting, and presenting the business justification for these sorts of complex integration initiatives.

The process to establish a business case for an ICC or shared infrastructure such as an enterprise data warehouse, ETL (extract, transform, load) hub, enterprise service bus (ESB), or data governance program (to name just a few) is fundamentally an exercise in analysis and persuasion. This process is demonstrated graphically in Figure 11.2.

Figure 11.2 Business case development steps

Step 1: Clarify the Business Need

Integration investments should be part of a business strategy that must, in turn, be part of the overall corporate strategy. Mismatched IT investments will only move the organization in the wrong direction more quickly. Consequently, an investment in integration should (depending on the enterprise requirements) be based on requirements such as

• Improved data quality

• Reduction of future integration costs

• Reduction of system architecture complexity

• Increase in implementation speed for new systems

• Reduction of corporate costs

• Support for business priorities

The first step in the business case process, therefore, is to state the integration problem in such a way as to clearly define the circumstances leading to the consideration of the investment. This step is important because it identifies both the questions to be resolved by the analysis and the boundaries of the investigation. The problem statement identifies the need to be satisfied, the problem to be solved, or the opportunity to be exploited. The problem statement should address

• The corporate and program goals and other objectives affected by the proposed investment

• A description of the problem, need, or opportunity

• A general indication of the range of possible actions

Although the immediate concern may be to fulfill the needs of a specific integration opportunity, you must, nevertheless, consider the overall corporate goals. A business solution that does not take into account corporate priorities and business strategies may never deliver its expected benefits because of unanticipated changes within the organization or its processes.

There is a significant danger associated with unverified assumptions that can derail business case development at the outset of the process. It is imperative to be precise about the business need that the integration solution is designed to address; abandon preconceptions and get to the core of the requirements. Do not assume that the perceived benefits of a centralized service such as an ICC are so obvious that they do not need to be specifically stated.

In summary, key activities in step 1 include these:

• Define and agree on the problem, opportunity, or goals that will guide the development of the business case.

• Use brainstorming techniques to envision how you would describe the business need in a compelling way.

• Start with the end in mind based on what you know.

• Prepare a plan to gather the data and facts needed to justify the vision.

• Understand the organization’s financial accounting methods and business case development standards.

• Understand the enterprise funding approval governance processes.

Note: It is important to review the core assumptions as the business case evolves and new information becomes available.

The key output from step 1 is a notional problem statement (with placeholders or “guesses” for key measures) and several graphical sketches representing a clearly defined problem/needs statement described in business terms. The MBF technique (see Appendix A) provides a template showing the basic structure of a problem statement with supporting facts and proposed resolution that can be summarized on a single PowerPoint slide. While the basic structure should be defined in step 1, the supporting details and action plans will emerge from the subsequent analysis steps.

Step 2: Identify Options and Define the Approach

The way in which you describe solutions or opportunities is likely to shape the analysis that follows. Do not focus on specific technologies, products, or methods, as this may exclude other options that might produce the same benefits but at a lower cost or with increased benefits for the same cost. Instead, try to identify all of the possible ways in which the organization can meet the business objectives described in the problem statement. This way, the options that are developed and analyzed will have a clear relationship to the organization’s needs. Unless this relationship is clear, you may be accused of investing in technology for technology’s sake.

Available options must include the base case, as well as a range of other potential solutions. The base case should show how an organization would perform if it did not pursue the integration investment proposal or otherwise change its method of operation. It is important to highlight any alternative solutions to the integration investment.

A description of what is meant by doing nothing is required here. It is not adequate to state the base case simply as the continuation of the current situation. It must account for future developments over a period long enough to serve as a basis of comparison for the proposed alternative solution. For example, an organization that keeps an aging integration technique may face increasing maintenance costs as the system gets older and the integrations become more complex. There may be more frequent system failures and changes causing longer periods of downtime. Maintenance costs may become prohibitive, service delays intolerable, or workloads unmanageable. Alternatively, demand for a business unit’s services may ultimately decrease, permitting a reduction of costs without the need for an integration investment.

Be sure to examine all the options in both the short and long term:

• Short term: The document should highlight the immediate effect of doing nothing. For example, your competitors may already have implemented systems such as a customer integration hub or a data quality program and are able to offer more competitive services. Thus, the enterprise may already be losing market share because of its inability to change and react to market conditions. If there is significant market share loss, it should be presented in a way that emphasizes the need for something to be done.

• Long term: The base case should predict the long-term costs and benefits of maintaining the current method of operation, taking into account the known external pressures for change, such as predicted changes in demand for services, budgets, and staffing or business direction.

Problems can be solved in different ways and to different extents. In some cases, options are available that concentrate on making optimum use of existing systems or on altering current procedures. These options may require little or no new investment and should be considered.

A full-scale analysis of all options is neither achievable nor necessary. A screening process is the best way to ensure that the analysis proceeds with only the most promising options. Screening allows a wide range of initial options to be considered, while keeping the level of effort reasonable. Establishing a process for screening options has the added advantage of setting out in an evaluation framework the reasons for selecting, as well as rejecting, particular options.

Options should be ruled out as soon as it becomes clear that other choices are superior from a cost/benefit perspective. A comparative cost/benefit framework should quickly identify the key features likely to make a difference among options. Grouping options with similar key features can help identify differences associated with cost disadvantages or benefit advantages that would persist even if the options were subjected to more rigorous analysis.

Options may be ruled out on the basis that their success depends too heavily on unproven technology or that they just will not work. Take care not to confuse options that will not work with options that are merely less desirable. Options that are simply undesirable will drop out when you begin to measure the costs and benefits.

The objective is to subject options to an increasingly rigorous analysis. A good rule of thumb is that when in doubt about the economic merits of a particular option, the analyst should retain it for subsequent, more detailed rounds of estimation.

To secure funds in support of ICC infrastructure investments, a number of broad-based strategies and detailed methods can be used. The following are five primary strategies that address many of the funding challenges:

1. Recurring quick wins: This strategy involves making a series of small incremental investments as separate projects, each of which provides demonstrable evidence of progress. This strategy works best when the work can be segmented into small steps.

2. React to a crisis: While it may not be possible to predict when a crisis will occur, experienced integration staff are often able to see a pattern and anticipate in what areas a crisis is likely to emerge. By way of analogy, it may not be easy to predict when the next earthquake will occur, but we can be quite accurate about predicting where it is likely to occur based on past patterns. The advantage that can be leveraged in a crisis situation is that senior management attention is clearly focused on solving the problem. A challenge, however, is that there is often a tendency to solve the problem quickly, which may not allow sufficient time for a business case that addresses the underlying structural issues and root causes of the problem. This strategy therefore requires that the ICC team perform some advance work, be prepared with a rough investment proposal for addressing structural issues, and be ready to quickly present it when the opportunity arises.

3. Executive vision: This strategy relies on ownership being driven by a top-level executive (e.g., CEO, CFO, CIO, VP, etc.) who has control over a certain amount of discretionary funding. In this scenario, a business case may not be required because the investment is being driven by a belief in core principles and a top-down vision. This is often the path of least resistance if you have the good fortune to have an executive with a vision that aligns with the Lean charter/mission. The downside is that if the executive leaves the organization or is promoted into another role, the momentum and any associated investment may fade away if sufficient cross-functional support has not been developed.

4. Ride on a wave: This strategy involves tying the infrastructure investment to a large project with definite ROI and implementing the foundational elements to serve future projects and the enterprise overall rather than just the large project’s needs. Examples include purchasing the hardware and software for an enterprise integration hub in conjunction with a corporate merger/acquisition program, or building an enterprise hub as part of a large ERP system implementation. This strategy may make it easier to secure the funds for an infrastructure that is hard to justify on its own merits, but it has the risk of becoming too project-specific and not as reusable by the rest of the enterprise.

5. Create the wave: This strategy involves developing a clear business case with defined benefits and a revenue/cost-sharing model to which all stakeholders who will use the shared infrastructure agree in advance. This is one of the most difficult strategies to execute because it requires a substantial up-front investment in building the business case and gaining broad-based organizational support. But it can also be one of the most rewarding because all the hard work to build support and address the “political” issues is done early.

In summary, the activities in step 2 for identifying the options and developing the approach are these:

1. Assemble the evaluation team:

a. Include a mix of resources if possible, including some change agents and change resisters.

b. Use internal resources who “know their way around” the organization.

c. Use external resources to ask the naive questions and sidestep internal politics.

d. Prepare for evaluation, including understanding the organizational financial standards and internal accounting methods.

2. Define the options and a framework for structuring the investment decision:

a. Identify the options (including the baseline “status quo” option).

b. Screen the options based on short-term and long-term effects.

3. Determine the business case style.

The key deliverables resulting from step 2 are a list of options and a rough idea of the answers to the following questions for each of them:

• How does the solution relate to the enterprise objectives and priorities?

• What overall program performance results will the option achieve? What may happen if the option is not selected?

• What additional outcomes or benefits may ensue if this option is selected?

• Who are the stakeholders? What are their interests and responsibilities? What effect does the option have on them?

• What are the implications for the organization’s human resources?

• What are the projected improvements in timeliness, productivity, cost savings, cost avoidance, quality, and service?

• How much will it cost to implement the integration solution?

• Does the solution involve the innovative use of technology? If so, what risks does that involve?

Step 3: Determine the Costs

It is necessary to define the costs associated with options that will influence the investment decision. Be sure to consider all the cost dimensions, which we describe here.

Fixed versus Variable and Direct versus Indirect Costs

The fixed costs are the costs that do not vary with the number of integration interfaces that are to be built. They can be costs that are incurred over a period of time but can be envisaged as one number at the end of that period. Examples are buildings, servers, and management overhead. Fixed costs typically do not change as the volume of output increases, although they may change in a step function such as when the building or server is fully utilized and another needs to be secured.

Variable costs are material and process costs that change with the volume of goods or services produced. In other words, each incremental unit output generates an incremental cost.

Direct costs are those that are unequivocally related to production outputs. For example, the cost of staff labor to program an interface is a direct cost. Indirect costs, on the other hand, may be considered fixed overhead costs or may be combined with direct costs on an allocation basis. For example, the cost of a desk and work space for a software developer may (based on the accounting policies of the enterprise) be considered as corporate overhead or may be added to staff labor costs along with other allocations, resulting in a “fully loaded” cost per hour.

Internal versus External Costs

External costs are sometimes referred to as “out of pocket” costs since they involve a direct expenditure of money, such as the purchase of a software license or hiring a consultant. Internal costs are generally for resources that have already been paid for and are being consumed by the investment project, such as using a server or software license that was purchased independently of the project or using employees to perform the work. It is usually easier to justify investment in a project that has primarily internal costs, unless the organization is severely resource-constrained, in which case it may be easier to obtain funding for incremental external resources.

Capital versus Operating Costs

Most enterprises have separate capital and operating budgets, as well as different governance processes for the two categories. Our recommendation is to keep both sources of funds in mind when preparing investment business cases and to develop a deep understanding of your enterprise processes and policies.

Aside from the formal processes, you should also seek to understand the informal processes and cultural dynamics. For example, in some organizations it is relatively easy to obtain approval for discretionary operating funds early in the fiscal year but it becomes increasingly difficult as the year progresses. Conversely, the same organization may maintain very stringent criteria for capital expenditures early in the fiscal year and ease up on constraints late in the year if the entire budget has not been consumed.

One-Time Costs versus Ongoing Costs

Up-front costs are the initial project development and implementation expenses. These can be substantial and should be carefully assessed. Fortunately, these costs are generally well documented and easily determined, except for projects that involve new technology or software applications. The main categories of one-time direct/fixed costs are

• Hardware and peripherals

• Packaged and customized software

• Initial data collection or conversion of archival data

• Data quality analysis and profiling

• Facilities upgrades, including site preparation and renovation

• Design and implementation

• Testing and prototyping

• Documentation

• Additional staffing requirements

• Initial user training

• Transition, such as costs of running parallel systems

• Quality assurance and post-implementation reviews

Ongoing costs are the expenses that occur over the life cycle of the investment. The costs to operate a facility, as well as to develop or implement an option, must be identified. The main categories of direct ongoing costs are

• Salaries for staff

• Software licenses, maintenance, and upgrades

• Computing equipment and maintenance

• User support

• Ongoing training

• Reviews and audits

Not all of these categories are included in every data integration implementation. It is important to pick the costs that reflect your implementation accurately.

The primary output from step 3 is a financial model (typically a spreadsheet) around the options with different views according to the interests of the main stakeholders.

Step 4: Define the Benefits

This step identifies and quantifies the potential benefits of a proposed integration investment. Both quantitative and qualitative benefits should be defined. Determine how improvements in productivity and service are defined as well as the methods for realizing the benefits.

• Identify direct (hard) and indirect (soft) benefits.

• Create a financial model of the benefits.

• Collect industry studies to complement internal analysis.

• Identify anecdotal examples to reinforce facts.

• Define how benefits will be measured.

To structure the evaluation, you will have to clearly identify and quantify the project’s advantages. A structure is required to set a range within which the benefits of an integration implementation can be realized. Conservative, moderate, and optimistic values are used in the attempt to produce a final range, which realistically contains the benefits to the enterprise of an integration project but also reflects the difficulty of assigning precise values to some of the elements:

• Conservative values reflect the highest costs and lowest benefits possible.

• Moderate values reflect those you believe most accurately reflect the true value of the integration implementation.

• Optimistic estimates reflect values that are highly favorable but are also improbable.

Many of the greatest benefits of integration are realized months or even years after the project has been completed. These benefits should be estimated for each of the three to five years following the completion of the project. In order to account for the changing value of money over time, all future pretax costs and benefits are discounted at the internal rate of return.

Direct (Hard) Benefits

The enterprise will immediately notice a few direct benefits from improving data integration in its projects. These are mainly cost savings over traditional point-to-point integration in which interfaces and transformations between applications are hard-coded, and the cost savings the enterprise will realize because of the enhanced efficiency and automation made possible by improved integration approaches, tools, and artifacts. Key considerations include

• Cost savings

• Reduction in complexity

• Reduction in staff training

• Reduction in manual processes

• Incremental revenue linked directly to the project

• Governance and compliance controls that are directly linked

Indirect (Soft) Benefits

The greatest benefits from an integration project usually stem from the extended flexibility the system will have. For this reason, these benefits tend to be longer-term and indirect. Among them are

• Increase in market share

• Decrease in the cost of future application upgrades

• Improved data quality and reporting accuracy

• Decrease in the effort required for integration projects

• Improved quality of work for staff and reduced turnover

• Better management decisions

• Reduced waste and rework

• Ability to adopt a managed service strategy

• Increased scalability and performance

• Improved services to suppliers and customers

• Increase in transaction auditing capabilities

• Decreased time to market for mission-critical projects

• Increased security features

• Improved regulatory compliance

It is possible to turn indirect benefits into direct benefits by performing a detailed analysis and working with finance and management stakeholders to gain support. This may not always be necessary, but often it is essential (especially with a “make the wave” business case style). Since it can take a lot of time and effort to complete this analysis, the recommended best practice is to select only one indirect benefit as the target for a detailed analysis.

Figure 11.3 illustrates an example of a compelling exposition of ICC benefits. Note that the initial cost of integrations developed by the Integration Factory is greater than hand-coding, but after 100 integrations the factory cost is less than custom hand-coded solutions. In this example (which is based on a real-life case), the enterprise developed more than 300 integrations per year, which translated into a savings of $3 million per year.

Figure 11.3 Sample factory business case graph

It is also useful to identify the project beneficiaries and to understand their business roles and project participation. In many cases, the project sponsor can help to identify the beneficiaries and the various departments they represent. This information can then be summarized in an organization chart—a useful reference document that ensures that all project team members understand the corporate/business organization.

Step 5: Analyze the Options

After you have identified the options, the next step is to recommend one. Before selecting an option to recommend, you need to have a good understanding of the organization’s goals, its business processes, and the business requirements that must be satisfied.

To evaluate investment options, select criteria that will allow measurement and comparison. The following list presents some possible analyses, starting with those that involve hard financial returns and progressing to those that are more strategic:

• Analysis of cost effectiveness demonstrates, in financial terms, improvements in performance or in service delivery and shows whether the benefits from the integration investment outweigh its costs.

• Analysis of displaced or avoided costs compares the proposed system’s costs to those of the system it would displace or avoid; it may justify the proposal on a least-cost basis if it can be assumed that the new system will have as many benefits as the current system.

• Work value analysis requires an analysis of work patterns throughout the organization and of ways to readjust the number and types of skills required; it assumes that additional work needs to be done, that management allocates resources efficiently, and that workers allocate time efficiently.

• Cost of quality analysis estimates the savings to be gained by reducing the cost of quality assurance, such as the cost of preventing or repairing a product failure, and can consider savings that are internal and external to the organization, such as the enterprise’s cost to return a product.

• Option value analysis estimates the value of future opportunities that the organization may now pursue because of the project; it uses decision trees and probability analysis and includes savings on future projects, portions of the benefits of future projects, and reductions in the risks associated with future projects.

• Analysis of technical importance justifies an infrastructure investment because a larger project that has already received approval could not proceed without it. This is likely when enterprises initiate integration programs as a consequence of a merger or acquisition and two large ERP systems need to communicate.

• Alignment with business objectives includes the concept of strategic alignment modeling, which is one way to examine the interaction between IT strategy and business strategy, and allows managers to put a value on the direct contribution of an investment to the strategic objectives of the organization.

• Analysis of level-of-service improvements estimates the benefits to enterprises of increases in the quantity, quality, or delivery of services and must be done from the enterprise’s viewpoint.

• Research and development (R&D) is a variant of option value analysis, except that the decision on whether to invest in a large integration project depends on the outcome of a pilot project; this is most useful for high-risk projects, where R&D can assess the likelihood of failure and help managers decide whether to abort the project or better manage its risks. It requires that management accept the consequences of failure and that the pilot be a reasonable expense in determining the viability of an integration project.

After you have quantified the costs and benefits, it is essential to conduct a cost/benefit analysis of the various options. Showing the incremental benefits of each option relative to the base case requires less analysis, since the analyst does not have to evaluate the benefits and costs of an entire program or service. Some benefits may not be quantifiable. Nevertheless, these benefits should be included in the analysis, along with the benefits to individuals within and external to the organization. You have to look at the project from two perspectives: the organization’s perspective as the supplier of products and services, and the enterprise’s or public’s perspective as the consumer of those services.

Hard cost savings come from dedicated resources (people and equipment), while more uncertain savings come from allocated costs such as overhead and workload. When estimating cost avoidance, keep these two types of savings separate. Assess how likely it is that the organization will realize savings from allocated resources, and estimate how long it will take to realize these savings.

Step 6: Evaluate Risks

Step 6 presents ways to help identify and evaluate the risks that an integration investment may face so that they can be included in the business case. It also includes how to plan to control or minimize the risk associated with implementing a data integration investment.

The purpose of risk assessment and management is to determine and resolve threats to the successful achievement of investment objectives and especially to the benefits identified in the business case. The assessment and management of risk are ongoing processes that continue throughout the duration of an integration implementation and are used to make decisions about the project implementation. The first decision about an integration investment option is whether to proceed. The better the risks are understood and planned for when this decision is made, the more reliable the decision and the better the chances of success.

The method underlying most risk assessment and management approaches can be summarized by the following five-step process:

1. Identify the risks facing the project.

2. Characterize the risks in terms of impact, likelihood of occurrence, and interdependence.

3. Prioritize the risks to determine which need the most immediate attention.

4. Devise an approach to assume, avoid, or control the risks.

5. Monitor the risks.

All but the last of these can and should be undertaken as part of the business case analysis conducted prior to the decision to proceed.

Not all risks are created equal. For each risk identified, characterize the degree of risk in terms of

• Its impact on the project (e.g., slight delay or showstopper)

• The probability of its occurrence (e.g., from very unlikely to very likely)

• Its relationship to other risks (e.g., poor data quality can lead to problems with integrating data)

Once the risks have been identified and characterized, they can be ranked in order of priority to determine which should be tackled first. Priority should be based on a combination of an event’s impact, likelihood, and interdependence—for example, risks that have a severe impact and are very likely to occur. Therefore, they should be dealt with first to avoid having to deal with additional risks.

You can assign priorities to risk factors by assigning a weight to each risk for each of the three characteristics (impact, likelihood, and interdependence) and multiplying the three values to create a composite score. The risk with the highest score gets the highest priority. A general rule of thumb is to develop a risk mitigation plan only for the top five risks based on the rationale that there is no point in focusing on lower-priority risks if the major ones aren’t addressed, and because of limited management attention it is not feasible to tackle too many at once. After you have mitigated some of the highest-priority risks, reevaluate the list on an ongoing basis and focus again on the top five.

Do not avoid or hide risks. The credibility of the business case will be enhanced by clearly identifying risks and developing a mitigation strategy to address them. Three main types of risks arise in IT projects:

1. Lack of control: Risks of this type arise from a project team’s lack of control over the probability of occurrence of an event and/or its consequences. For example, the risks related to senior managers’ decisions are often a result of the lack of control a project team has over senior managers.

2. Lack of information: Risks of this type arise from a project team’s lack of information regarding the probability of occurrence of an event or its consequences. For example, risks related to the use of new technologies are often the result of a lack of information about the potential or performance of these technologies.

3. Lack of time: Risks of this type arise from a project team’s inability to find the time to identify the risks associated with the project or a given course of action, or to assess the probability of occurrence of an event or the impact of its consequences.

There are three main types of responses to risk in data integration projects, and they are listed in ascending order of their potential to reduce risk:

1. Assume: A department accepts the risk and does not take action to prevent an event’s occurrence or to mitigate its impact.

2. Control: A department takes no action to reduce the probability of occurrence of an event but upon its occurrence attempts to mitigate its impact.

3. Avoid: A department takes action prior to the occurrence of an event in order either to reduce its probability of occurrence or to mitigate its impact.

Selection of a type of response depends on the priority assigned to a risk, its nature (i.e., whether it is amenable to control or avoidance), and the resources available to the project. In general, the higher the priority of a risk, the more vigorous the type of response applied.

Step 7: Package the Case

Assemble the business case documentation and package it for consumption by the targeted stakeholders. Key activities in this step include the following:

• Identify the audience.

• Prepare the contents of the report.

• Package the case in different formats to make a compelling and engaging presentation, using

• Descriptive graphics

• Animation or simulation of process or data quality issues

• Case studies and anecdotes

• Comparative financial data

• Customer testimonials

Step 8: Present the Case

The best analysis and documentation will be useless unless the decision makers buy in and give the necessary approvals. Step 8 provides suggestions to help ensure that your recommendations get a fair hearing. Use both formal and informal methods to present the proposal successfully. Key activities in this step include these:

• Find the right sponsor(s).

• Leverage individual and group presentations.

• Promote the proposal and obtain cross-functional buy-in.

• Model, pilot, and test-market the proposed solution.

Find a sponsor who can galvanize support for the business case, as well as for the subsequent implementation. The sponsor should be a person in a senior management position. Avoid starting a project without a sponsor.

The investment proposal will compete for the attention of decision makers and the organization as a whole. This attention is crucial, and information can be a vital element in helping enterprises to lobby the project decision makers throughout the life cycle of the decision process. Consequently, the proposal itself must be promoted, marketed, and sold. Market your proposal with an eye toward the enterprise culture and the target audience. Word of mouth is an important, but often overlooked, way of delivering limited information to a finite group.

A business case must convince decision makers that the analysis, conclusions, and recommendations are valid. To make this happen, use theoretical or practical models, pilot projects, and test marketing. Remember, seeing is believing, and a demonstration is worth a thousand pictures.

Furthermore, the model or pilot allows the assessment of any ongoing changes to the environment or to the assumptions. One can then answer the “what-if” scenarios that inevitably surface during the decision-making process. At the same time, there is a basis for reassessment and revision in the investments.

Step 9: Review the Results

Step 9 outlines a process for conducting ongoing reviews during the life cycle of the data integration project. Be realistic in your assessment of the feedback from the preceding stage. Whatever the difficulties encountered in the decision-making process, follow up after the decision to review the ongoing validity of the investment and reinforce support.

Reviews help to verify that the IT investment decision remains valid, and that all costs and benefits resulting from that decision are understood, controlled, and realized. The investment analysis contained in the business case defines the goals of the implementation project and serves as a standard against which to measure the project’s prospects for success at review time.

The following types of reviews can be conducted:

• Independent reviews: These are conducted by an independent party at major checkpoints to identify environmental changes, overrun of time and cost targets, or other problems.

• Internal peer reviews: The objectives of the peer review are to verify that the project is still on course and to provide expert advice, counsel, and assistance to the project manager. In this way, the combined skills and experience of internal staff are applied to the project.

• External peer reviews: ICCs may also draw upon similar people in other departments or organizations to provide a different perspective and to bring a wide range of expertise to bear on project strategies, plans, and issues.

• Project team sanity checks: Another source of early warning for project problems is the project team members. These people are the most intimately aware of difficulties or planned activities that may pose particular challenges.

• Oversight reviews: These reviews, under a senior steering committee, should be planned to take place at each checkpoint to reconfirm that the project is aligned with ICC priorities and directions and to advise senior management on project progress.

• Investment reviews: The enterprise auditor can also review the performance of projects and, upon completion, the performance of the investment. At an investment review, the auditor reviews and verifies the effect of the investment to ascertain that the investment was justified.

The reviews should start as soon as money is spent on the investment. Major project reviews should be scheduled to coincide with the release of funds allocated to the project. In this approach, the project sponsor releases only the funds needed to reach the next scheduled review. The performance of the project is reviewed at each scheduled checkpoint or when the released funds run out. After review, departmental management can decide to proceed with the project as planned, modify the project or its funding, or even terminate the project, limiting the loss to the amount previously released.

Investment reviews can be scheduled to coincide with project reviews during investment implementation:

• The first investment review should be conducted no later than the midpoint of the project schedule, when the deliverables are under development.

• The second should be conducted after the end of the implementation project, when the deliverables have just started to be used in production.

• A final review should be conducted after the investment has been in production for between six months and a year.

• The exact dates for these reviews should ideally be determined by the timing of the investment deliverables. This timing should be clearly indicated in the investment plan.

The approved investment analysis should form the basis for criteria used in all reviews. The project schedule of deliverables, based on the investment analysis, establishes the timing criteria for project reviews.

After each review, the sponsor should say whether the investment will stop or continue. An investment may be stopped, even temporarily, for any of the following reasons:

• There is no agreement on how to conduct the review.

• The review shows that most of the expected results were not achieved.

• There were changes to the approved investment analysis, and it is not clear that the enterprise was made aware of the full implications of the changes.

• Changes to the approved investment analysis were accepted, but there is no additional funding for the changes or the enterprise has not accepted the new risks.

For the final investment review, the enterprise should demonstrate to the auditor that the investment achieved the expected results, and the auditor should report on the investment’s level of success.

Chargeback Accounting

The ICC operates within a larger organization that needs to make periodic decisions about its priorities for allocating limited resources. In this context, an ICC needs not only to secure initial funding but also to demonstrate that continued investment is justified.

Chargeback accounting, which your accounting department may refer to as transfer pricing, describes the options and process for allocating costs in an ICC to other groups that benefit from its work. One of these options is to dispense with a chargeback mechanism and simply use a centrally funded cost center. Central funding, however, is generally considered to be a non-Lean practice since it disconnects the customer of the ICC from the funding source, which can lead to dysfunctional outcomes such as when the executive responsible for the ICC budget reduces the funding without a clear understanding of the impact on the ICC’s customers. Another example of diseconomies is the supply and demand mismatch that was discussed earlier—having a fixed annual budget (and fixed staff) for a group that supports a variable workload.

Furthermore, there are additional benefits to a systematic approach to chargebacks, not the least of which is the psychological impact on consumers and providers of the service. It also encourages users to understand the internal financial accounting of the organization so that customers and management alike can work within the realm of its constraints and understand how it relates to the culture.

The goal of a Lean Integration practice should always be to implement a chargeback model and ultimately operate as a profit center rather than a cost center (which we also refer to as a self-funding model). This may not always be possible in the early stages of a Lean practice in some enterprises because of existing accounting practices and processes. In that case the ICC team needs to do two things: implement compensating processes to work around the limitations of a central funding model and avoid as many of the dysfunctional behaviors as possible, and mount a campaign to understand, and eventually change, the corporate accounting practices to support a chargeback model.

The campaign to change the accounting practices in an organization may take years, but nonetheless it is essential to pursue it. Stenzel, in Lean Accounting, provides some useful advice in this regard: “In order for accountants to fully participate in the lean process, they also need to adopt five lean accountant behaviors: (1) enable process ownership, (2) think sustainable growth first, (3) adopt a long-term view, (4) become a business partner to nonfinancial employees, and (5) adopt the enterprise view of lean.”²

2. Ibid., Kindle Loc. 2577–79.

Economic Framework

As shown in Figure 11.5, the horizontal dimension of the economic framework is the investment category with strategic demands at one end of the spectrum and tactical demands at the other end. Strategic demands typically involve projects that drive business transformations or process changes and usually have a well-defined business case. Tactical demands are associated with day-to-day operations or keeping the lights on. In the middle of the spectrum, some organizations have an additional category for “infrastructure investments”—that is, project-based funding, focused on technology refresh or mandatory compliance-related initiatives. These are projects that are generally considered nondiscretionary and hence appear to be maintenance.

Figure 11.5 Economic framework

The vertical dimension is the funding source and refers to who pays for the services: the consumer or the provider. In a free-market economy, money is exchanged for products or services. For internal shared-services organizations, rather than exchanging real money, accounting procedures are used to move costs between accounting units. Transferring costs from an internal service provider to the consumer of the service is generally referred to as a chargeback.

If we lay these two dimensions out along the x- and y-axes with a dividing line in the middle, we end up with these four quadrants:

1. Demand-based sourcing: This operating model responds to enterprise needs by scaling its delivery resource in response to fluctuating project demands. It seeks to recover all costs through internal accounting allocations to the projects it supports. The general premise is that the ICC can drive down costs and increase value by modeling itself after external service providers and operating as a competitive entity.

2. Usage-based chargeback: This operating model is similar to the demand-based sourcing model but generally focuses on providing services for ongoing IT operations rather than project work. Once again, the ICC in this model operates like a stand-alone business that is consumer-centric, market-driven, and constantly improving its processes to remain competitive. While the demand-based sourcing model may have a project-based pricing approach, the usage-based model uses utility-based pricing schemes.

3. Enterprise cost center: Typically, this operating model is a centrally funded function. This model views the ICC as a relatively stable support function with predictable costs and limited opportunities for process improvements.

4. Capacity-based sourcing: This operating model strives to support investment projects using a centrally funded project support function. Centrally funded ICCs that support projects are excellent models for implementing practices or changes that project teams may resist. Not charging project teams for central services is one way to encourage their use. The challenge with this model is to staff the group with adequate resources to handle peak workloads and to have enough non-project work to keep the staff busy during nonpeak periods.

In general, the ICCs that are funded by consumers and are more strategic in nature rely on usage-based chargeback mechanisms. ICCs that are provider-funded and tactical rely on capacity-based sourcing or cost center models.

Chargeback Models

The kind of chargeback model that is appropriate varies according to two factors: what costs you want to charge and in what context, and the organizational and individual behavior that you want to influence. This section focuses on specific recommendations related to the most common and recommended patterns.

Figure 11.6 shows six of the most common chargeback models and a typical application for each of them.

Figure 11.6 Chargeback models

For example, the tiered flat rate model is recommended for charging individual projects or business units for their use of a portion of an enterprise license. Here is a scenario for how it could work: Let’s say that the cost of a software license is $100,000 per server and that many projects that are part of an enterprise program could use the same software. A small project may use only a small fraction of the server, but since the license can be purchased from the vendor only in per-server increments, even a small project must pay $100,000. A medium-sized project needs the capacity of an entire server for itself, which would cost $100,000, and a large project might need three servers for a total of $300,000. The overall program will encompass six small projects, four medium, and two large. If each project purchased the license directly from the vendor, the total cost would be $1.6 million, as shown in Table 11.4.

Table 11.4 Project-Based Direct Purchase

An alternative approach is for the ICC to purchase an enterprise license and recover the costs through internal accounting transfers. Software vendors are motivated to sell enterprise licenses at a discount since doing so reduces their cost of sales and results in a larger up-front sale. In this scenario, we will assume that the enterprise license costs $1 million. Using our projected number of projects, we could allocate the cost of the license using a tiered flat rate: $50,000 for a small project, $80,000 for a medium project, and $200,000 for a large project, as shown in Table 11.5. Note that in this scenario, all projects pay less than they would have individually (which by itself is an incentive to use the standard software).

Table 11.5 Tiered Flat Rate Chargeback for Enterprise License Scenario

Note also that the total recovered cost is $20,000 greater than the purchase price of $1 million, which has some positive and negative aspects to it. The ICC may be able to use this $20,000 to fund other activities or to help pay for overhead costs. On the other hand, the $20,000 difference between the purchase price and the chargeback allocations may require a more complicated set of accounting transactions to ensure that all the accounts balance.

Service-Based and Fixed-Price Chargeback

These are the most sophisticated of the chargeback models and require that the ICC clearly define its service offerings and structure a pricing model based on defined service levels. Service-based pricing is used for ongoing service, whereas fixed pricing is used for incremental investment projects. In other words, both of them offer a fixed price for a defined service. This model is most suitable for a mature ICC that has well-defined service offerings and a good cost-estimating model.

Tiered Flat Rate Chargeback

The tiered flat rate is sometimes called a “utility pricing” model. In this model, the consumer pays a flat rate per unit of service, but the flat rate may vary based on the total number of units or some other measure. This model is based on the assumption that there are economies of scale associated with volume of usage and therefore the price should vary based on it.

Resource Usage Chargeback

In this model the “client” pays according to resource usage. Resources may be in one or more categories such as number of records processed, data volume transmitted, or CPU time used by the integration hub. Integration technology can support the collection of metrics for these and other types of resource usage.

Direct Cost Chargeback

Here the “client” pays the direct costs associated with a request that may include incrementally purchased hardware or software as well as a cost per hour or per day for developers or analysts. The development group provides an estimate (with assumptions) of the cost to deliver based on its understanding of the client’s requirements.

Cost Allocation Chargeback

Costs can also be allocated on a more or less arbitrary basis irrespective of any actual resource usage. This method is typically used for ongoing operating costs but may also be used for project work. The general presumption with this method is that most IT costs are either fixed or shared and therefore should simply be “allocated” or spread across the various groups that use the services.

Organizational Behavior

In addition to the appropriate application or use of each of the six chargeback models, a second dimension is the organizational behavior that is influenced by the various models. Each of the chargeback models has a unique profile of simplicity, fairness, predictability, and controllability as perceived by the customers of the ICC and by other stakeholders. For example, the cost allocation model is perceived to be the simplest to administer (and hence may be the easiest for the accounting department to support), but it provides little useful information to management or the customer. Allocations are also perceived to have low integrity since, from a customer’s perspective, the costs are not predictable (they may increase or decrease based on how the resource is shared by other groups), transparent (it is often hard to pinpoint exactly what costs are included in the allocation), or controllable (the customer has limited or no ability to impact the shared allocations).

The value of these organizational behavior aspects is reinforced by Stenzel in Lean Accounting: “Traditional accounting is compelled to allocate 100 percent of occupancy costs to products. Lean accounting allocates only the costs associated with the space utilized by enterprise value streams. This process highlights two key benefits. First, the value stream is motivated to continually reduce their footprint, including any idle inventory storage. Second, the space and the cost of unutilized resources are made visible to decision makers whose task it becomes to grow the business—either increase sales or develop new markets.”³

3. Ibid., Kindle Loc. 2528–32.

For many of the reasons noted earlier, it is particularly important that the ICC be able to influence organizational silos and change organizational behavior. These objectives can include gaining support from silos to suboptimize their operations in the interests of the enterprise, or convincing groups to rely on a shared service rather than to do the work themselves. This is not easy but can be accomplished with an appropriate strategy. The most successful campaigns are sustained on three fronts: economic incentives, social pressures, and moral values. Here are some of the actions that an ICC can take along these three dimensions:

1. Economic incentives include the following recommendations or best practices:

a. Optimize the delivery of services to be fast, inexpensive, and high-quality. For example, if you want everyone to use a common software solution rather than each group building or buying its own, make the common solution so cheap, fast, and good that there is no economic motivation to deviate.

b. Make it easy for people to conform to standards. For example, if you want everyone to follow a certain data security standard, rather than publishing a large standards document that requires everyone to read, interpret, and design his or her own solution, simply offer a ready-to-deploy software solution that has the security standards embedded into it. Although it generally requires some investment to make difficult concepts “easy,” the results in terms of acceptance are well worth the effort.

c. Offer financial subsidies to encourage behavior changes. For example, if a company is growing and needs a new building, don’t charge the first group that moves into one floor of the building the cost of the entire building; instead, carry the cost of the empty floors in a central cost center so that there isn’t an economic barrier to acceptance by the silos. As obvious as this is, in the IT arena it is often common practice to charge the full infrastructure cost of a new corporate direction to the first project that intends to use it.

d. Charge a risk reserve or operational premium for nonstandard solutions. For example, rather than mandate that everyone in the company use a certain database vendor, you could structure an IT pricing method that adds a project charge or operational charge for business units that choose to deviate.

2. Social pressure can also encourage compliance and collaboration. In some organizational cultures, these techniques can be more powerful than economic incentives:

a. Empower staff to escalate issues concerning nonconformance. This could include providing coverage for front-line staff who need to maintain a strong working relationship with business partners. For example, to encourage collaboration you could have a federated enterprise architecture function with some architects reporting in a solid-line relationship to business units. When one of these architects needs to take a position on an issue that will be unpopular with the business unit, have the central arm of the enterprise architecture function play the “bad cop” governance role.

b. Empower staff by making information available. For example, if you want to reduce the number of duplicate or redundant technologies or applications, shine a light on the problem by documenting and broadly communicating the portfolio.

c. Ensure that the defined standards with which you want everyone to comply are in fact endorsed and communicated by a cross-functional management team.

d. Measure conformance to desired standards by producing periodic reports that are public and visible. The groups or individuals that are not performing will be embarrassed by their peers for being out of compliance, which can be a powerful incentive.

e. Reward compliance with standards and processes by publishing case studies, highlighting successes at team meetings, and recognizing positive behavior in public forums.

3. Moral values also play an important role in encouraging positive behavior:

a. Encourage a commitment to the “greater good” by clearly communicating the value to the overall organization. Reinforcement messages include “We are all part of the same company; we all succeed or fail together” and “We are all serving the same customer. The customer is king.”

b. Publish integration principles and print them on posters (or mouse pads or coffee cups, for example) to keep them visible.

c. Ensure fairness and an adequate level of transparency in decisions—especially those that may be unpopular. People will be much more supportive of unpopular directives if they are perceived to affect everyone equally.

To facilitate effective communications in support of these nonfinancial incentives, an ICC should consider establishing an internal “marketing” function. The role of internal marketing is to make the appropriate stakeholders within the organization aware of, interested in, and motivated to use the services of the ICC.

In summary, we recommend a hybrid approach of service-based, flat-rate, and measured resource usage methods of charging for services provided to internal clients:

• Direct cost for hardware and software procurement

• Fixed-price service-based for project implementation

• Measured resource usage for operations

• Tiered flat rate for support and maintenance