Transition Planning and Support Originally Published on February 28, 2012 I am often asked on how to manage transition.   Most organizations find that there are a lot of moving parts.   What happens here effects all stake holders and if expectations aren’t set correctly the reputation of the IT organization can often be at risk and that it can be difficult to meet the changing needs of the business in a cost effective and timely manner.   In order for us to be able to effectively meet these challenges we should start with the big picture process of Transition Planning and Support: The purpose and objective of the transition planning and support process is to provide overall planning for service transitions and to coordinate the resources that are required.   It does that with the following activities: Plan and coordinate resources to deliver the requirements of service strategy that have been translated in service design and insure they are effectively delivered in service oper

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

Someone recently asked me to clarify how service management handles the blur between management and development.    Great topic area. While many perceive service management frameworks as affecting only the production environment, ITIL and others actually wrap best practices around an entire service lifecycle that starts with strategy and works its way through design, transition and operation.   Service management does acknowledge that there are already proven, trusted software development lifecycle (SDLC) approaches in use and that development may occur inside or outside the customer organization.  Given that, there is more focus on service design than service development  in ITIL and a recommendation to use the SDLC methodology of choice when developing. Enter DevOps - a philosophical movement that recognizes that today's rapid development environment requires a stronger connection between development teams and operational teams.   Agile is quickly replacing the classic waterf

ITIL 2011:  Design Coordination Originally Published on September 20, 2011 The Service Design stage of the ITIL Service Lifecycle can be a powerful and beneficial set of activities and undertakings if managed, guided and coordinated in a holistic and comprehensive manner. One of the more powerful processes to emerge with the publication of the ITIL 2011 addition is the Design Coordination process. Previous editions of ITIL had the reader and practitioner assume or extrapolate the guidance provided in the Design Coordination process. ITIL 2011 formalizes the guidance and shows the need to have a method of ensuring the smooth operation of all the moving parts of Service Design.   Design Coordination has several important objectives including (SD 2011 4.1.1): Ensure the consistent design of appropriate services, service management information systems, architectures, technology, processes, information and metrics to meet current and evolving business outcomes and requirements

The Importance of Availability Management Originally Published on July 5, 2011 The Availability Management process ensures that the availability of systems and services matches the evolving agreed needs of the business. The role of IT is now integral to the success of the business. The availability and reliability of IT services can directly influence customer satisfaction and the reputation of the business. The proactive activities of Availability Management involve the proactive planning, design and improvement of availability. These activities are principally involved within design and planning roles. The proactive activities consist of producing recommendations, plans and documents on design guidelines and criteria for new and changed services, and the continual improvement of service and the reduction of risk in existing services wherever it can be cost-justified. There are several guiding principles that should underpin the Availability Management process and its focus:

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