Why IT governance
Development of your IT governance solution without the full and proper context of your business is likely to result in a solution that is not designed to support the strategic objectives of your business. An IT governance solution that is designed and implemented “within the four walls of IT” is designed to benefit only the IT organization. However, in practical application that same solution may not benefit anyone since it has not considered the entire value chain of the business (customer to customer). Even worse, it will negatively impact the business in ways that may be relatively invisible, across organizational boundaries. The value of your IT governance solution may be compromised at your organizational boundaries. Without proper forethought and management support for building the necessary organizational transparency required to be successful, your attempt to build an effective IT governance solution will fall short of expectations.
Your IT governance solution must be developed as a flexible architecture that is strategically aligned well with your business. This coordination and strategic alignment of various IT governance disciplines is referred to as IT governance solution architecture. It is a core contributor to whether you can adequately exploit and extend the varying capabilities of your business.
– Diversification
– Coordination
– Replication
– Unification
If an operating model helps to define your company’s strategy, and your IT governance solution is an essential ingredient in execution of that strategy, then their alignment is crucial. Furthermore, the operating model for your company is a predictor for your IT governance solution architecture.
For example, if your company’s operating model is one of diversification (low business process integration and standardization), then your IT governance solution for each (quite possibly) independent entity may be relatively isolated from the others. There may be only a subset of applicable (common) regulations, standards, and policies that apply. On the other end of the spectrum, there is the unification operating model (high business process integration and standardization). This type of strategy demands that your business is highly integrated and that sharing of information and resources is a critical component of leverage.
In this type of environment, there may be no opportunity for regulations, standards, and policies to exist in isolation. They must be shared across the whole enterprise in order to realize the strategy.
– The Capability Maturity Model Integrated (CMMI) is a standardized, process improvement approach that provides organizations with the essential elements of effective processes. It can be used to guide process improvement across a project, a division, or an entire organization. It identifies five levels of maturity: initial, managed, defined, quantitatively managed, and optimizing.
– The IT Infrastructure Library (ITIL) is an internationally recognized and constantly evolving collection of IT best practices that are designed to help organizations overcome current and future technology challenges. ITIL is mainly about execution. It addresses controls as part of its activities. IT departments around the world use ITIL as a roadmap to help guide efficient and effective implementation of current technology, including the realization of an IT service management strategy.
– The IT Governance Institute (ITGI) version 4.0 of Control Objectives for Information and related Technology (COBIT) is an IT governance framework and supporting toolset that allows managers to bridge the gaps between control requirements, technical issues, and business risks.
Alignment of business and IT
Your IT governance solution must enable project teams and incent good behavior in a way that benefits your organization from a business perspective, an (internal) IT perspective, and a business and IT alignment perspective (creating business transparency). In Enterprise Architecture as Strategy: Creating a Foundation for Business Execution, Robertson, Ross, and Weill discuss the alignment of business and IT using the term linkage. Your business and IT organizations are linked together at all levels or your organization: the enterprise level, the business unit level, and the project level.
Value factors are business concerns that the governing body has regarding governed projects that operate under a specific governance solution. They do not indicate or prescribe the design of any specific governance process, including milestones, activities, artifacts, or roles. They are not themselves a governance process, nor do they prescribe a set of governance milestones. They assert that the design of an IT governance solution should focus on the reduction of business risk as rapidly as possible (ideally, geometrically).
Relative to the development of your governance solution, value factors should guide your organization to discover the objectives for each of the phases of your governance solution. Value factors define how you enable your governance solution to yield value to your organization throughout the life cycle of your IT governance solution. Value factors are described by the following three desires, realized in order, as you execute projects against your governance solution:
1. Ensure strategic benefit.
The business realizes benefit from the availability of a solution, either directly or indirectly. Direct benefits include the ability to generate revenue from the solution without it being an enabler for something else, such as for sales of a new medical device. Indirect benefits include the creation of new enterprise architecture capabilities that make it measurably easier (less risk) and more cost efficient to deploy beneficial solutions, such as the capability to have a single view of your customers.
2. Ensure strategic alignment.
The business realizes the leverage of existing enterprise architecture to deliver much more quickly and with much less expense. This is a measure of the project’s contribution to or use of the enterprise architecture to support your operating model.
3. Ensure business execution.
The business realizes productive and efficient creation and deployment of the right solutions. This is a measure of your company’s ability to deploy marketable solutions.
Your organization should begin with a discussion of these value factors as the starting point for developing those that best suit your organization and purpose.
Four IT governance value factors exist:
– Return on investment (ROI)
– Enterprise architecture
– Deliverable value
– Operations
The order of these value factors is important. It reflects the need for evolutionary development and deployment of the right solutions in the most cost and time efficient manner possible.
ROI: The first value factor
The first value factor of IT governance is the ROI of the project with reference to the overall strategic backdrop of the project and consideration of all the dependencies and business conditions that surround the project. The expected ROI from the deployment of the solution should be expressed in terms of revenue, business enablement (value to the enterprise architecture and operating model), market opportunity/market share, or some combination of all of these terms. As a project progresses through its early life-cycle stages, for example, through inception for a RUP managed project, the concerns of the business must surround the value that will be returned to the business if a solution were immediately available.
Enterprise architecture: The second value factor
The second value factor of IT governance is the alignment of proposed solutions with the enterprise architecture. Highly valuable solutions will fit within, support, or strategically extend the business enterprise architecture. Being in strong support of the enterprise architecture will maximize ROI, by minimizing cost or developing the solution, especially in more mature enterprise architecture environments due to application of modern techniques such as SOA. In addition, support of the enterprise architecture will minimize the chance of failure. The enterprise architecture includes the technological architecture of inter-related IT systems, organizational alignment, which includes how divisions or lines of business inter-operate or the business processes. As a project progresses through its early-to-middle life-cycle stages, such as through elaboration for a RUP-managed project, the business concerns (those monitored by the governance board) must reflect the need of proposed solutions to align with the enterprise architecture. The concerns must align technologically in reference to SOA, reuse, and extend or support strategic objectives. In addition, they must align procedurally, meaning that participating business processes can work together in terms of financials, timing, command or control management, and so on.
Deliverable value: The third value factor
The third value factor of IT governance is the assured construction or development of deliverable value. This value factor centers around the basic ability of the business to execute as it is required to convert decisions into tangible, demonstrable business value as rapidly and as error-free as possible. Projects should be able to deliver on ROI at any time as a result of any change in business condition, such as yearly replanning or budgeting, re-organization, divestiture of capability, or shifts in market conditions. As a project progresses through its middle-to-end life-cycle stages, such as through construction for a RUP-managed project, the business concerns (those monitored by the governance board) must reflect the need to obtain ROI on-demand. Project teams must maintain as low an inventory (unimplemented decisions) as possible. Doing so both minimizes costs (no inventory storage) and aligns expectations with just-in-time delivery. For example, decisions can be made with minimal waste or not implemented at all.
Operations: The fourth value factor
The fourth value factor of IT governance is the assurance that deployed systems deliver the expected ROI. Businesses are increasingly more dependant on their IT systems for the delivery of value to their customers and the maintenance of the associated revenue streams. When IT systems do not perform as expected, businesses suffer operationally, such as by losing customers, and financially, such as by losing revenue in real-time. Projects must be able to deliver and operate solutions within defined expectations, such as by service-level agreements (SLAs) for performance, reliability, supportability, and so on. As a project progresses through is end-to-operational life-cycle stages, such as through transition and beyond for a RUP-managed project, the business concerns (those monitored by the governance board) must reflect the need to realize, maintain, and possibly increase ROI.
The IT governance value factors do not operate in a phased manner. After the value factor is introduced to govern the project, it remains as a measurement throughout the governed project life cycle. This approach provides the opportunity for the business to assess each value factor continually, in response to changing business conditions, and consequentially, to adjust priorities, scope, or resourcing, or to cancel or delay projects as needed
Measuring business performance
IT organizations have traditionally concentrated on affecting team and individual (local) productivity and quality indicators as a means of increasing the overall efficiency of IT processes. In the following section, “Example of the need for driving business value, not IT value,” we demonstrate the critical need to drive business ROI over IT ROI, or business initial rate of return (IRR). This example outlines the way in which IT organizations have traditionally attempted to measure business performance improvements, which is in isolation of the whole business value chain. This method can be effective when the core business is, for example, software development in a gaming software development company.
However, productivity of IT processes in most organizations is not an effective measure of business value. The relative cost savings of more productive project team members in isolation of the full end-to-end business process is not significant enough to garner executive interest. Nor is it significant enough to receive the attention and capital needed to fund ongoing improvement programs. Furthermore, the relative cost savings may easily reduce the overall productivity of the IT process or end-to-end business process in which IT process is a key constituent. Therefore, while IT organizations may see real localized value as an increase in the IRR, they often fall short of overall objectives because executives do not see the impact of this IRR on the business top and bottom lines. In short, they observe no ROI.
In financial terms, the ROI of improving IT process performance is not evident. The investment competes with other investments made by the business. Consequently, the ability to establish an explicit connection of IT process performance measures and business performance measures affords a greater context for the value of IT process capability improvements. The evaluation of the value of IT process capability improvements requires thoughtful alignment of measurable risk reduction criteria to the potential and likely ROI from the investment in improvement efforts.
Delivering ROI requires the derivation of monetary value from an underlying software product or other IT system changes. The opportunity costs, improvements of core business processes, missed market windows, and so on provide a business context for positioning IT projects. The simultaneous reduction of business risk and decrease in project cycle time are among the quantifiable benefits that IT project capability improvements can deliver. A framework and a core set of measurements that are driven from the business level down to the project level flips the traditional bottom-up view of metrics. Defining this framework is a primary objective.
Several significant barriers are associated with the ability to measure business performance based on individual project contribution. The challenges stem from the inherent difficulties in mapping project performance indicators to business performance indicators in a way that demonstrates a causal relationship between the two.
It is well understood that measurement programs affect the outcome of the activities that we measure. In fact, taking measurements of practitioner contribution is one good way to measure programs. However, if you are not careful about what you choose to measure, you will achieve results that are aligned with the measurements rather than those that are aligned with the desired result. If you choose the wrong measurements, you incent undesirable behavior. Choosing the “right” measurements will aid your ability to obtain the desired result. However, the desired result may not be obtained in a way that most people would predict. Plans change, requirements change, markets change, and business strategies change all within the time frame of a single project.
Your business must be positioned with processes and procedures to react to these “course correcting” events. A poorly conceived measurement program will consistently and predictably ignore the reality of constant change. For example, if you choose to measure project performance based on earned value contribution, then you are really measuring whether the project is adhering to its predefined plan. Measuring earned value ignores the possibility that the plan may not be the most effective way to achieve the desired result. Adherence to plan provides a false sense of progress and most often leads to cost and schedule overruns.
Furthermore, in the context of measuring business performance, we must recognize that measurements must be taken at several levels within an organization. The measurements that are important to a project team’s performance may not be interesting to executive management. There must be a continuum of interconnected and causal measurement data from the bottom of your organization to the top of the organization. Many companies have referred to this as the “rolling-up” of metrics information to gain an understanding of the overall scope of the project.
The rolling-up of metrics information from the project level to the executive level presents a significant challenge for most organizations. While the kinds of measurements needed at the project level are fairly well understood, the measurements in the mid- to upper-levels of management are not understood. At least, they are not causal to the project-level measurements. Companies must generally cross three hurdles to more effectively build the executive view of the business performance of IT projects:
– Measurements must be objectively collected at all levels.
There must be no opportunity to manually enter or otherwise manipulate measurement data. In cases where manual data entry is an acceptable practice, there must be a complete audit trail of the entries as well as a measure of the corresponding introduction of increased risk due to individual subjective input.
– Measurements must be automatically collected and automatically rolled up.
Organizations have a strong tendency to translate information manually from one level to the next, that is from the project to line of business. The necessary automated systems are not in place or are not effective or manageable.
– Measurements must support the achievement of the desired result at each level.
The right measurements must be selected to align with the business objectives at each level. Do not use project-level metrics to assess business value and risk reduction.
The ability of your company to develop a comprehensive measurement program that serves the needs of all levels of management may be further complicated by the following issues and misconceptions:
– Culture barriers hinder development.
Practitioners at all levels, especially at the project and middle management levels, generally have limited, if any, visibility into the desired business results that are associated with the project. They may claim, “It is not my job.” No context nor governance authority exists to relate project metrics to business metrics.
– Governance is command and control.
The governance solution in place does not empower project teams to make decisions regarding the achievement of desired (strategic) business results.
– Measurement systems are intrusive.
The misconception that having to measure, or to implement a measurement harness, will slow productivity of the organization by requiring project teams to enter data into the measurement system.
– Management is always checking up on practitioners.
Teams might have the feeling that somehow the measurement program will shine a spotlight on their work and performance and management will use their findings to evaluate individual performance. The fact is that measurement programs are used to evaluate business performance, not individual performance.
The institution of objective measurement systems, over subjective measurement systems, looks for indicators of problems or areas of concern in the program. There is a lot of room to hide behind subjectively collected measurement data. The thought of responding to true project status (earlier in the life cycle) may cause concern for project teams that operate reactively rather than proactively.
– The ROI has not been defined.
At all levels in your organization, an honest assessment of the desired business results must be defined. This information may not exist in any formalized documentation, such as within a balanced scorecard, but is necessary to ensure that the organization is strategically aligned from top to bottom