I often get questions on the differences and similarities between the Software Development Lifecycle (SDLC) and the ITIL Application Management Lifecycle. Is the ITIL framework just another rebranding of SDLC? SDLC defines the organization’s standards for the creation and maintenance of applications. The SDLC can be divided into ten phases during which defined IT work products are created or modified. The phases range from initiation, design, development, implementation, operations & maintenance to disposition. The tenth phase, disposition, occurs when the system is disposed of and the task performed is either eliminated or transferred to other systems. The ITIL Application Management Lifecycle presents a more holistic, service-oriented view. It allows for greater alignment between the development view of the applications and the live management of those applications. This ITIL lifecycle focuses on the overall management of applications as part of IT services. Understanding the c

Rusty asked: I was looking for terms used for categorizing the impact of a change, I remember in Version 2 of ITIL that changes where categorized as Major, Significant, Minor and Standard is that no longer done? Or is the Imapct also defines as the priority High, Medium, and Low Rusty, I’m going to give you my answer in three parts. This information can also be found in Section 4.2 of your Service Transition Book.   In ITIL V3 changes are now categorized into three distinct types:   • Standard Change: Change to a service or infrastructure for which the approach has been pre-authorized by Change management that has an accepted and established procedure to provide a specific change requirement. It has a defined trigger, documented tasks and budgetary approval. The risk is low and well understood. • Normal Change: Change to a service or infrastructure for which the risk must be assessed and must go through the Change Advisory Board (CAB). These are Changes that happen either on

One of the most important yet often less fully considered aspects of using Service Management is Organizational Change Management. When it comes down to it, Service Management is about people—as customers, users, providers, maintainers, supporters and a myriad of other roles. So while we get caught up in getting effective, efficient and economical services, processes and technologies in place to provide value, we must not push aside the importance of attitude, behavior and culture. We have all encountered new situations, changes in process or work flow, new technologies and other unfamiliar situations. Most people recognized from experience that different people deal with change in different manners. But we do not have to rely simply on hearsay or belief or personal experience. We can turn to experts in the field of Organizational Change Management for a way to work through the adoption of new ideas, approaches and technologies. In 1962 in his work Diffusion of Innovations, Everett

Paul recently asked; Hello, When browsing on the topic of Service Requests, I visited your site where a question was answered on the differences and similarities of Service Requests and Standard Changes. I was triggered by the following passage: "It is important to note that not all Service Requests are Standard Changes. Service Requests can include questions, queries, complaints and compliments. Similarly, not all Standard Changes are Service Requests. Standard Changes can include batch jobs, patches and other low risk changes that are not "requestable" by the user. Any Service Request or Standard Change that presents a higher risk may require reassessment and reclassification by Change Management." I am trying to think of a term that would differentiate the one from the other. Considering that there are Service Requests that may invoke a Standard Change, I can see two possibilities: it may be a Standard Change that can be requested by any end-user or it ma

You can’t always go home again, but you can use Continual Service Improvement (CSI) to meet the changing needs of your customers. I recently posted a blog about returning to a service desk I had managed and spoke about how the changing business environment had impacted management’s ability to sustain the current list of Critical success factors (CSFs) and Key Performance indicators (KPIs). The 1st question that was asked was “What should we measure?” Within the new business reality we reviewed how the corporate vision, mission, goals and objectives had changed? We spoke with service owners, business process owners, business analysts and customers and asked what was critical to them. What services that we were providing was creating the most value to them and enabling them to meet these new goals and objectives? Management then identified the gaps of “what we should measure”, to “what we can measure”. From this a more customer focused list was developed. The overriding objective

One of the things that troubles me at times is how often people try to make the world more complex than it needs to be. The world is really a rather simple place if you take the time to step back and avoid complexity. I recently read a statement that made think upon this problem again. The opposite of “simple” is “elaborate”, not “complex”— Dan Roam, The Back of the Napkin What people call complex, may in reality be elaborate. They confuse the two ideas. This can lead to issues in the delivery of Business and IT Services to customers. If someone believes a service is too complex they can often be less willing to make the effort to provide the service, or support it or improve it. Most likely the service is just elaborate (having lots of underpinning elements and components), not really complex (being of a nature that is difficult to understand). So how do we move away from complexity and towards seeing Service Management in terms of simplicity and elaboration? Here are several tech

I recently posted a blog about returning to a service desk I had managed and spoke about how the changing business environment had impacted management’s ability to sustain the current list of Critical Success Factors (CSFs) and Key Performance indicators (KPIs). The 1st question was “What should we measure?” Within the new business reality, we reviewed how the corporate vision, mission, goals and objectives had changed. We spoke with service owners, business process owners, business analysts and customers and asked what was critical to them.  We could then determine the services that were creating the most value  and enabling them to meet these new goals and objectives. Management then identified the gaps of “what we should measure”, to “what we can measure”. From this, a more customer-centric list was developed. The overriding objective of these new service measurements was to provide a meaningful view of the IT service as experienced by our customers. The three key areas that cu