Too often, IT professionals jump from strategy right into implementation without doing the proper due diligence in collecting, analyzing and recording detailed customer requirements. The ITIL Service Design book defines three levels of requirements: Functional, Management / Operational and Usability. It gives us in-depth descriptions of Functional requirements and Management/Operational requirements but leaves me a bit empty when it comes to Usability requirements. The definition is as follows, “The primary purpose of usability requirements is to ensure that the service meets the expectations of its users with regard to its ease of use. To achieve this: Establish performance standards for usability evaluations Define test scenarios for usability test plans and usability testing. I like to define this as “User-ability”. Service Design (Section 5.1.1) describes this as the ‘look and feel’ needs of the user that facilitates its ease of use. Usability requirements ar

HDI (formerly Help Desk Institute) recently released its 2009 Practices and Salary survey and reports that an incident resolved via the telephone costs $22, while an incident resolved via self-help costs $12. Furthermore, 11 percent of the organizations surveyed report that self-help tools are prompting a decrease in the number of incidents reported to the Service Desk. Having said that, these organizations also report that only three percent of incidents are resolved via self-help. With the Baby Boomers retiring and technically savvy Gen Y joining the workforce – and, oh yeah, the economy – the time has come to get serious about self-help as a support channel. Many think the solution lies in finding and installing the right technology; however, new technology projects often fail from a lack of preparation and management. Here’s where the four Ps come in to play. Introduced in the ITIL Service Design publication, the four Ps – in the context of self-help – include: People – How can yo

Sandy, if you have any more questions, just let me know! Standard Operations and Maintenance is really something that gets defined in the Service Level Agreement in consultation and negotiation with the customer. It is not really a determination made solely by IT or Operations. It is the customer or receiver of service that helps to establish whether an “outage” has occurred. Because we want to adhere to the terms and conditions set forth in the SLA we want strong controls in place. I think it is not a question as to whether the Change Management process will be used or not used. It is more a question of the degree of Change Management that will be used. A solid approach would be to establish a clear definition of a Service Change in the organization. ITIL says it is any “addition, modification or deletion of elements of the delivery of service” [paraphrased]. This is a broad definition and covers just about everything we do in IT. So, next we need to identify what we actually do in

Thanks for the great question Beverly. ITIL V3 and PMBOK Project Management are both best practices that fall under the larger umbrella of IT Service Management (or really just overall Service Management). ITIL focuses on the lifecycle of services, while PMBOK focuses on the lifecycle of projects. Services are all of the things we do to deliver value to our customers. In effect services are a type of product. Projects are temporary (short term) endeavors we undertake to accomplish specific outputs. So we can look at projects as one mechanism or vehicle for establishing and delivering services, products, solutions, etc. The decision as to undertake a project will be made as a result of ITIL Service Strategy and Service Design. The project team may then use PMBOK best practices for accomplishing the goal, objective or output identified during Strategy and Design. Conceptually this places Project Management roughly equivalent to ITIL Service Transition activities (with some overlap to Ser

I often get asked the questions, "Where do I start with SACM? How do I implement this process?" In my experience, this is one of the most difficult processes to implement correctly. Let’s discuss the first activity of the SACM process of Planning . In this activity, decisions will be made about the scope of what needs to be controlled in your organization. What level of configuration management is required? How will that desired level is achieved? Do you gather information about a service or about specific components? Do you need to control assets which are causing your customers the most pain points? When do you establish a controlled configuration, how do you change a controlled configuration, and what amount of resources are you going to expend to manage configurations? All of these decisions must be documented and formalized within the configuration management plan. Configuration Management Plan: · Context and Purpose · Scope · Requirements · Applicable policies and stand

Every ITSM framework and standard references the need to meet "customer requirements". Unfortunately, there is less attention paid to the process of collecting and managing those requirements. I am happy to report that the ITIL Service Design book contains some good high level guidance on "Requirements Engineering" (Section 5.1). Requirements Engineering is defined as "the approach by which sufficient rigor is introduced into the process of understanding and documenting business and user requirements and ensuring traceability of changes to each requirement." The section goes on to to describe a Requirements Catalog for documenting and managing changes to requirements. It also describes techniques and tools for gathering, analyzing and validating requirements with customers. ITIL defines three levels of requirements: Functional, Management and Operational and Usability. The Service Design book is particularly good for those who do not have a background in

This is perhaps one of the most important yet challenging questions in all of IT Service Management. In fact it makes ITSM possible (given the realization that it is IT Service Management). I pondered this question while having lunch and catching up on some industry reading about value and customers. The ITIL© V3 definition of a service is as follows: A service is a means of delivering value to customers by facilitating outcomes customers want to achieve without the ownership of specific costs and risks. So given this definition, how do we know what exactly is a service? As a result of my pondering (and some sauce spilled on my blazer from my lunch) I came to a conclusion. Simply, a service is anything you do to help other people accomplish a goal. In other words it is “work done for other people”. If a person could accomplish the work themselves, would they need service provided to them? Maybe, but often, they can’t do it as well, as cheaply, etc. As an example, let’s go back to the s