When discussing the elements of value creation through the delivery of services we always talk about customer preferences, perceptions and the business outcomes they generate.  We also throw in the elements of utility and warranty.  These are all critical in ensuring our ability to create value for our customers and capture value for ourselves as service providers. The service relationship between service providers and their customers revolves around the use of and interaction of assets.   Assets are made up of both resources and capabilities and are provided by both the service provider and the customer.  These are critical value elements in the creation of usable, customer aligned services. Many of our customers utilize our services in conjunction with their own assets to then build and deliver services or products our customers then deliver to their customers. We, as the service provider, consider these customer assets.  Without these there would be no basis for defining th

I was recently asked what the compliance requirements, architectural constraints and interface requirements are in designing the service design package for a new app. The short answer is that the Service Design Package (SDP) would have ALL of the documents and information related to how the app was designed and developed including any policies or known compliance or other constraints.  The purpose of the SDP is to provide a living set of knowledge assets that can be passed around the lifecycle for use in each stage (e.g. deployment, operations, support, updating, etc.). For more information the the SDP please use this link:  http://www.itsmacademy.com/itil-sd/

Operating under a constant threat of cyber attacks is the new normal for many organizations in today’s virtual business environment.  These attacks can come from anywhere, from anybody and at any time.  It is no longer a question of reacting to and then fixing the problem.  Today the question is “How do we prepare the entire organization to be prepared and vigilant to deal with cyber security threats each and every day. A defensive approach is no longer adequate.  A proactive strategy by cyber security teams with the appropriate expertise, capabilities and best practice processes and policies is an absolute must have in order to meet the challenge of recurring engagement with those whose intent is to harm the organization in some way. There must be well defined and documented processes to prevent, where possible, detect and respond with control and countermeasures as quickly as possible while predicting what will happen next.   The introduction of effective cyber resilience requir

When an organization is planning on a major change that will incur significant cost, risk, time and engagement of resources along with organizational impact, it is best practice to initiate this activity through the Service Portfolio process.  Before this new or significantly changed service is chartered, it is important that it be reviewed for how it may impact the short, medium and long term support of other services currently being delivered, the pool of limited resources that will be utilized for this undertaking and on the change schedule itself. The Change Proposal is used to communicate a high level description of the change and is normally submitted to Change Management for authorization.  Authorization, however, is not an approval for implementation, but is a measure to allow the service to be chartered so design activity on the service can begin. In some cases the proposal may be created by someone other than Portfolio Management, such as the PMO or SMO. This high le

A systems engineer recently asked “With all of the buzz around Agile and DevOps, is ITIL Foundation training and certification still relevant?”   The short answer is yes and its relevance is directly tied to the success of strategic initiatives and the outcomes of the organization.  There is direct benefit to the learner/candidate also.  It has been a while since this has been discussed so let’s revisit this once again. For the Consultant or Third Party Vendor: Gets you on the short list! -  ITIL Foundation training gives those who are consulting in any area of “Service Management” a standard set of vocabulary critical to communication.  Also, knowing the terms and basic concepts is crucial to the credibility of the consultant.  The improper use of a single term that is known by your customer could give the impression that you as the consultant do not know the industry and omit you from the short list.  Some organizations will not even consider a vendor without the proper certi

I was recently asked to comment on the importance of Demand Management for IT Services as it relates to the IT Business organization. Demand Management Demand Management is tied to the “Customer” or consumer demand. It is more about the market and what is the demand from that level. Strategic Example Strategic Demand Management might be a business strategy for how to influence user behavior. The telecom industry a few years back offered “Free nights and weekends”. This was a “Strategy” to manage the “Demand” until the provider could get all of the infrastructure laid down to support the demand for service. Tactical Example Within the activities of “Demand Management “ are those that are defined to monitor, manage, and report upon the patterns of business activities (PBA) and the activities of the varied user profiles (UP’s) . Demand Management would provide the UP’s and PBA’s and work very closely with Capacity management (managing workload at the component level to meet

I was recently asked to clarify the roles of the Process Owner, Process Manager and Process Practitioner and wanted to share this with you. Roles and Responsibilities: Process Owner – this individual is “Accountable” for the process. They are the goto person and represent this process across the entire organization. They will ensure that the process is clearly defined, designed and documented. They will ensure that the process has a set of Policies for governance. Example: The process owner for Incident management will ensure that all of the activities to Identify, Record, Categorize, Investigate, … all the way to closing the incident are defined and documented with clearly defined roles, responsibilities, handoffs, and deliverables. An example of a policy in could be… “All Incidents must be logged”. Policies are rules that govern the process. Process Owner ensures that all Process activities, (what to do), Procedures (details on how to perform the activity) and the

Underlying and supporting the  Agile Manifesto  are the twelve principles that help to bring the Agile philosophy to life. The DevOps movement encourages us to adopt and adapt these principles into the ITIL lifecycle not to reinvent it, but to allow us to make it spin faster.  Let’s take a look at them individually and interpret them from an ITIL, operational and support perspective. Our highest priority is to satisfy the customer.   We do this through early and continuous delivery of the proper utility & warranty. Welcome changes, even late in development, by using well defined and nimble change, release and deployment management, teams and models, allowing our customers to remain competitive in their given market spaces. Deliver updated working services frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. OK that one I modified a bit. We’ll   be Agile about it. Business people and IT must work together daily and collaborate

ITIL is turning 25 this year.  In honor of this milestone, AXELOS commissioned a study ( The Importance of ITIL® – A Global View – 2014 and Beyond ) to provide a global and independent assessment of the current perception of ITIL, engaging nearly 400 C-Level and medium tier service managers in key international regions across a range of industries. One of the stated reasons that the study was commissioned is because ITIL’s benefits are being questioned in light of factors such as cloud computing, more advanced automation, and agile. The results of the study reaffirm ITIL’s value, particularly in the eyes of IT executives. In fact, according to the study, just under 70% of executives indicated that ITIL is becoming more important in light of these trends. Some interesting results include: 71% of those surveyed view ITIL as playing a tangible role in supporting the move to DevOps and Agile  ITIL 2011 adopters are more likely to see ITIL as growing in importance   40%

As business organizations opt for support from the cloud to provision Software, Platform, or Infrastructure services the need for warranty through the service value chain becomes paramount. Service warranty is gained by achieving specified levels of availability, capacity, continuity, and security.  The dynamic, nature of the business and varied demand from multiple customers and user profiles must be considered when defining and investing in cloud architectures.  Each customer will expect that only their application or service will be delivered to users when in fact multiple customer and user communities could be leverage from the scalability and shared resources in the cloud. Availability/Capacity and the Cloud Service providers must gain assurance that multiple instances of the same application are delivered in a scalable manner.  In order to ensure availability and leverage capacity on demand additional tools and technologies such as load balancing, server virtualization

  An incident is an unplanned interruption to an IT service or reduction in the quality of an IT service and is strictly a reactive process. A problem on the other hand represents a different perspective of an incident by diagnosing its underlying root cause, which might also be the cause of multiple other incidents. Incidents however do not always grow up to become problems.  While Incident Management activities focus on restoring services to normal operations as quickly as possible, Problem Management activities determine the root cause, find the most effective and efficient permanent resolution and ultimately prevent the incident from happening again.    Problem Management can be both reactive and proactive. Proactive Problem Management identifies weaknesses in the environment before actual incidents occur.  These can then be exploited as improvement opportunities.   Reactive Problem Management addresses problems that were identified from one or more incidents.      The pol

“ Problem Management  seeks to minimize the adverse impact of incidents and problems on the business that are caused by underlying errors within the IT infrastructure and to proactively prevent the recurrence of incidents related to those errors.   In order to achieve this,  Problem Management  seeks to get to the root cause of incidents, document and communicate known errors and to initiate actions to improve or correct the situation”.    Given that statement is directly from the ITIL Best Management Practices text, it’s a wonder more organizations don’t have well integrated Problem, Incident and Change processes in their organizations. I never want to say that there is a single silver bullet solution for a given problem and I’m not suggesting that here.  However having a solid CMS (Configuration Management System) is a good step in the right direction.   Of course before we even think of tools we must have rules.  Thinking holistically we can create an integrated set of best p

Problem Management for Newbies (Part 2 of 2) In part one of “Problem Management for Newbies” we looked at reactive Problem management and how Problem Management can serve as a pillar of support to incident management.  Problem Management prevents, minimizes and eliminates future incidents and problems from occurring.  There will always be a need for reactive problem management.  IT support can never guarantee that there will not be outages and will always need clearly defined roles, skilled staff and governance for the resolution of incidents and problems when they occur.  Added value to the business is via proactive problem management!  Proactive Problem Management Proactive problem management will glean management information from the function of the service desk, and others across the organization.  By viewing and analyzing reports on frequency of incidents, types of incidents,  noting the times that incidents and problems occur and most importantly understanding the bu

Getting Started with Problem Management To understand the process of Problem Management one must first understand that a problem is distinctively different than an Incident.   It is tracked and recorded separately, it requires a very different skill set and has a different objective than those that are required for “Incident Management”.   Problem records are unique entities and are reported upon separately.   A repeatable lean problem management process could very well be the glue that helps IT Service providers integrate and automate much of the work and effort required to “prevent” “Eliminate” and to “Minimize” the impact of incidents on your business and end user customers. While an incident is an unplanned interruption that creates an impact to one or more business services, the problem is actually the cause of one or more incidents.    Example:   “I can’t access the ERP system”, “The web portal will not come up!”    “I can’t log in” are all examples of incidents.    The c

Prioritizing Changes Originally Published in 2011 The Professor recently received the following question: Having put together a spreadsheet of information that I need to assess the impact of a change,  what I need to do next is figure out how to assess the impact of a change as being high, medium, or low? Any guidance you can give me on how to do this would be greatly appreciated.” The  Service Transition book provides great guidance on assessing the impact of changes (ST 4.2.6.4). This section provides 7 questions that must be answered to fully understand the impact. Many of these questions are answered using information in your spreadsheet. Others you may want to consider adding.  Who RAISED the change? What is the REASON for the change? What is the RETURN required from the change? What are the RISKS involved in the change? What RESOURCES are required to deliver the change? Who is RESPONSIBLE for the build, test and implementation of the change?

We continue our "Best of" blog services by moving into Service Transition Who is the Change Initiator? Originally Published on July 21, 2010 The “change initiator” is the individual or group that is requesting the change. Change initiators could be users, suppliers or IT staff – depending on the nature of the proposed change. It is the change initiator’s responsibility to justify the reasons for making the change.  However, since the change initiator may not understand all of the risks associated with a seemingly innocuous change, some type of impact assessment should occur.  The assessment could be very simple and quick - or extensive- based on the scope of the change and business processes that are potentially affected. The change authority (CAB, Steering Committee, local CABs, etc.) assesses the impact of the propose change and determines if the change is necessary or beneficial.  Impact could be negative or positive and should consider cost/benefit, resources r

ITSM Requirement Gathering Techniques Originally Published February 20, 2010 In a previous discussion, we talked about the three levels of requirements in Service Design: Functional, Usability and Management and Operational. There is a range of techniques that can be used to actually obtain these services requirements. It is often difficult to get your customers to verbalize what they need. It has been my experience that the customers and the business are not completely sure of what their requirements actually are. They will need assistance and prompting from the designer or requirements gatherer. This must be done in a professional and sensitive manner to ensure that it is not seen as IT dictating the business requirement. We are all familiar with the most popular techniques, interviewing and workshops. The following is a list of additional techniques which might aid you in the Service Design requirements gathering stage: Observation: Watch your customers perform a spec

We continue our "Best of" blog series by  moving into Service Design. The Service Design Package Originally Published in 2010 I have gotten many questions about what value does the Service Design Package provide? We first must understand that all design activities are triggered by changes in business needs or service improvements. In order to design and deliver IT services that meet the changing needs of the customers and the business, clear, concise and unambiguous specifications of the requirements must be documented and agreed. The SDP is where we document and agree to Requirements – What the business wants and how they plan to use this new service. Define who all of the stakeholders are  Service Design – Functionality of this new or changed service (SOR). Service levels to be delivered (SLRs, SLAs). Operational management requirements (OLAs, Contracts). Overall design and topology. Defined outcomes and deliverables.  Organizational Readiness Assessment

What does the IT in ITIL® stand for? This question may seem easy to answer. The IT stands for “information technology”. But what does that really mean? Is there more than one way to answer the question of what the IT in ITIL® means? I believe there are more than one context or meaning for IT and we must be aware of the distinct meanings. Let’s take a look at some of the ideas or concepts behind IT. ·         IT as “information technology” : This most basic use of IT refers to the physical and technological pieces and components made up of electronics and operating/machine software. E.g. A desktop computer is IT as “information technology”. ·        IT as “management information systems (MIS)” : Computerized components that are used to manage, control and govern information used to run a business or organization. E.g. A customer relationship management system is IT as “MIS”. ·          IT as “collection of applications and infrastructure” : This umbrella use of IT encom

In order to create a successful foundation for our implementations of ITSM and ITIL® we can take lessons from the study of languages. The foundation of the service management best practices is a language that needs to be understood, mastered and used, just like you would learn a foreign or native tongue. When learning a new language there are two basic approaches one can take. You can study the grammatical theory and structure or you can do immersion learning. Language experts tell us that both are necessary actually to master or become fluent in a language. Immersing yourself in a language (such as ITIL) provides a conversational or daily usage basis. Think of this as having insight as to “how” the language works. Studying the theory and structure of a language (such as ITIL) provides for an understanding and knowledge basis. Think of this as having insight as to “why” the language works. Without theory there would be no usage since you would be unable to form new sentences, only