Skip to main content

Posts

Thoughts on People and Process

The “ Agile Manifesto ” states that “We value Individuals and Interactions over processes and tools”.  What? Some have taken that statement and interpreted it to mean that when it comes to design and development … “No Process” is required!  In fact if we look further in the manifesto we see clearly that the value of process and tools is indeed recognized.  The manifesto is trying to impart the importance of people and interactions.  If we have a brilliant process that is defined and documented and yet drop the ball when it comes to people and interaction we will surely miss the mark every time.  Therefore, while there is value in process and in tools service providers must value the people and interaction with them more. In her book titled “The ITSM Process Design Guide” Donna Knapp stresses the importance of “Just Enough Process”.  When designing ITSM processes such as Service Level Mgmt, Change Mgmt, Incident Mgmt and others, service providers could ...

The Agile Service Manager

A core principle of popular Agile methodologies is to limit “Work in Progress”. Self-organizing Scrum teams, will only take on a small piece of work from the overall backlog that can be completed within a timeboxed period, normally between 2 and 4 weeks. By limiting their focus and attention to what is most important (priorities are set and agreed to) you enable the team to complete the agreed to work and by limiting work in progress we train teams to finish work, rather than begin added work. With this focus to customer requirements, a higher level of quality and more satisfied customers is the result.  Additionally, because the work is done in smaller increments, there is much less risk to our environment. In order for our ITSM teams to move from the methodologies currently being used to Agile methodologies such as Scrum and Kanban to name a couple, we must have an advocate for our teams to be able to engage in this new way of developing and maturing our ITSM/ITIL processe...

Operational Support and Analysis (OSA)

This blog was written in 2015. The OSA class was sunsetted along with all of ITILv3.  For a more recent perspective, visit our latest article on the importance of modern operational practices and the ITIL Practice Manager path on How to Align ITSM with Organizational Goals: A Step-by-Step Guide What if we did not build an operational support system to meet current business requirements?  That might sound a bit outrageous and contradictory to everything we have learned.  If you are a service provider, then you are aware that what we consider premium service support today could be accepted as the norm and sometimes can be outdated before it becomes a reality. The key to sustaining underpinning operations for any industry is in the constructs of the system. If we build a system to provide what the customer and business outcomes require now, then that is what we will have. The likelihood is that we will have a system that provides for a service that will ren...

Service Transition: Release Unit vs Release Package

A “Release Unit” describes the portion of a service or IT infrastructure that is normally released as a single entity according to the organizations release policy. The Release Unit can be thought of as a collection of infrastructure items that when packaged together could perform a useful function. The unit may vary depending on the type or item of service asset or service component.  The actual components to be released on a specific occasion may include one or more release units, or may include only part of a release unit.  Release Units should contain information about the service, its utilities and warranties and release documentation.  These components can be grouped together into a Release Package for a specific release.  In general the aim is to decide the most appropriate release unit level for each service asset or component. A “Release Package” is a set of configuration items that will be built, tested and deployed together as a single release.  E...

Continual Service Improvement (CSI) - Thoughts on Measuring, Value and Risk

The best practice approach and the Seven-step Improvement Process for Continual Service Improvement (CSI) begin with identifying the vision, mission, goals and objectives of the business.  In order to measure with appropriate targets these outcomes and objectives must be quantified. If you cannot measure it you cannot improve it.  First and foremost in order to perform ongoing CSI for a service we must identify the service.  That is just common sense right?  Yet how many discussions take place in Sales, in Development, and in Operations about whether something is or is not a service.  Collectively everyone in the lifecycle has a mission to meet the outcomes of the service or services that are being provided.  Measuring and Reporting For CSI to be successful we measure and monitor and report upon a service end-to-end.   When measuring and reporting IT managers will generally report availability in terms of percent with such things as ...

The Importance of Demand Management

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 ...

What is the difference between Process Owner, Process Manager and Process Practitioner?

This article was originally published in 2015. With the Introduction of ITIL 4, some of the concepts have changed in ways that are described below. ITIL 4 has also introduced new roles, as explained in our blog ITIL 4 and the Evolving Role of Roles . Before we dive into the difference between these roles, let’s first look at a key update in ITIL 4 – the shift from processes to practices. ITIL 4 has evolved to focus on holistic practices vs. isolated processes. By definition, a practice is a set of organizational resources designed for performing work or accomplishing an objective. For example, the purpose of the incident management practice is to minimize the negative impact of incidents by restoring normal service operation as quickly as possible. All organizations recognize the need to allocate resources to the management of incidents and mature their capabilities in that area. In ITIL 4, each practice includes resources based on the four ...