One of my favorite sets of analogies to use in class is food, the making of  food or restaurant operations. We make what we eat by pulling together ingredients into recipes. In the same way, we design services. We use the elements of services combined into the five aspects of design (solutions, tools, architectures, process and measurement) to produce the Service Design Package (SDP). When we think about designing services, we must remember it takes a number of elements. ITIL v3 says there are four elements of service design: People Process Products Partners I like to think of these elements as the “ingredients” of a service. The most important “ingredient” in any service is the “people”. We can have effective processes, efficient products, and loyal partners, but without people the service will get nowhere.   People are the elements that make the value for the customer truly possible. Processes do not execute themselves, products do not spontaneously build and partners are not

The Professor has been asked, “Does ITIL address Technology Lifecycle management?” In version 2 of ITIL, the ICT Infrastructure Management book focused on technology management.  This is still a good resource, although availability of the publication may now be very limited.   In Version 3, the same information is spread across the lifecycle - most heavily in Service Design, Service Transition and Service Operation.  There are a couple of updates in ITIL Version 3 for technology management.   Configuration Management is now "Service Asset and Configuration Management" so that Asset Management and Configuration Management are integrated.   Service Design now defines a Technical Service Catalog to acknowledge underpinning technical services that are critical elements of business services.  ITIL also includes a Technical Management function as the custodian of technical expertise. While the Technical Management function performs most of it's work in Service Operation, it

In a previous Blog I spoke to Application Management from the point of view that they do not actually develop the application but manage it throughout its entire lifecycle. This is done through the Application Management Lifecycle along with Operational Models. Operational Models are the specifications of the operational environment in which the application will run after it has been deployed. This model is used to simulate and evaluate the live environment during the Design and Transition stages. It also ensures that proper environmental requirements and sizing can be documented and understood by all groups or teams involved with application development and management. Many of you are familiar with “Software Lifecycle (SLC) and “Software Development Lifecycle” (SDLC). These are use by application development and project teams to manage the designing, building, testing, deployment and support of applications. From an ITIL perspective the Application Management Lifecycle looks at the

When I teach ITIL V3 Foundation classes I often have to make the distinction between Application Management which is one of the “Service Operation Functions” and Application Development. I often begin my discussion by explaining that Application Development is responsible for the actual development and building of applications by the developers. Application Management is responsible for managing applications throughout their lifecycle and is performed by any department, group or team that is involved in managing and supporting operational applications. Additionally the function also plays a role in the design, testing and improvement of applications that form part of IT services. Application Management plays a key role in all applications whether purchased from a third party manufacturer or developed by in-house staff. During the design stage of the ITIL Lifecycle one of the key decisions made by Application Development is whether to buy or build. After that decision is made Applic

I have often been asked what value does the Service Acceptance Criteria (SAC) provide? First let’s understand what the SAC is by definition. Service Acceptance Criteria: A set of criteria used to ensure that an IT Service meets its functionality and quality requirements and that the IT Service Provider is ready to operate the new IT Service when it has been deployed. This set of criteria is in the form of a formal agreement that an IT Service, Process, Plan or other deliverable is complete, accurate, reliable and meets the specified requirements. We 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, we must ensure that the contents of the Service Acceptance Criteria are incorporated and the required achievements are planned into the initial design. The Service Acceptance Criteria is the document that will ensu