Put simply, IT must support business goals and objectives. It does this by either improving operational effectiveness or by containing costs (efficiency). Therefore, a simple answer of where to start implementing ITIL is in those areas where the highest Return on Investment can be realized. But, of course, it is not that neat.

To begin with, few organizations are starting from scratch. Most organizations have some IT infrastructure in place and the sophistication of the operations is probably determined by the strength of the personnel and technology in respective departments within the IT and business units. The fact that different departments will have different capabilities will be reflected in inconsistent service provision particularly in such areas as capacity and availability management - ie. service delivery components. Managed workforce practices wherein the communications channels are open may help mitigate disparities. Overall, the implementation of various ITIL best practice areas should tend to mirror the organizational maturity required for their implementation.

Implementing all but the most basic ITIL practices (defined as those practices which address a "reactive" organization (ie., firefighting). This would include Incident Management and reactive versions of Change, Release and Problem (eg. Major Situation Root Cause Analysis).

To get beyond these kinds of approaches requires the organization to address its' overall management and organizational capabilities and Capability Maturity Modeling provides valuable insights into how to increase this capacity to implement best practices. CMMI suggests the establishment of maturity goals through target staging of capabilities.

Target a Standardized (Defined) Level of Maturity

This requires a pre-occupation with standards. The following chart is taken from an assessment of organizational "business intelligence" maturity but the discussion is more widely relevant^N.

In the early stages, business units purchase their own toolsets and develop many of their own processes and procedures to employ them. For business intelligence applications these are often spreadsheets or personnel databases used to access information at relatively low costs. Once these business units become reliant on the tools (because of sunk costs on licenses, training, embedded knowledge and expertise), they are highly resistant to any centrally-directed attempts to standardize, particularly when the selected tool is not the one they are using (or even a different version). As the approach becomes more widely used in different business units, the enterprise needs to standardize the tools and approaches to control its' spiralling costs of owning and maintaining the tools and processes. As the graph illustrates, however, the costs of redundancy and uncoordinated actions are not immediately felt - it is "only in the mature stages that standardization delivers sufficient benefits to offset the loss of local control".

Once an organization balances local requirements with enterprise standards, it reaps a multiplicity of benefits that enhance individual performance and boost corporate productivity^D.

Support Case for Service Improvement Project (SIP)

Not so long ago, IT Divisions were exempt from demonstrating Return on Investment to the company. Today, IT plays in the same arena as other enterprise functions - sales, service, finance, marketing: all are expected to project their returns, then deliver with control and predictability. The CIO’s spot at the board room table comes with this level of business results expectation.

ITIL has inherited much of this mystique. It has developed such a following that companies will enter into service management improvement programs based on ITIL best practices without describing the benefits to be expected. The organization gets caught up in the initial euphoria, but most often will pay when the first wave of criticisms threatens the improvement program. The difficulty in expressing these benefits in financial terms has been commented on by Rich Schiesser in IT Systems management.

The creation of the good business case is a critical element/stage in good project management and a service improvement initiative should be undertaken using Project Management methodology. Much of the justification should be included in a business case and ultimately find its' way into the Project Charter. However, the information is often so fundamental in its' description of the state of the infrastructure as to transcend project initiatives. This information not only serves to justify service initiatives but to describe how associated processes will be implemented. The information will be re-used many times and should be periodically revisited to ensure ongoing accuracy. The following are examples of key information which the organization should use to justify service improvement initiatives:

Information	Use
Determine Vital Business Functions (VBFs)	Mapping IS services to business value chain functions allows IS to clearly identify vital business functions and their relationships to Information Services. By mapping these dependencies, IS can more effectively prioritize activities that support vital business functions (eg. incident recovery severity designations, change prioritizations, etc), and focus on adding value to what is most important to the business. IS can also improve its role in the business value chain by being directly involved in the development of new solutions that support vital business functions. In this way, IS can move beyond simply responding to the needs of the business, and delivering IS services per agreed service levels. IS can move to a higher value-add function of jointly planning competitive business initiatives that rely on IS service and support.R
Business costs from service outages for major applications	Prioritize applications for incident treatment Assess which applications require Business Continuity and Disaster Recovery Plans Determine application availability/recovery strategies Assign priorities for change and release management treatment
Number of incidents resulting from poor changes	Determine importance of Change Management as a "pain point" to the organization in conjunction with business costs, ensure appropriate risk mitigation strategies associated with application changes
Cost per user supported by the organization	Determine baseline reference to like-industry averages Establish baseline for trending
Determine Customer satisfaction with IT services provided	determine extent of business support Establish "pain points" Determine baseline satisfaction level for trending

These base characteristics of the IT organization provide the initial justification and outline for a service improvement initiative. A developed "Business Case", a key deliverable of the Concept Phase of Project Management, will cite service deficiencies which need attention. These will be expanded upon in the Project Charter, the major deliverable of the Project Definition phase.

The Project Charter establishes the primary repository for updating this kind of information and the re-usability of this document for further initiatives will further the maturity of the organization with reference to its' project management capabilities.

Establish Governance Framework

It is important to establish who makes what kinds of decisions with regard to service delivery because it determines who needs to be involved in the project and in what capacity - decision-maker, participant, advisor or informant. In CMMI, assigning responsibility is key to institutionalizing a Managed Process. Without a sound governance model there is little assurance that decisions in other areas of an improvement endeavor are being made correctly and by the appropriate people.

The best way to approach Governance is as a shared activity. Assemble some sort of council or IT strategy committee when coming up with a governance model. Then, have the committee take a look at each policy it would like to enact and matrix each by priority, by degree of benefit, and by rank. The starting point to define governance is to define the role and responsibilities of the IT area. Some key considerations are:

• People & Structure - At a department level within IT, there should be a definition of what each area is responsible for. When this structure is rolled up it should cover the responsibilities of the IT area as a whole. By defining R&Rs, then rolling them up as part of a structure, it will become clear where gaps exist, or activities outside the scope of IT are being performed. It also shows the poor fits in the organization^N. Many non-IT areas of the organization can be part of governance^N. This includes communication processes and implies the establishment of formal communication forums where interaction can take place^N.
• Process - establishing the rules under which IT operates. Setting standard processes and methodologies which the organization will use^N. An organizational decision to utilize ITIL or CobIT or CMMI as single or conjoint reference models would be an illustration of this kind of policy. All these should be visible in the roles and responsibilities of the area, and need to be documented at some level (more in Process Management). If a proper business process model has been created, the governance can refer to that model. If not, governance may have to refer to some high level criteria^N.

  "Once IS is aligned with itself, the organization can focus on aligning with business objectives. This includes making sure that IS shares information with the business and understands its requirements. When this type of communication exchange doesn’t take place, the results can cause problems." Ken Turbitt, ITIL -The Business Perspective Approach, August 28, 2005, ITSMWatch

• Projects - Governance should also cover the evaluation of ideas, justification, approval and prioritization of projects. From project start, there are areas that should be included in the governance^N.
• Compliance - There needs to be a mechanism in place to monitor compliance. This can be as formal as an IT Audit function, to as informal as periodic reviews.
• Clarify Exception Handling Methods - Exceptions are how enterprises learn. They challenge the status quo, particularly the IT architecture and infrastructure. Some requests for exceptions are frivolous, but most come from a true desire to meet business needs. If the exception proposed by a business unit has value, a change to the IT architecture could benefit the entire enterprise. Exceptions also serve as a release valve, relieving the enterprise of built-up pressure. Managers become frustrated if they are told they can't do something they are sure is good for business. Pressure increases and the exceptions process provides a transparent vehicle to release the frustration without threatening the governance process^R.

Like any major organizational initiatives, IT governance must have an owner and accountabilities. In most organizations, the CIO will be accountable for IT governance performance with some clear measures of success. Most CIOs will then create a group of senior business and IT managers to help design and implement IT governance. The action of the board or CEO to appoint and announce the CIO as accountable for IT governance performance is an essential first step in raising the stakes for IT governance. Without that action, some CIOs cannot engage their senior management colleagues in IT governance.^R

Establish Policy Framework^R

Policies are established to reduce risk and maximize efficiency. The benefits of standardization will only materialize from effective enforcement of the policy governing work processes. Many policies focus on how work is performed, others dictate when the work is performed, while others mandate what technologies will be employed. By designing and enforcing the appropriate policies, service providers increase quality and enhance agility while minimizing their costs.

Most organizations have no shortage of policies, but, their enforcement is another matter. Many policies are unknown to IT staff so marketing and accessibility are important considerations^N. Without some measure of policy enforcement, standardization is nearly impossible to achieve. Technology selection will be fragmented; economies of scale will be elusive, if not impossible, and learning curves will never be surmounted. Carefully planned, actively enforced policies are a necessary ingredient for the successful transition to a service provider model.

However, not every activity needs a policy. Excessive policy-making can stifle innovation and create an oppressive work environment. There is a balance between the enforcement of policy and the encouragement of workplace creativity^R.

When it comes to building and implementing IT policies, there is no magic bullet. Every business is different, and the approach taken to meet objectives and/or ensure compliance will vary from one environment to another, even in the same industries. However, there are certain best practices which increase the odds of crafting and implementing a policy that employees will support and that will help protect organizational integrity.

A uniform format will make the policy easier to read, understand, implement, and enforce. The scope of a policy should be manageable. Separate, smaller polices that address specific needs will usually be better. A typical policy should include:

• a statement of purpose,
• description of the users affected,
• history of revisions (if applicable),
• definitions of any special terms, and
• specific policy instructions from management.

Policies should be reviewed by legal counsel to ensure that they comply with governing laws, and, they should be reviewed on a regular basis to ensure that they continue to comply with applicable law and the needs of your organization. New laws, regulations, and court cases can affect both the language of your policies and how you implement them. A thorough review of policies at least once a year is desirable and a dedicated notification system/service to keep employees informed of changes should be developed. When revised policies are introduced, they should be formally distributed and thoroughly explained.^R

Establishing Awareness of Best Practices

Few organizations can direct new change through fiat, particularly if those changes involve cultural shifts or the re-alignment of established work habits. Mature organizations will have established work habits which facilitate "change". These organizations are often referred to as "agile^N" in that they can change directions quickly. Flexible alignment of IT with business goals and objectives will preclude any reluctant acceptance of best practices by embedding practices which seek out the lessons learned by others.

While individuals may be aware of good practices within their own job speciality they will often lack the wider perspective associated with other's endeavors and their potential impact on their area. They often fail to understand the trade-offs between their and other units concerns and initiatives. More importantly, this may be reflected in a failure of cooperation in administering functions as a participant within a more encompassing service chain. The result is less than optimal performance and disgruntled customers.

A basic presentation on IT service management best practices throughout the organization (such as an ITIL Essentials introduction) will be useful in sponsoring involvement and creating support for initiatives.

Define Risk Management Approach

Risk^N management allows IT management to balance operational and economic costs of protective measures and achieve gains in mission capability by protecting the IT systems and data that support the organization. Minimizing negative impacts on an organization are the fundamental reasons organizations implement a risk management process for their IT processes and systems. Effective risk management must be totally integrated into all service management best practices - particularly service restoration, change and release processes^R. The organization should establish (preferably in conjunction with developing a policy framework) a general risk assessment approach which defines the scope and boundaries, the methodology to be adopted for risk assessments, the responsibilities and the required skills. The approach should ...

• assess the risk acceptance capacity of the organization
• focus on examining essential elements of risk such as assets, threats, vulnerabilities, safeguards, consequences, and likelihood of threat
• provide for the definition of a risk action plan to ensure that cost-effective controls and security measures mitigate exposure to risks on a continuing basis
• ensure a formal acceptance of the residual risk, depending on risk identification and measurement, organizational policy, uncertainty incorporated in the risk assessment approach itself and the cost effectiveness of implementing safeguards and controls.

Choose a Structural Fault Management Approach

A primary goal implicit in ITIL is the removal of structural faults (which cause the cessation of business operations). The time it takes to recover from incidents will often impact the profit line of an organization, so that the organization should consider its' recovery. This will usually be accomplished through one of four generic approaches:

1. Place reliance on restoration - Ensure that once an incident occurs that recovery will be as fast as possible with priority treatment being based upon the impact of the outage to business operations. The first order of business is to restore service through the implementation of a workaround with the root cause of the incident taken offline for subsequent investigation.

2. Find and remove root cause - The ITIL practices of directing initial response to the implementation of a workaround has its' critics...

   "Some might question: "why start at problem management and ignore incident management?" Incident management, while important because it focuses on the fastest way to help people resolve an immediate issue (email your file to me and I'll print it; meanwhile, we'll create a trouble ticket to figure out why the printer near you isn't working) can actually be a negative drag on productivity. Workarounds are, after all, work that doesn't really solve the problem and with repetition can quickly add up to many times the work required to resolve the underlying problem." The Fastest Payback for Your ITIL Investment, Integrien White Paper, October, 2005, p.3

   "A successful Problem Management implementation will free up IT resources required to perform daily support activities, which allows for resources to be directed towards an overall ITIL implementation. Traditional human-based Problem Management has significant limitations that preclude it from being effective at freeing up IT resources." Problem Management: The Key to Leveraging an ITIL Implementation, Chorus System Inc Whitepaper, March 2005

   These authors (usually associated with Knowledge-based products) contend that Problem Management analysis and decision making activities are overly labour intensive. Consequently, Incident data consists of vague symptoms as reported by users and high level status information from monitoring systems and monitoring tools constrain the amount of information to be analyzed to that which a human is capable of absorbing. Thus key data required to properly diagnose a problem seldom exists. In addition, when the root cause of a problem is determined and a workaround or solution is identified, the characteristics of the error and the associated solution are seldom recorded in a known error database (knowledge base) ^N. Because of poor incident data and ineffective knowledge bases, many organizations are forced to increase human resources within Problem Management. In some organizations, Problem Management is actually a functional group of people rather than a process. In reality, most organizations are so busy being reactive that there is little time to be proactive.

3. Contain the impact of faults - Infrastructure redundancy, fault-tolerant, effective back-up strategies, etc will allow the fault to occur without it resulting in an outage to the business. In the past, this strategy was too expensive to employ for all but the most important of the enterprise's applications. Today, however, with the advent of blade computing and self-help mechanisms and their diminishing costs (at least relative to business losses experienced through the outage) their use is becoming widespread.

4. Problem prevention - Management of the processes in which structural faults enter the infrastructure through improved Change and Release Management processes. This is the premise behind the Visible OPS approach ^R. Their approach starts by Stabilizing the Patient - that is reducing the number of new faults being introduced to the infrastructure by freezing change outside of scheduled maintenance windows^N. they then direct attention to effective Release Management processes by reducing the risks associated with release through the use of known and trusted "build processes.

   The highest return on investment comes from implementing effective release management processes. This step creates repeatable builds for the most critical assets and services to make it "cheaper to rebuild than to repair." We take the priceless paintings identified in the previous step and work to create equally functional prints that can be mass-produced The Visible OPS Handbook, Starting ITIL in 4 Practical Steps, Kevin Behr, Gene Kim and George Stafford, ISBN: 0-9755686-0-4

Identify Configuration Items

Some ITIL process areas are harder to implement than others. A 2002 study of 10 ITIL assessments in the UK found that "in the area of Configuration Management organizations consistently under achieve"^R. Though central to the control and management of IT resources, an exhaustive CMDB is difficult to establish and even more problematic to maintain. In the end, this requires automation through auto-discovery tools - "Dynamic, current, accurate, service-relevant, adaptive and scalable - auto-discovery is one of the holy grails surrounding the CMDB^R. Control comes at a cost.

BMC Software Solutions, a major provider of ITSM toolsets, has contended that the "hands-off" approach by ITIL has resulted in a great deal of confusion about what a CMDB is and what it is not^R. They note, that "One thing, however, that ITIL is explicit about is the fact that configuration management is focused on the relationships among infrastructure hardware and software components".

In both CMMI and Service Management Maturity, Configuration Management is cited as a key sub-process for the achievement of Level 2 (ie. Managed) maturity. Therefore, achieving some capability in this area is key to realizing basic management capabilities. CMMI identifies key Configuration activities:

• Identifying the configuration of selected work products that compose the baselines at given points in time
• Controlling changes to configuration items
• Building or providing specifications to build work products from the configuration management system
• Maintaining the integrity of baseline^N
• Providing accurate status and current configuration

The highlighted item above indicates that CMMI treats Change Management as a sub-process of Configuration Management - ie., Track and Control Changes.^N. Change Management is seen as the means of controlling modifications to the Configuration data system. Therefore, even though the CMDB may be difficult to develop, populate and maintain, it is nonetheless a critical to properly defining the impact of incidents and prioritizing competing demands for resources to devote to recovery activities. Additionally, it is key to any improvement efforts directed at refining the risks associated with changes to the infrastructure.

Fortunately, the population of the CMDB can be done in stages - both from the perspective of the granularity of a record^N and the scope of the coverage^N - "Very often, due to the large number of CIs involved, a phased approached will be adopted to implement this process"^R.

Develop Project Management Capability

Service Improvement Programs should be implemented using project management approaches and practices. The organization's capabilities with respect to project management, will, to a large degree, determine how successful it is in undertaking a service improvement initiative.

In addition, infrastructure rollouts and major releases should be controlled using project management methodologies. The capabilities of the organization in re-using and perfecting project plans will affect their success rates and lead to reductions in changes which need to be backed out and fewer structural faults and incidents in the infrastructure.

Project Management is a key control in the CobIT framework, and the existence and review of the framework is a key control area - establish and periodically review a general project management framework which defines the scope and boundaries of managing projects, as well as the project management methodology to be adopted and applied to each project undertaken.^R. The publication describes the attributes for Project Management in organizations at different maturity levels.

Similarly, Project Management is one of four process areas in CMMI^N. Note that basic Project Management capabilities are associated with a level 2 (Managed) organization while Process Management proficiencies require level 3 (Defined) maturity.

Level 2 - Managed

• Project Planning - establish and maintain plans that define project activities
• Project Monitoring & Control - provide an understanding of the project's progress so that appropriate corrective actions can be taken when the project's performance deviates significantly from the plan.
• Supplier Agreement Management - Manage the acquisition of products from suppliers for which there exists a formal agreement.

  Level 3 - Defined

• Integrated Project Management for IPPD - establish and manage the project and the involvement of the relevant stakeholder's according to an integrated and defined process that is tailored from the organization's set of standard processes.
• Risk Management - identify potential problems before they occur, so that risk-handling activities may be planned and invoked as needed across the life of the product or project to mitigate adverse impacts on achieving objectives.
• Integrated Teaming - form and sustain an integrated team for the development of work products.
• Integrated Supplier Management - proactively identify sources of products that may be used to satisfy the project's requirements and to manage selected suppliers while maintaining a cooperative project-supplier relationship.

  Level 4 - Quantitatively Managed

• Quantitative Project Management - quantitatively manage the project's defined process to achieve the project's established quality and process-performance objectives.

Identify IT Services

Service Level Management was one of the first areas addressed in the second version of the ITIL books. It's primary focus is on distinguishing types of agreements and emphasizing the need for written agreements to replace verbal accords. Much discussion centres on the contents of the agreements and the need to report against performance commitments contained within the agreement. Service Catalogues are mentioned in passing but the relationship between them and SLAs is not expounded upon.

More recently, SLM has been advanced as a key method in ensuring IT-business alignment. As the Cheshire cat replied to Alice - "If you don't know where you're going, any road will get you there".. So, many organizations are discovering that operational effectiveness means that money must be directed to activities and processes which have returns realizable in the achievement of business goals and objectives - operational efficiency is just wasted dollars if it doesn't add business value. The three main concerns facing executive management today are compliance with government regulations, cost reduction and increased revenue generation: The first of these, compliance with government regulations, is a major issue for IT. It may be a key drivers in defining the service management (eg. Sarbannes-Oxley), requiring close cooperation with corporation financial and business leaders. At the very least, it will require periodic compliance reports. Cost reduction is always a concern for both IT and the business. Streamlining processes and offering self-service capabilities through a service catalogue and knowledge bases can reduce costs while empowering users. Lastly, streamlining and automating processes for initiating requests and streamlining the authorization process can reduce time to service, freeing technicians to work on higher-priority issues like increasing efficiencies or providing additional revenue-generating capabilities Indeed, increasing attention has been directed to the production and dissemination of a Service CatalogueR as a means of better achieving this alignment. "Central to these and other ITIL processes, is the IT Service Catalog, which provides a compelling venue for communicating service options in terms of content, costs, service level agreements (SLAs) and other characteristics to IT customers. The IT Service Catalog can also empower IT operations and planning with an effective model of business services and their end-components, which can support and enhance a large number of ITIL processes, as well as most management disciplines." The Service Catalog: an Essential Building Block For ITIL, White Paper Prepared for Centrata, December 2004, p. 1 "The Service Catalog is a critical first step in ensuring that IT services align with the business unit’s needs. By establishing a standard set of service offerings, with associated service levels and costs – and then publishing that information to the internal customers of IT – the IT organization can leverage market forces to manage demand for services. IT can become more demand-driven, based on informed customer requests for pre-defined service offerings, and thus improve alignment." How to Produce an Actionable IT Service Catalog, newScale Whitepaper, February, 2005, www.newscale.com

A Service Catalogue offers the organization a method to establish a relationship between costs and the provision of IT services.

Many organizations avoid internal pricing of time and resources. While unpopular it will promote a tangible shift in a service provider's orientation. Both internal and external prices are fundamentally based on a calculation of the cost of delivering a service to a customer. The accuracy of the cost analysis will determine the financial viability of the service. No service assessment can be adequately undertaken without such figures. All relevant costs should be captured, categorized and assigned to a service. Cost modeling must be both systematic and repeatable. Once gathered, the costs must be incorporated into an internal pricing model for analysis along two dimensions.

Establish Documentation Repository

Process management is a way in which an individual, a group, a project, or an organization thinks about, and manages, its work activities. It is based on the premise that the quality of the product is governed primarily by the quality of the process used. . IT is being forced to pay far greater attention to process for three primary reasons:

• regulatory mandates requiring IT organizations to prove that they have taken reasonable care in controlling their IT processes.
• the push for efficiency. One area that has been largely untouched in this effort to maximize IT efficiencies is the process area. There is a wealth of efficiencies that can be reaped from focusing on processes.
• the push toward automation and responsive infrastructures that can adapt rapidly as business needs change. Automation is not a silver bullet for processes. In reality, automation should not be undertaken unless there are established processes that are already stable and effective^N.

The ability to utilize known, trusted and re-usable processes is an important organizational attribute. Without defined and enforced processes encompassing best practices wherever practical the organization is doomed to repeat its' mistakes because there are few formalized methods to capture learning.

Process Management is one of four key primary areas in CMMI^N which defines an organization's capabilities and overall maturity. Each of these four areas can be defined by the maturity of sub-processes within that area.

However, Process Management requires key process capabilities by an organization which are associated with higher levels of maturity:

Level 3 - Defined

• Process Focus - plan and implement organizational process improvement based on a thorough understanding of the current strengths and weaknesses of the processes and process assets.
• Process Definition - establish and maintain a usable set of organizational process assets. This is a key practice area. It is instructive to note the sub-processes CMMI advances for implementing this Practice Area. It represents a practical plan for implementing process definition capabilities.

  Establish Standard Processes Decompose each standard process into constituent process elements to the detail needed to understand and describe the process Specify the critical attributes of each process element Specify the relationships of the process elements Ensure that the set of standard processes adheres to applicable policies; process standards and models; and product standards Ensure that the set of standard processes satisfies the process needs and objectives of the organization. Ensure that there is appropriate integration among the processes that are included in the set of standard processes. Document the organization's set of standard processes. Conduct peer reviews on the organization's set of standard processes. Revise the set of standard processes as necessary Establish Lifecycle Model Descriptions Select life-cycle models based on the needs of projects and the organization Document the descriptions of the life-cycle models. Conduct peer reviews on the life-cycle models. Revise the descriptions of the life-cycle models as necessary Establish Tailoring Criteria and Guidelines Specify the selection criteria and procedures for tailoring the set of standard processes Specify the standards for documenting the defined processes Specify the procedures for submitting and obtaining approval of waivers from the requirements of the organization's set of standard processes Document the tailoring guidelines for the organization's set of standard processes. Conduct peer reviews on the tailoring guidelines Revise the tailoring guidelines as necessary Establish the Organization’s Measurement Repository Determine the organization's needs for storing, retrieving, and analyzing measurements Define a common set of process and product measures for the set of standard processes Design and implement the measurement repository Specify the procedures for storing, updating, and retrieving measures. Conduct peer reviews on the definitions of the common set of measures and the procedures for storing and retrieving measures Enter the specified measures into the repository Make the contents of the measurement repository available for use by the organization and projects as appropriate. Revise the measurement repository, common set of measures, and procedures as the needs change Establish the Organization's Process Asset Library Design and implement the process asset library, including the library structure and support environment Specify the criteria for including items in the library. The items are selected based primarily on their relationship to the set of standard processes Specify the procedures for storing and retrieving items Enter the selected items into the library and catalog them for easy reference and retrieval. Make the items available for use by the projects Periodically review the use of each item and use the results to maintain the library contents. Revise the process asset library as necessary

• Organizational Training - establish and to develop the skills and knowledge of people so they can perform their roles effectively and efficiently

  Level 4 - Quantitatively Managed

• Process Performance - establish and maintain a quantitative understanding of the performance of the set of standard processes in support of quality and process-performance objectives, and to provide the process performance data, baselines, and models to quantitatively manage the organization's projects.

  Level 5 - Optimizing

• Innovation & Deployment - select and deploy incremental and innovative improvements that measurably improve the organization's processes and technologies. The improvements support the organization's quality and process performance objectives as derived from the organization's business objectives.

Organizational process assets enable consistent process performance across the organization and provide a basis for cumulative, long-term benefits to the organization. A Process Catalogue provides a single source of the definition of IT operations processes. It is invaluable in the management and continuous improvement of these processes^R. This collection of items should include descriptions of processes and process elements, descriptions of life-cycle models, process tailoring guidelines, process-related documentation, and data. The catalogue supports organizational learning and process improvement by allowing the sharing of best practices and lessons learned across the organization.

For the catalogue to properly work it should meet the CMMI criteria for institutionalizing a Process Definition at the defined level

• Establish Policy - Establish and maintain an organizational policy for planning and performing the organizational process definition process^N.
• Provide Resources - A process group typically manages the organizational process definition activities. This group is typically staffed by a core of professionals whose primary responsibility is coordinating organizational process improvement. This group is supported by process owners and people with expertise in various disciplines.
• Assign Responsibility - Assign responsibility and authority for performing the process, developing the work products, and providing the services of the organizational process definition process.
• Train People - Examples of training topics include (1) planning, managing, and monitoring processes (2) Process modeling and definition, (3) Developing a tailorable standard process
• Manage Configurations - Examples of work products placed under configuration management include (1) set of standard processes, (2) descriptions of the life-cycle models, (3) tailoring guidelines for the set of standard processes, (4) definitions of the common set of product and process measures, (5) measurement data
• Identify and Involve Relevant Stakeholder's - Examples of activities for stakeholder involvement include (1) reviewing the set of standard processes, (2) reviewing life-cycle models, (3) resolving issues on the tailoring guidelines, (4) assessing the definitions of the common set of process and product measures
• Monitor and Control the Process - Examples of measures used in monitoring and controlling include (1) percentage of projects using the process architectures and process elements of the set of standard processes, (2) defect density of each process element of the set of standard processes
• Objectively Evaluate Adherence - Examples of activities reviewed include Establishing organizational process assets.
• Review Status with Higher Level Management - Review the activities, status, and results of the organizational process definition process with higher level management and resolve issues.

Much of this material exists in the organization in various uncollated (and hence, less accessible) forms. The collection and retention of these process artifacts is an exercise which can be undertaken early in preparation for their inclusion in process modeling and storage in a process repository.

Establish Base Measurement Capability and Culture

Many organizations rely upon a tool to provide the process. This most often occurs because the underlying IT discipline's processes and activities and their associated value are not properly understood. Most IT managers understand the technology tools that are used to oversee the environment and deliver the required products and services to its constituency, but not the underlying processes or relating measurements. IT organizations may do a good job of measuring and/or tracking certain aspects of the IT environment, such as database transactions, network uptime, trouble tickets, change requests, and so on but falter in providing the end-to-end measurement and reporting of the IT organization's transformational processes.

One of the most popular characterizations of indicators is the one known as SMART ^R meaning that a good indicator has to be Specific, that is, identified with a relevant variable and representing it accurately; Measurable, that it not only may be measured but that there are also the mechanisms necessary to generate the corresponding information in order to quantify them; Action-oriented in relation to critical processes of the organization; Relevant (R:Relevant) in general terms has to do with the differentiation between lots of trivial ones and the few vital ones; Timely which has to do with the availability of information at the right moment for the decision making.

to Project Options