When it comes to processes, W. Edwards Deming stated that there are only two choices: execute the process or improve the process. When it comes to improving a process we have three basic paths we can follow: develop the process (if it does not exist), redesign the process (if it is sore need of fixing) or improve the process (tweaking it in incremental ways). So let’s explore each of these paths in a little more depth. Develop the Process: This path occurs when you really do not have a process. You might have some loosely followed procedures or perhaps steps that people follow in their heads. There is no formally defined, developed or documented process. This path allows you to start from the beginning by gathering requirements for the process, creating a process definition document and then implementing the process. This path takes the longest time and in some ways the most work. Redesign the Process: This path occurs when the process you have in place just does not provid

C hris Argyris is one of the most important and influential thinkers in the last 100 years. Yet, few people are aware of his efforts in organizational development and human behavior. Argyris wrote about a number of different areas of organizational change management. Perhaps one of his most important contributions has been in the area of Single-loop and Double-loop learning for individuals and organizations. Single-loop learning is when an individual or group undertakes an action and the result is not what they expect or believe be the result should be. So they go about “correcting” their approach on the assumption that they must have done something “wrong” the first time. As a result of the “correction” they expect a different result. Some of you may recognize this as the classic definition of “insanity”. Others have called these “self-fulfilling” prophecies. Doing the same kinds of things over and over and expecting different results. Single-loop Learning results from creating what

The Professor was recently asked about the following very interesting situation. In my organization, we have a service desk that is not part of the main IT department.  Since we are a service desk solution provider, it is actually in one of our businesses units.  So our IT department has chosen to take advantage of that in-place service desk to effectively also be the service desk for internal employees.   Is this a situation where an operational level agreement (OLA) applies?    Or are the “parts” of the internal organization too far apart and a service level agreement (SLA) is more appropriate? I think the idea is that the OLA applies to different internal groups within IT?   Is that true? Let’s first define these terms and then apply them to this situation. An SLA is an agreement between a service provider and a customer. In the case of the service desk that is in one of the company’s business units, that service desk is a Type I (internal) service provider. Since ITIL is non-p

Trends such as mobile computing, consumerization (also known as bring your own device (BYOD), and cloud computing are having a dramatic impact on the service desk. These trends are prompting many organizations to evaluate and improve their existing service management processes , or implement new processes where needed, and to rethink the role the service desk plays in implementing, executing and improving these processes. It would be easy to look at these trends and think of them only as the deployment of new technologies but there are bigger considerations at stake. What services are these technologies enabling? What business processes do these services underpin? How is the business impacted when these services are interrupted? An important key performance indicator (KPI) for service catalog management is whether the service desk has the information that it needs about those services and their associated interfaces and dependencies. This is because the service desk plays

When I teach ITIL foundation classes and we start talking about aligning IT strategy with business strategy, I usually see some puzzled looks on the faces of my students.   So I thought I would give some basics on what we are trying to establish here. The purpose of strategy management for IT services is to create a process for defining and maintaining an organization's perspective, position, plans and patterns related to its services and the management of those services.    The purpose of a service strategy is to communicate how a service provider will enable an organization to achieve the desired business outcomes and establish the criteria and mechanisms to decide which services will be delivered, to whom they will be delivered to and to establish the most effective and efficient way to manage these services. The objectives of strategy management for IT services are: Analyze the internal and external environments in which we (the service provider) exist and to identify

Designing and documenting a process enables an organization to move from the initial level of the ITIL Process maturity Framework (PMF) through the repeatable level to the defined level.   To undertake this task without adequate resources can be quite daunting especially given the fact that it must I dentify needed changes to job descriptions Develop and document work procedures Identify work requirements Establish the data to be collected and the format to report accomplishments D ocument the necessary vocabulary to be utilized within the process The following ten process design and improvement steps can be used to create an easy to use and repeatable approach to help move your organization from one level to the next.   The ten steps are grouped into four phases.   Each phase will produce a deliverable that serves as an input to the follow phase. Phase: Requirements Definition.    Output: Requirements Definition Document. 1.     Determine the management’s vision and level

Service Level Management (SLM) is the process that is responsible for the overall agreeing and documenting Service Level Targets (SLT) and the responsibilities within Service Level Agreements (SLAs) and Service Level Requirements (SLRs) for every service and related activity within IT. The SLA is effectively a level of guarantee or warranty with regard to the level of service quality delivered by the service provider for each of the services supplied to the business.   The accuracy of the SLAs, SLRs and SLTs and the overall success of SLM is very dependent on the quality of the service portfolio and service catalogue and their contents because they provide the detailed information on the services to be managed within the SLM process. With that said the purpose of the SLM process is to certify that all current and planned IT services are delivered in accordance with agreed achievable targets.   This is normally accomplished by SLM through a continuing cycle of negotiations, agreem