Process Management Table of Contents
Process management is the application of management principles to the definition, evaluation, improvement and communication of business processes across an enterprise. It is a guide and framework and is essentially a process about processes. Process management has the same characteristics as any business process, inputs, outputs, defined activities and tasks, guides and enablers. The objective of process management is to provide a common set of tools and techniques for teams from across the enterprise to use in the design and redesign of business processes. These tools include a common language, guidelines and standards to ensure teams can communicate easily and that the projects within a program produce solutions that are integrated from a process point of view. More....

Introduction to Process Management

A growing number of IT organizations are exploring how to develop and execute an IT process improvement program. However, for a variety of reasons many have simply not been able to address this issue. Some of the most often cited factors include not having the time, resources, or the skilled personnel to commit to developing a comprehensive IT process management program. And, of course, the budget tightening that has continued over the past few years has forced many IT organizations to focus on other initiatives. IT budgets are increasing, but the history of a high degree of IT failures and seemingly unchecked spending of the late 1990s has had its affect. ^[Note]

While IT organizations may measure and track certain aspects of the IT environment, (ie., database transactions, network uptime, trouble tickets, change requests), the ability to provide the end-to-end measurement and reporting of the IT transformational processes that govern these and other important process activities is often overlooked. There are many processes required to manage a technology organization. These include processes to manage customer-facing functions, internal department support, finance, procurement, and asset management. The issue is not whether IT has "business" processes, the concern is how they manage and measure the effectiveness of these processes and the value to the business^[Ref].

The magnitude of such failures was recently highlighted in an informal poll conducted at a web seminar. Computer Economics, an online computer research outfit, co-hosted a web seminar, attended by over 75 technology leaders, on the topic of the importance that IT process architecture plays in developing an adaptive and agile IT organization. An interactive, online poll of the audience was taken regarding the effectiveness of IT process management. The seminar participants were asked the following question: "How effective is your IT process management strategy?" 70% responded that their strategy was NOT Effective while only 8% cited an effective strategy^[Note].

Process Management

Many organizations are concerned about the quality of their IT service management and are addressing this by implementing ITIL best practices. These best practices are described over ten sub-disciplines divided into two categories - service management and service delivery. The practices are described in each area, but the descriptions will vary by the requirements of the organization to successfully implement the practices in the area. In addition, there can be variability in how easily the sub-practices can be implemented. However, for the most part the best practices are geared towards enterprises with organizational capabilities between levels 2 and 3 on the Capability Maturity Model (CMM) scale.

A key to achieving level 3 - a Defined level of management is the ability to develop, maintain and utilize process descriptions. These processes are intended to achieve operational consistency and to reduce process and hence service variations to the Customers. The delivery of services of known quality and consistency is a prime characteristic of a Customer-focused organization.

The goal of this process description is to develop a process "for managing processes". The importance of this is clearly cited in Business Process Management - The Third Wave".

Process Management addresses the needs for CMMI enablers cited in the Appendix, most prominently - ’Establish and maintain the plan for performing the organizational process definition process.’

Specifically, this means:

• The organization’s set of standard processes (the basis for achieving maturity level 3), is established and improved over time.
• Standard processes are used to establish consistency across the organization
• Projects establish their defined processes by tailoring the organization's set of standard processes according to tailoring guidelines
• Processes should always begin with business requirements and culminate in a successful, cost effective outcome
• Ensuring capture of individual knowledge and experience on procedures is retained as corporate knowledge

Critical Success Factors

• Process description are maintained in a process library.
• Operations are not permitted to operate outside the process descriptions.
• A process to expedite changes to process descriptions is put in place until process descriptions and operations become mutually consistent.

Coverage

In Scope

• ITIL process descriptions describing major service management and delivery processes
• Service fulfillment chains describing how departments interact in the fulfillment of Customer services (e.g. new employee IT services)
• System recovery procedures - standard procedures outlining how major systems can be recovered quickly. These procedures are invoked in the case of a major outage and, because the outage procedures are been reviewed and tested, will have low associated risks with their usage (e.g. system re-boot sequences)
• Standard back-out procedures - standard procedures for back-out changes in order to restore a previous state either for technical reasons or because the change cannot be completed in the time allowed

Out of Scope

• Documentation which is not part of a process plan describing an operational characteristic (eg., contact pager numbers)
• Non participating IT units within enterprise (eg. application area not part of enterprise IT service)

Assumptions

• Processes are organizational assets in the same manner as hardware and software
• Staff will follow processes if they are aware of them and, with proper motivation, will make an effort to improve them
• Defining and subsequently improving a process will have a positive impact on the business
• Processes will contain many errors when released which must be attended to while in production

Process Inter-relationships

Release Management

Change Management

Incident/Problem Management

Service Level Management

Configuration Management

Capacity Management

Policies & Guidelines

• There will be a Definitive Process Document Library (DPDL) containing a process description of all major processes operating within the organization. (A major process is defined as one having a significant impact on one or more important outputs of the IT Provider)
• There will be only one formally recognized description maintained in the DPDL for each process
• Processes are in production with release of version 1.0
• Processes will be described using the format described in the Process Description Template in the Appendix
• There will be a Process Owner who is responsible for the integrity and currency of each description
• Modification to process descriptions will utilize Change and Release Management processes. In this regard, the DPDL is treated in the same manner as a DSL. A Defect List will itemize known issues which have not been adequately addressed or agreed upon by participants. Versioning will conform to rules sets set out in basic concepts

How the Process Scales

Small organizations can benefit from ITIL as easily as large organizations, but, the manner in which the benefits accrue may be vastly different. Small IT units usually have two main responsibilities. ^[Note]

1. Applications - including software development if applicable, and,
2. Service & Support - including IT infrastructure support and helpdesk services.

The larger the IT unit the more specialized will be the departments. A few characteristics of small IT units are:

• More likely to outsource certain tasks and responsibilities
• Reliance on individuals which creates more single point of failures
• End users are expected to be more self-supporting
• A highly flexible IT staff with much team spirit
• Very short and informal communication lines
• It goes without saying that smaller IT units usually have smaller budgets.

Consequences of these characteristics are:

• Outsourcing, technology, and ITIL processes solve managing growth issues
• Outsourcing decisions are more often based on avoiding risks and on initial cost reductions
• Tools and technology is introduced to automate as much as possible tasks, and to provide sufficient management information
• ITIL Processes are to support the hiring process of the right IT skills, the outsourcing of the right IT responsibilities, and to set the right expectation levels within the user community

This results in the following characteristics of small enterprises with regard to ITIL.

Concepts

• Process Level 1 describes a 'mega-process' such as Change Management. In practices this level strives to give readers a broad, high-level understanding of the process in question. At this level of abstraction the entire process should be able to be displayed on a single page. The next process levels provide increasingly level of detail.
• Process Level 2 translates a Level 1 process such as Change Management into major process functions. Change Management is subsequently de-composed into Change Initiation, Change Planning and Change Implementation functions. Process Level 2 process documentation depicts the inputs, outputs, controls, mechanisms and major activities for each process function.
• Process Level 3 defines and sequences the main events within each process function. At this level of decomposition, we would find the detailed activities associated with, to continue the example, Change Administration processes such as Reviewing & Closing RFCs, Updating Change FSC, etc. and depicts in increasing details the inputs, outputs, controls, mechanisms and major activities for each process event.
• Process Level 4 defines the sub processes and activities within a main process. At this level of detail, Change Managements' Emergency Change Advisory Board process would be captured in fine enough detail so that the subject matter experts and process performers can clearly understand how the process relates to their work
• Process Level 5 defines the supplemental procedures and reference material used to guide, clarify or instruct how tasks are performed.

The information about processes, the process diagram itself and possibly even the experiences of the organization's use of them will be captured in a repository. The repository will be accessible to stakeholders (including internal customers) or performers of the business processes. The repository will be maintained as one of the process management responsibilities. Even if the repository is a file cabinet, there should be a central place to store and retrieve process related information. The Process Manager is responsible for selection, communication and maintenance of the repository.

Toolsets & Notation

However, re-engineering proved to be excessively time-consuming and expensive, and the concept fell out of favor. While it never completely disappeared, it assumed a vastly diminished profile.

Like the phoenix, however it arises from the ashes - morphed into a new and different creation. Driven by the Bush administration's enterprise architecture mandate in the United States, government agencies are using various approaches and support tools to get their architectural house, and uses in order.

The new field is a mix of old stand-bys and newer methods. Integrated Computer-aided Manufacturing Definition (IDEF) was the approach of choice in the 1990s and remains the only one compliant with the U.S. Federal Information Processing Standards (FIPS). Joining it are two other techniques: Unified Modeling Language (UML) and Business Process Modeling Notation (BPMN).

UML comes from the object-oriented software design world and has been pressed into process modeling chores. Meanwhile, BPMN is an emerging approach that is gaining credibility among software tool vendors. It promises to do what previous approaches have failed to accomplish: integrate systems development from the business process model to actual code generation.

Process Asset Library

To Oetringer the solution is "a single respository or a definitive document library" to hold official IT documents.

Process descripotions are an extension of this thinking. All process documentation should be retained in the DPDL - a logical extension of the Definitive Software Library (DSL) and CMDB. The DPDL should be accessible from an intranet web portal. The repository or process library will store processes and supporting information. At the enterprise level (Business Control Level 1 in the hierarchy described above) the library would contain the ITIL best practices for easy reference. Process templates for each level in the process hierarchy will also be available from the process library.

Process diagrams and related information to be included in the repository must adhere to accepted, standard enterprise process guidelines. Furthermore, each process must be sanctioned by a process governance structure before inclusion in the repository or before invocation of change management processes. The process repository is authoritative - all other illustration, diagrams, flowcharts not contained in the repository can only be considered work in progress.

Documents are to be placed into the appropriate part of the repository in order to be accessible and easy to locate. The Process Classification Framework discussed below illustrates a preliminary structure of the DPDL.

The root of the document repository should be located on an intranet website. Initially, the repository will have two main branches: one branch may be structured around processes associated with adoption of the ITIL framework while the other branch will form a structure analogous to a Service Catalogue. This latter branch is needed to gather process and procedures relating to services. The website content management capabilities will be the primary method of managing and controlling the documentation.

Versioning

Change Management

Key Performance Indicators (KPI) are short, focused and measurable indicators of performance of the enabling factors of the IT processes, indicating how well the process enables the goal to be reached. While Key Goal Indicators focus on "what", the Key Performance Indicators are concerned with "how". They will often be a measure of a Critical Success Factor and, when monitored and acted upon, will identify opportunities for the improvement of the process.

Critical success factors (CSF) are those primary process performance measures that most closely define and track how the process must perform to be considered successful. CSFs are directly related to strategic and business plan objectives and goals. For each critical success factor there must be an associated key indicator that provides the measure and a standard of performance or allowable variance from planned performance. The most effective key indicators are those designed into the process in such a way as to provide a readily available or continuous reading of performance. Many of the instruments on a car dashboard can be considered examples of key indicators.

CSFs provide one means of assessing the need for process improvement actions or projects. This is especially true when the key indicator relates directly to stakeholder interests. For instance, if customer satisfaction survey results are a key indicator for a process and the standard of performance is set at 90%, any reading below 90% suggests the need for corrective action.

Process measurement and metrics should be identified during the definition of the process. These measurements can be driven from Six Sigma Voice of the Customer (VOC) and Critical to Quality (CTQ) exercises.

There are four types of performance measures. Specific measures within these categories provide the basis for evaluating both the satisfaction of stakeholder interests and the performance of all process participants.

1. Conformance to Standards (CTS)
   Conformance to standards measures are concerned with product and process quality with respect to a norm. CTS measures the factors of customer acceptance of a product, service, or deliverable; number of rejects; adherence to procedures; test results; budget performance; compliance with public law, statutes, and regulations; and issues associated with health, safety, and security.

   There must be a well-documented or illustrated standard in place. The standard must state the requirements, the authority for the standard, and the applicability. New standards of performance should be validated before being put into service for a given process. Benchmarking is a particularly good technique to use in establishing standards of performance in this category.

   While all four process stakeholders are concerned with CTS, Higher Authority (see Roles below) is particularly interested because it is the source for most conformance standards. Customers are also interested in CTS as it applies to output products and services.

2. Fitness for Purpose (FFP)
   Fitness for purpose measures are focused on the degree to which a given interaction between a stakeholder and the process meets requirements or satisfies an objective. FFP measures such factors as how well a product or service satisfies (meets requirements) or even excites (exceeds requirements) customers. Customization, flexibility, and responsiveness are qualities that generate FFP measures.

   FFP also applies to other stakeholders. Higher Authorities need to measure the relevance of standards, rules, and regulations to the processes on which they are imposed. Suppliers are becoming more proactive in supplying processes with just enough value-added materials and data to meet process requirements with a minimum of waste. Resource providers are concerned with providing suitable facilities, equipment, and funding vehicles to maximize process performance.

3. Process Time (PTM)
   Process Time measures are concerned with process cycle time, throughput, and responsiveness. But process time is also a reliable surrogate measure for process cost. This is because process costs are consumed over time and, in general, the less time a process takes to complete a cycle or produce a product, the lower the cost. Many leading enterprises focus on reducing process time rather than on reducing process cost. As a result, they improve cycle time while automatically reducing process cost.

   Process time measures fall into three sub-categories. Operations Time is defined as the time spent within a process transforming inputs into outputs. It is the direct application of resources or factors of production in making the transformation. Non-value added time is time spent in the process other than operations time or quality-related time (described next). It includes delay or wait time, meetings and report writing, supervision and oversight, compliance with unnecessary or inappropriate regulations, planning and budgeting, employee relations, acquisition and procurement, and internal paperwork. Quality-related time includes inspection, rework, error prevention, problem determination, problem solving, quality-related maintenance, and training.

4. Process Cost (C$T)
   Process Cost measures are concerned with the consumption of resources allocated to the process of producing output products and services. Variable costs include supplies that are consumed in producing outputs as well as the factors of production, which include labor, machine hours, and facilities integral to process operation.

   There are also fixed process costs not directly associated with process operation that must be measured, managed, and controlled directly. These include cost of excessive benefits and prerequisites, cost of facilities not directly related to work processes, and cost of non-productive (non-income producing) assets.

Roles and Responsibilities

Process Documentation Manager

• Responsible for maintaining the integrity of the DPDL containing process descriptions.
• Acts as Local Change Manager for process documentation.
• Ensure adherence and consistency to Change and Release Management processes

Process Owner

• Responsible for the accuracy and continued currency of processes documentation.
• Ensures all participants in a process are consulted and their views are reflected in process maps.
• Modify process descriptions and submit RfC with proposed modifications.

Local Change Manager

• Ensures changes to processes follow Change and Release Management procedures.
• Refer process changes of high significance to Corporate CAB for consideration.

Process Modeler

• Ensure process activities and steps reflect current or anticipated future processes.
• Report any variances between operations and described processes to the Process Owner.

Performance Measurement

Key Goal Indicators

Many of the best practices outlined by ITIL are based upon the assumption of specialized roles in the organizations (eg., Service Desk as generalists specializing in 'First point of Contacts', Availability and Capacity Management focuses independent of the infrastructure components under consideration). The assumption of these roles is predicated on the IT organization being of a sufficient size to economically justify the diversification. While it is possible to group ITIL roles in new ways (eg. Change Manager and Configuration Manager) even this grouping implies a certain size threshold.

The organization's ability to specialize along ITIL best practice areas correlates with its' ability to assume higher maturity practices. The prime ingredient in achieving greater maturity is the ability to undertake continuous improvement. This occurs in a number of stages:

1. the ability to perceive what is good about a process toe to emulate or codify it so that it can be repeated.
2. the definable elements of repeatable processes can be identified and codified. The organization then operates in accordance with the process description and that description (and, not the internalized learning of individuals) becomes the defining element. Commonalities amongst processes lead to new insights and further refinements to the processes.
3. the processes are objectively measured against objectives and deviations become the subject to refinement.
4. the measurements are subjected to implicit models wherein the processes can be subjected to optimal performance criteria.

The assumption of higher maturity characteristics implies the infusion of resources - first to define and operate from those definitions, later to undertake ongoing, meaningful performance measurements. It involves specializations in the same way that ITIL practices do, but, there is no guarantee that adopting ITIL specializations will lead to significantly greater organizational maturity - the specializations reside in different strata. Any one of the three grey lines in the above chart is possible. The steeper incline portrays an organization moving rapidly to greater organizational maturity. This organization will instill in itself the internal capabilities to find its' own best practices. The lower incline reflects an organization dependent on thye reported best practices to garner efficiencies. The middle line is perhaps optimal. It allows the organization to build upon the best practices of others to achieve some quick wins while putting in place operational characteristics which will allow it to build upon this start and tailor those practices to its own internal cultural and size characteristics.

Maturity characteristics have been identified in COBIT for 34 IT governance practices - which include the majority of ITIL areas. The Key Goal indicators for these practices are to achieve the characteristics described by higher maturity implementations of each practice. You can refer to the COBIT description for these determinants.

Key Performance Indicators

• The percentage of internal processes which are maintained in the DPDL
• The degree to which Change process documentation in the DPDL accurately depicts actual process operations.

Metrics

• percentage of processes documented and maintained in the Definitive Process Document Library (DPDL).
• Average annual number of RfCs per process (until processes become error free).

Measurement Issues

• Identification of process inconsistencies requires a concerted effort to monitor processes against their description for a period of ’gestation’ following the implementation of a ’defined’ process (or large scale revisions).

Processes

Inputs

• Business Requirements

  If you are going to manage a process effectively, you need to start with an understanding of the business and the role of the process within it. There are powerful cause-and-effect relationships that exist between processes, even between those that may at first appear to be unrelated. Clearly these need to be understood.

  Requirements can originate from a number of sources but chief amongst them are Service Level Requirement and Service Improvement Plans developed by Service Level Management.

• Procedural Documentation

  Operations manuals will provide important information on how processes and their associated activities are conducted and flow over a lifecycle. Process and Service Owners share the responsibility for this documentation.

• Existing Process Descriptions

  Existing process descriptions provide the baseline to undertake revision and quality analysis (e.g. Six Sigma project) for process improvement.

• Modeling Standards

  Process Management is vital for companies to meet and exceed their quality and efficiency demands. Specific business requirements are the starting point for modeling business processes by using modeling standards. The result is an overview of all processes as well as more detailed process levels.

• Release and Change Management Guidelines

  Release and Change Management guidelines will determine how change suggestions are processed, reviewed and put into production.

Mechanisms

• Process Modeling Tools

  Process Modeling tools such as Visio and Proactivity can be used to describe processes for review and approval.

• Process Mapping

  Process mapping sessions can be held to uncover AS-IS process models and to brainstorm TO-BE models.

• Change/Release Management

  Change and Release Management processes will be followed to place processes into production.

Outputs

• Process Model

  Process models consist of ICOM diagrams and flow diagrams describing process flows and interactions in a manner which facilitates understanding. Models are usually developed to describe current operations (AS-IS) model and desired operations (TO-BE) models.

• Gap Analysis

  The Gap Analysis is a formal deliverable itemizing the differences between the AS-IS and TO-BE models. It advances recommendations to implement the TO-BE process which recognize impediments to the kinds of changes which may be required by the movements.

• Request for Change

  An RFC is submitted through Change Management describing a needed change to how a process is operationalilzed in the production environment. The RFC lists any process simulations and methods for introduction of the new process (training, awareness campaigns, forms changes, database/system modifications, etc).

• Process Improvement Plan

  Where an underlying difficulty has been identified which is adversely impacting upon service quality, Service Level Management must, in conjunction with Process Management, instigate a Process Improvement Plan to identify and implement whatever actions are necessary to overcome the difficulties and restore service quality.

  Process Improvement Plan initiatives may also focus on such issues as organizational visioning or people, technology or cultural impediments to process quality. In these cases, the relevant stakeholders need to be involved and adequate feed-back given to make improvements for the future. At any time, a number of separate initiatives that form part of the Process Improvement Plan may be running in parallel to address difficulties with a number of services or processes.

Process Activities

Develop Process Modeling Infrastructure

• Develop a vision for process improvement - what a process oriented organization will look like
• Develop an Enterprise process management focus
• Develop common standards for language and definitions
• Integrate process related activities across the IT entire organization
• Develop and Integrate process definitions and a governing policy framework. Specify the critical attributes of process elements
• Specify the relationships of the process elements
• Define and populate the roles of process management - the Process Manager, Consultants, Process owners and organizational coordinating committee.
• Define and initiate a process training program
• Develop a process measurement methodology
• Roll-out process management
• Conduct regular review of process goals
• Develop Change Management procedures for modifying processes

The benefit of a more process centric IT organization is in the way work is undertaken and completed. Expected results and performance measurements will be better documented and become accessible to those who need them regardless of location. Thus, individual knowledge and experiences become corporate knowledge and procedures and work become regularized with less variation between instances. Work becomes more predictable and to established and measurable standards.

Define Tailoring Criteria

Establish the Measurement Repository

Establish and Maintain the Process Asset Library

Current State : AS-IS Modeling (baselining)

TO-BE Modeling

The following are some of the core questions that need to be answered when modeling process improvements.

• If the process is changed and some of the tasks eliminated, simplified or automated, how much will be the new throughput or cost savings?
• Will key bottlenecks be removed once the process is changed?
• What will be the new throughput and costs for each operation?
• How many units can be produced with the new process?
• What will be the resource requirements to run the new process?
• Can resources be redeployed and savings generated with the new process?

Gap Analysis

Information from all sources should be considered in order to validate and clarify survey results. Many gaps may be cultural in nature and require ample time to correct. Gaps in IT skill enhancement and organizational change may be significant.

Develop Release Plan

Develop Implementation Plan

Working According to Process Descriptions

Revise Process

Retire Process

• Submission of an RfC to remove the process.
• Approval to do so through Change Management.
• Retiring the CI from the CMDB.
• Removing the process description (or archiving it) from the DSDL.

Appendix

Input, Control, Output, Mechanism (ICOM) Descriptions

Integration Definition for Function Modeling (IDEF0)

ICOM Approach

• Inputs - are things or information needed to do the activity or process. Inputs are transformed by the activity^R.
• Controls - govern why or how you do the activity. For example, policies, laws, regulations and guidelines are controls. Business rules are primary examples of Controls
• Outputs - are the things or information that the activity creates
• Mechanisms - are the way you do the activity, or what supports the activity. The activity's direct costs will be related to the mechanisms. The organization's ability to perform the activity will be directly affected by the maturity of the mechanisms it uses to achieve its' outputs.
• Activities - are sub-tasks or specific deliverables which are completed as part of the activity or process under consideration. Each activity can, itself, be subject to a de-composition using ICOM as a structuring tool

Process Modeling Tools

Beyond this, there is a new class of business mapping capability occurring with the introduction of Business Process Management (BPM). As BPM continues to develop and mature, you can anticipate the development of products and solutions that help the business to integrate its process management, performance management, and information management strategies. From a position of closer process management, businesses may be able to respond more rapidly and with greater confidence. Information generated at the process layer will be fed back for analysis, giving the necessary management controls and a closer understanding of the cause-and-effect relationships that exist between process elements and indeed between disparate processes. As a consequence, change management will become less fraught with risk and danger.

CMMI Maturity Levels

Level 3 Maturity - Defined Processes

Organizational Process Focus

Candidate improvements to the organizational process assets are obtained from various sources, including measurement of the processes, lessons learned in implementing the processes, results of process appraisals, results of product evaluation activities, results of benchmarking against other organizations' processes, and recommendations from other improvement initiatives in the organization.

Process improvement occurs within the context of the organization’s needs and is used to address the organization's objectives. The organization encourages participation in process-improvement activities by those who will perform the process. The responsibility for facilitating and managing the organization's process-improvement activities, including coordinating the participation of others, is typically assigned to a process group. The organization provides the long-term commitment and resources required to sponsor this group.

Careful planning is required to ensure that process-improvement efforts across the organization are adequately managed and implemented. The planning for process-improvement results in a process-improvement plan. The process-improvement plan will address appraisal planning, process action planning, pilot planning, and deployment planning. Appraisal plans describe the appraisal timeline and schedule, the scope of the appraisal, the resources required to perform the appraisal, the reference model against which the appraisal will be performed, and the logistics for the appraisal. Process action plans usually result from appraisals and document how specific improvements targeting the weaknesses uncovered by an appraisal will be implemented. In cases in which it is determined that the improvement described in the process action plan should be tested on a small group before deploying it across the organization, a pilot plan is generated. Finally, when the improvement is to be deployed, a deployment plan is used. This plan describes when and how the improvement will be deployed across the organization.

Organizational Process Definition

The organization's process asset library is a collection of items maintained by the organization for use by the people and projects of the organization. This collection of items includes descriptions of processes and process elements, descriptions of life-cycle models, process tailoring guidelines, process-related documentation, and data. The process asset library supports organizational learning and process improvement by allowing the sharing of best practices and lessons learned across the organization.

The organization's set of standard processes is tailored by projects to create their defined processes. The other organizational process assets are used to support tailoring as well as the implementation of the defined processes.

A standard process is composed of other processes or process elements. A process element is the fundamental (e.g., atomic) unit of process definition and describes the activities and tasks to consistently perform work. Process architecture provides rules for connecting the process elements of a standard process. The organization's set of standard processes may include multiple process architectures.

Organizational Training

An organizational training program involves:

• Identifying the training needed by the organization
• Obtaining and providing training to address those needs
• Establishing and maintaining training capability
• Establishing and maintaining training records
• Assessing training effectiveness

The identification of process training needs is primarily based on the skills that are required to perform the organization's set of standard processes. These skills and knowledge may be:

• Technical skills pertain to the ability to use the equipment, tools, materials, data, and processes required by a project or process.
• Organizational skills pertain to behavior within and according to the employee's organization structure, role and responsibilities, and general operating principles and methods. [Note]
• Contextual skills are the self-management, communication, and interpersonal abilities needed to successfully perform in the organizational and social context of the project and support groups.

Effective training requires assessment of needs, planning, instructional design, and appropriate training media (e.g., workbooks, computer software), as well as a repository of training process data. As an organizational process, the main components of training include a managed training-development program, documented plans, personnel with appropriate mastery of specific disciplines and other areas of knowledge, and mechanisms for measuring the effectiveness of the training program.

Certain skills may be effectively and efficiently imparted through vehicles other than in-class training experiences (e.g., informal mentoring). Other skills require more formalized training vehicles, such as in a classroom, by Web-based training, through guided self study, or via a formalized on-the-job training program. The formal or informal training vehicles employed for each situation should be based on an assessment of the need for training and the performance gap to be addressed. The term “training” used throughout this process area is used broadly to include all of these learning options.

Success in training can be measured in terms of the availability of opportunities to acquire the skills and knowledge needed to perform new and ongoing enterprise activities.

Level 4 Maturity - Quantitatively Managed Processes

Organizational Process Performance

The common measures for the organization are composed of process and product measures that can be used to summarize the actual performance of processes in individual projects in the organization. The organizational data for these measures are analyzed to establish a distribution and range of results, which characterize the expected performance of the process when used on any individual project in the organization.

In this process area, the phrase “quality and process-performance objectives” covers objectives and requirements for product quality, service quality, and process performance. As indicated above, the term “process performance” includes product quality; however, to emphasize the importance of product quality, the phrase “quality and process performance objectives” is used rather than just “process-performance objectives.”

The expected process performance can be used in establishing the project’s quality and process-performance objectives and can be used as a baseline against which actual project performance can be compared. This information is used to quantitatively manage the project. Each quantitatively managed project, in turn, provides actual performance results that become a part of the baseline data for the organizational process assets.

The associated process performance models are used to represent past and current process performance and to predict future results of the process. For example, the latent defects in the delivered product can be predicted using measurements of defects identified during the product verification activities.

When the organization has measures, data, and analytic techniques for critical process and product characteristics, it is able to do:

• Determine whether processes are behaving consistently or have stable trends (i.e., are predictable)
• Identify processes where the performance is within natural bounds that are consistent across process implementation teams
• Establish criteria for identifying whether a process or process element should be statistically managed, and determine pertinent measures and analytic techniques to be used in such management
• Identify processes that show unusual (e.g., sporadic or unpredictable) behavior
• Identify any aspects of the processes that can be improved in the organization's set of standard processes
• Identify the implementation of a process which performs best

Level 5 Maturity - Optimizing Processes

Innovation and Deployment

The term “improvement,” as used in this process area, refers to all ideas (proven and unproven) that would change the processes and technologies to better meet the quality and process-performance objectives.

Quality and process-performance objectives might include:

• Improved product quality (e.g., functionality, performance)
• Increased productivity
• Decreased cycle time
• Greater customer and end-user satisfaction
• Shorter development or production time to change functionality, add features, or adapt to new technologies

Achievement of these objectives depends on the successful establishment of an infrastructure that enables and encourages all people in the organization to propose potential improvements to the processes and technologies. Achievement of these objectives also depends on being able to effectively evaluate and deploy proposed improvements to the processes and technologies. All members of the organization can participate in the organization's process- and technology-improvement activities. Their proposals are systematically gathered and addressed.

Pilots are conducted to evaluate significant changes involving untried, high-risk, or innovative improvements before they are broadly deployed.

Process and technology improvements that will be deployed across the organization are selected from process- and technology-improvement proposals based on criteria:

• A quantitative understanding of the current quality and process performance
• The quality and process-performance objectives
• Estimates of the improvement in quality and process performance resulting from deploying the process and technology improvements
• Estimated costs of deploying process and technology improvements, and the resources and funding available for such deployment

The expected benefits added by the process and technology improvements are weighed against the cost and impact to the organization. Change and stability must be balanced carefully. Change that is too great or too rapid can overwhelm the organization, destroying its investment in organizational learning represented by organizational process assets. Rigid stability can result in stagnation, allowing the changing business environment.

Improvements are deployed, as appropriate, to new and ongoing projects. In this process area, the term “process and technology improvements” refers to incremental and innovative improvements to processes and also to process or product technologies.

The informative material in this process area is written with the assumption that the specific practices are applied to a quantitatively managed process. The specific practices of this process area may be applicable, but with reduced value, if the assumption is not met.

The specific practices in this process area complement and extend those found in the Organizational Process Focus process area. The focus of this process area is process improvement that is based on a quantitative knowledge of the set of standard processes and technologies and their expected quality and performance in predictable situations. In the Organizational Process Focus process area, no assumptions are made about the quantitative basis of improvement.

Process Description Template

Revision History

Objectives

• a clear understanding of the components of success (ie. critical success factors),
• what are the interactions the product will have with external sources,
• what strategic and tactical organizational criteria are being satisfied (note: strategic-focused processes will explicitly include provisions for improvement over time, whereas, tactical-focused products will involve quick, immediate returns such as reengineering efforts)
• is the product generally-based or one-time - in the latter case competence must be designed into the task itself because interactions between operations are more likely unique (note: organizations that are averse to process-oriented modes of thinking often inadvertantly create one-time products).
• is the product to meet a specific or broadly based need. Processes that create products for a very specific and unique purpose must have the needs designed into the process,
• who is going to use the product, where and when

Process Characteristics

The benefits of defining the scope are:

• Dividing a complex process into achievable chunks.
• Defining the features that will be in each process description.
• Allowing flexibility for change.
• Providing a baseline for trade-offs.

The scope of processes and its activities must be defined and managed as well as the scope of work and services being provided by the process team.

Assumptions list beliefs which must be shared for the process objectives and policies and guidelines to be logically valid. If the assumptions are not widely shared then business objectives may be be aligned properly and the entire process may not be accomplishing what it is intended to.

Inter-relationships describe how this process relates to others - both ITIL and ITSM derived internal processes. Inter-relationships imply dependencies. It is important to understand the risks that are associated with a dependency. Misunderstood dependencies can doom a project before it has even started.

Policies and Guidelines

Scaling

Ramping up a process can occur for two primary reasons:

1. accommodate increased workload, or,
2. increase the maturity with which the process is delivered.

In small IT units one group (or individual) may have responsibility for a wide variety of processes. Typically such a person or group is much more effective in performing one role better than the others. Which of the processes is done most effectively is determined by the range of personalities and skills in the group. Conversely, a large enterprise is able to allocate individual processes to specialist groups comprising people with specialist skills who also have a personality that is a good match for the process. However, over-specialization has its disadvantages - it can be perceived as tedious and de-motivating if an individual is simply left in place without looking after their needs and aspirations.

The second dimension exists when the organization wishes to enhance the maturity of the process. The description for respective levels of maturity are described by CMM and within COBIT for each of 34 descriptive governance processes. Each of the best practice processes as described by ITIL exists naturally at a certain maturity level (though collectively COBIT suggests they exist between level 2 (repeatable processes) and level 3 (defined processes). However, in most instances the process can exist with certain characteristics at a specific level. In order to increase the processes maturity additional processes, toolsets and approaches must be added to support the process. In many instances, this will include the ability to manage internal processes since this is a direct an important characteristic of a Defined maturity level.

Basic Concepts

Performance Measures

Roles and Responsibilities

Process Descriptions

Appendix

Six Sigma Project Overview

Define

• Project Scope visually related in a Business Interaction Model.
• Critical Goal Model based upon "the Voice of the Customer."
• Association matrices of critical goals to business deliverables and business processes.
• Supplier-Input-Process-Output-Customer (SIPOC) Model for each business process.
• Impacted roles optionally structured in an Organization Model.

Measure

Analyze

• Cause and Effect Model
• Association matrix showing the impact on critical goals by current problems
• Detailed "As-Is" Workflow Model
• Simulation results of the current process highlighting process problems

Improve

• Opportunity Model
• "To Be" Workflow Models showing possible solutions
• Simulation results of the proposed solutions to evaluate alternatives
• Association matrix comparing opportunities to problems

Control