I've been hearing a lot lately about "going back to the basics" of ITIL and IT Service Management.  So for the first half of 2013, I'm going to package and republish the best of my blogs for each lifecycle stage.  As always, I welcome your comments and questions!   ~~ ITSM Professor Utility and Warranty Equals Value Originally published October, 2012 When a service provider is developing a service for a customer or group of customers the underlying goal is to ensure that the service has value for the customers by meeting a set of defined requirements.    The value is often defined by what the customer is willing to pay for this service rather than what it actually cost the service provider to produce the service or any other essential feature of the service itself. Services themselves do not actually have intrinsic value.   That value is created by the outcome enabled by employing the service and therefore the value of the service is not determined by the provid

I often get asked where change evaluation takes place.   Isn’t it part of change management?   It is a separate process however it is driven by change management and is triggered by the receipt of a request for evaluation from Change Management. Inputs come from several processes including the SDP and SAC from Design Coordination, change proposal from SPM, RFCs, change records and detailed change documentation from Change Management.   It holds discussions with stakeholders through SLM and BRM, testing results from service validation and testing to ensure that its members have a full understanding of the impact of any issues identified and that the proper risk assessments can be carried out against the overall changes and in particular the predicted performance, intended affects, unintended affects and actual performance once the service change has been implemented.    The purpose of change evaluation is to provide a uniform and structured means of determining the performance of a c

In an earlier blog I spoke to the conflicts that all operational organizations face.   This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more towards one extreme or the other.   At a high level it can provide the service provider with the opportunity to develop some guidelines on how to resolve these conflicts and move towards a best practice approach in resolving discrepancies.   We talked to the first and most common which was the Internal IT view vs. the External Business view.   Today I would like to speak to the dilemma of Stability vs. Responsiveness. IT operations must ensure that the IT infrastructure is stable, performs at an agreed and defined levels on a consistent basis and is available with the correct amount of capacity to meet the demands of ever changing patterns of business activity. These changes can be evolutionary.   Needed changes in functionality, performance

In every organization the one constant is change.   In operation all functions, processes and related activities have been design to deliver specific level services.   These services deliver defined and agreed levels of utility and warranty and doing so while delivering an overall value to the business.   The catch is this has to be done in an ever changing environment where requirements, deliverables and perceived value changes over time.   Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.   One of the key roles of service operation together with processes from the other stages of the life cycle is to deal with this tension between these ever changing priorities. This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more to

I recently had the chance to encounter a very telling situation about the modern world. A presenter was talking about how the college age generation (the future employees of IT and business) was moving away from what he called “old style web pages”. That is full web sites and pages overloaded with content and information that requires someone to commit time to actually “reading”. The preferred communication approach for the upcoming generations is rather the “text” or “tweet”—140 or so characters of information or knowledge spun into the universe as snippets of data, information, knowledge and wisdom. Older generations are capable of producing such ‘text bites” of knowledge, but generally see them as links or parts of a much bigger activity called a conversation. For the future those “texts” and “tweets” will be the whole conversation or story: beginning, middle and end in 140 characters or less. It brought to mind the importance of coupling existing knowledge management with new or

A question arose recently concerning the relationship between Service Management and Project Management. This is a topic of interest to many people since on the surface both approaches seem to be fighting for some of the same work space in organizations. When we go back to the basic definitions of each we can see that the two are not in conflict, rather are very complementary. However, the relationship may not be as many people expect. I have found that the relationship is one of time: short term bursts of creation activities (outputs) inside a larger ongoing management lifecycle (outcomes). Let us start with the definition of service and service management (according to ITIL ® ): Service : A means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks Service management (SM) : A set of specialized organizational capabilities for providing value to customers in the form of services.  Both of these de

I recently had the opportunity to chat with a practitioner about the importance of knowledge management and had to smile when she declared that ‘knowledge management is back.’ The premise of the comment was that early attempts at knowledge management were unsuccessful as organizations seemed to think that the knowledge was going to ‘magically’ appear. Gartner speaks to the fact that organizations also often focused on collecting knowledge, rather than dispersing it. It has taken the IT industry a while to understand that there needs to be a strategy for knowledge management that culminates in the right information being delivered to the right place or person at the right time. Doing that successfully requires a process, methods, policies, procedures, tools, and metrics. Another consideration is the shifting of generations in the workforce. Think about it. How do young – or young at heart – people solve problems today? They Google or Tweet and draw upon the knowledge and exp