Welcome to the Professor

Please join in the conversation. The Professor is always happy to respond to your questions and hear your ideas!
Email itsmprofessor@itsmacademy.com.

Tuesday, February 21, 2017

The Service Management Trinity

In a previous blog from the ITSM Professor we focused on the relevance of ITIL and ITSM Best Practices to contemporary IT service providers.  We learned how a successful DevOps initiative must embrace ITSM, Lean, Agile and other frameworks and practices to ensure success.  The solution to value is like a diamond and has many facets!  In 1992 I read an article that talked about the key to delivering value and the topic was all about People, Process and Technology.

Twenty-five years later I must agree this is still the winning formula.  What might be different is how we view and utilize these for success.

What will Change?

People – Integrated teams with ownership and accountability. Visualized workflow and clear direction.  Communication, Education and Collaboration required.  Inspire and Educate!

Process – NO MORE overburdened bureaucratic difficult processes to follow.  We want just enough process, just enough governance and the process activities will no longer be siloed to just Design or to just Operational lifecycles.  They will be integrated.  Shatter the departmental and the process silo’s.   Have you embraced ITSM Best Practices and Agile Service Management?  This is not an oxymoron.

Technology – We should now have an outside in approach.  “Information, Technology, and Infrastructure are key but our focus will shift from those to the “Value” that that they produce.  The voice of the customer and dynamic business requirements becomes the focus.  Today with cloud services, infrastructure on demand and other innovation yet to be seen we are more than ever enabled to shift our focus from the technology to outcomes.  Automation will be key but we now look at microsystems and Tool Chains that support the flow of integrated teams, integrated processes and brilliant results.

The trinity still stands.  Some organizations talk about a focus on People, Process and Technology but in the wrong order.   If you are focusing more on Technology and Process than you may be at risk.  It is still all about PEOPLE, PROCESS, and TECHNOLOGY but most importantly is that it is in that order.

Tuesday, February 14, 2017

Is ITIL Still Relevant?

With the onset of practices such as DevOps, Continuous Delivery, Rugged Code, and Value stream mapping, is ITIL / ITSM Best Practice still relevant?

The short and emphatic answer is YES!

Let’s look at how ITSM Best Practices are relevant and enable some of the initiatives that are in the foreground of Service Management for many contemporary IT organizations today.

DevOps – DevOps is a cultural and professional movement that focuses on communication and collaboration to ensure a balance between responsiveness to dynamic business requirements and stability.   Therefore, things like Lean and Value Stream Mapping, practices like Continuous Delivery and Continuous Deployment, all become a subset or a building block to a successful DevOps initiative.  DevOps is frequently an organic approach toward automating workflow and getting products to market more efficiently. Ok, if we can accept that then the next question is … What are you going to automate?  

ITSM Best PracticeProvides the cornerstone for the activities referred to as “ITSM Processes”.  The need for these activities does not go away.  They need to be performed to get any hope of meeting compliance, mitigating risk and to ensure value for any product or service that is being designed, deployed and more importantly sustained over the life of that product or service.  If DevOps integrates teams throughout the value stream including Service Operation teams the better question is how could you even think about omitting best practice?  What is going to change is how we go about creating and fulfilling the processes throughout the service lifecycle.  Agile software development is money out the window if we do not have Agile processes and workflow. The backbone will still be People, Process and Technology.  And… in that order.

It is mandatory for our teams to get a common understanding of just how DevOps is enabled by Agile, ITSM and Lean best practices.  It is not just the tool, automation and continuous delivery but how we go about doing this that is key.  We need to inspire and to educate our teams for how these practices can dove tail together to enable them and your company for success. 


Tuesday, February 7, 2017

IT Service Management - Tools

In today’s world where demand for up to date services has grown and the lead times for delivery has continued to be shortened I am often asked, what is the best tool? The answer is, of course, “it depends!” Every organization has different needs, budgets and resources, however the requirements for automated building, testing and delivering new functionality has never been greater.

Every organization must be able to look at the list of requirements for tools from both the operational and development sides of the IT organization as the functions become more and more integrated.

The starting point is a list of generic requirements. An integrated suite is preferable and should include options such as:
  • Service Portfolio
  • Service Catalog
  • Service Design Tools
  • Discovery/Deployment/Licensing Technology
  • Workflow or process engines
  • CMDB’S
  • Configuration Management Systems (CMS)
  • Self Help for Users
  • Remote Control
  • Diagnostic Utilities
  • Reporting Tools/Dashboards
  • Service Knowledge Management System (SKMS)
Depending on your requirements, goals, budget and maturity level, you may need one, several or all of the above technologies. A good suite will offer the flexibility to purchase only those modules that are currently needed by your organization with the option to add more over time.

The next step is to assess your current tools and their use. The assessment may reveal that you are not using existing tools to their fullest capability. Consider the following when evaluating existing tools and possible new purchases:
  • Support for monitoring service levels, data structure, data handling and integration
  • Integration of multi-vendor infrastructure components
  • Conformity to international open standards
  • Flexibility in implementation usage and data sharing
  • Usability
  • Distributed clients with a centralized shared database
  • Conversion requirements
  • Data backup, control and security
  • Support and scalability
The following are useful evaluation techniques:
  • Gather your Requirements. (Use the MoSCoW strategy for evaluating your requirements. Must haves (M), Should haves (S), Could haves (C), and our Won’t haves but would like to have (W)?)
  • From the MoSCoW list, create a Statement of Requirements (SOR).
  • Identify possible products
  • Determine a selection criteria
  • Evaluate products
  • Put together a short list of products
  • Score the final products
  • Rank the products
  • Select the product that meets your needs and budget
Please remember that any tool is NOT a silver bullet. Effective internal processes are critical to gaining efficiencies through tools. Tool success will likely depend on your planning, deployment, management and improvement of process.

While there are many good technologies in the marketplace today, it is important to select the one that meets your specific and unique requirements.

For more information please see ITIL Foundation, ITIL Service Design, ITIL Service Strategy


Tuesday, January 31, 2017

Service Acceptance Criteria

I have often been asked what value does the Service Acceptance Criteria (SAC) provide?  Along with other criteria and elements, the Service Acceptance Criteria forms what is described in ITIL and the Service Design Package.  With so much importance on Design, Development and Deployment, the significance of the SAC increases as we look to optimize service value.  Do you want to increase value to your business and customers? First let’s understand what the SAC is. 

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. 

In the past, this has sometimes been thought of and enacted on at the end of the value stream. High performing service providers will frequently apply other methodologies such as lean, agile and ITIL process improvements to ensure that the SAC is defined and improved throughout the development/deployment lifecycle.  This is how ITIL intends it to be utilized.

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 required achievements are planned into the initial design.  What?  Does this mean that the SAC starts in the requirements gathering stage and evolves throughout the delivery?  Yes, and in doing so, a service provider could help to shift their organization to focus on value from a customer’s perspective rather from that of the IT service providers view point. 

The SAC is the document that will ensure the Service Provider is ready to deliver the new service by answering the following criteria:
  • Has the go live date been agreed to with all parties?
  • Has the deployment project and schedule been agreed to and made public to all stakeholders?
  • Have all SLR/SLA’s been reviewed, revised and agreed to with all stakeholders?
  • Has the Service Catalog/Portfolio been updated and all appropriate relationships established within the Configuration Management System?
  • Have all users been identified/approved and appropriate accounts created for them?
  • Can all SLR/SLA targets be monitored, measured, reported and reviewed?
  • Can performance and capacity targets be measured and incorporated into the Capacity Plan?
  • Have incident and problem categories and processes been reviewed and revised for the new service?
  • Has appropriate technical support documentation been provided and accepted by Incident, Problem and all IT support teams?
  • Have all users been trained and user documentation been supplied and accepted?
  • Have appropriate business managers signed off acceptance of the new service?

Consider now how the flow of work, the velocity of your team and value to the business and external customers could be optimized with a focus on the SAC early in the ­­­­­­­­­­­­­­­­value stream. With these documented criteria in hand we can insure that the Service Provider will meet the agreed needs of the customer and the business. It will insure that availability, capacity, security and continuity can be assured and thereby deliver value to the business.

For more information see ITIL Service Design




Wednesday, January 25, 2017

Incident vs. Problem

You may have seen a similar blog from the Professor a few years back that talked about the distinction between the idea of an incident vs problem.  Everything from that article is still relevant.  As process and methods for development and deployment have matured so has the usage of Incident and Problem Management.


This is one of the most often confused points in for Agile, LEAN and ITIL adaptations.
The ITIL definition is the same.
Incident: Any unplanned event that causes, or may cause, a disruption or interruption to service delivery or quality
Problem: The cause of one or more incidents, events, alerts or situation­­­­­­­
Where and how we apply Incident and Problem Management is evolving.
A decade ago, and still in some organizations, Incident and Problem Management are processes exclusive to Service Operation.   ITIL is so very relevant and today we find, with the onset of DevOps and cultural shifts, many organizations are adopting little or zero tolerance for allowing defects through the development/deployment lifecycle.  ITIL processes and principles will help.
High performing service providers have discovered that by integrating Incident and Problem Management early in the lifecycle, such as in design, development, build and test activities, they can become much more proactive to ensure true value to the customer. This aligns with and allows for the DevOps principle for shortened and amplified feedback loops throughout the value stream of Design and Delivery. If this concept is also applied to the process improvements of that value stream then the time, the amount of resources and certainly the cost will be much less for the service provider.
If Incident and Problem Management are applied early in the lifecycle and a defect is discovered, “Problem Management” would determine the root cause or the reason “Why” and propose a solution to prevent the repeat of this type of defect (incident) or cause (problem) so that it will never happen again.  This in turn prevents the “defect/incident” from occurring in the future.  This is very different then those that focus on Problem Management after the defect has done its damage and consider it only as an operational task.
If we continue to look at Incident and Problem Management as merely for Service Operation, it is likely that we will have a lot of business impact and potentially frustrated technicians who do not feel enabled for success and a likely dissatisfied customer.  By thinking out of the box and considering how you can increase the flow of work for Design and Delivery by applying Incident and Problem Management activities early in the lifecycle, an organization can truly become proactive.  
For further information, ITIL training, resources and more …  click here!

Tuesday, January 10, 2017

Service Asset & Configuration Management (SACM)

Service Asset & Configuration Management (SACM) is the one process that touches all of the other ITIL processes. SACM’s purpose is to deliver accurate and up-to-date data and information to every other process across the lifecycle.  The fascinating fact about SACM is that in many cases it depends on those other processes through their defined, documented and agreed to activities, to insure that the data and information about those assets is up to date, accurate and properly recorded through the Configuration Management System (CMS),  No organization can be truly efficient and effective without having a configuration management process to insure we understand how and where that infrastructure, application, tools, documentation and sometimes even people are being utilized in delivering business outcomes and creating value.

SACM ensures that CIs (configuration items) are properly identified; baselined and that changes made to them are properly controlled and recorded.  This is accomplished by closely integrating Change, Release and Deployment and SACM.  Most organizations have a process that will track and report on the value and ownership of fixed assets throughout their lifecycle.  Much of this is done by a part of the business known as fixed asset management or financial asset management. Their goal is to keep financial information on these resources. In most cases they are not usually within the same business unit as Information Technology.  For the most part they are not concerned with the relationships between these resources and how these assets are being utilized and what IT and business services they support.  SACM must ensure the proper care and maintenance of these CIs that are under the control of IT services.  There should be well established intersections between these groups in order to provide the overall business a more defined and detailed view of these capital assets.

By having an accurate representation and clear visibility to your service assets:
  • Staff is better able to forecast and plan changes.
  • IT staff have a better understanding of the relationship between CIs and the services they support
  • Assessments are more accurate for Availability, Capacity and Continuity planning.
  • There is a greater effectiveness in delivery of service levels.
  • You have the ability to precisely identify the costs of a service.
  • You can provide greater flexibility to the business in meeting market opportunities.
  • As technological changes happen it allows SACM to create more effect CIs and CI definitions to meet the new reality.
For more information:


Tuesday, January 3, 2017

The Purpose and Value of a Business Impact Analysis (BIA)

I am often asked the purpose and value of a Business Impact Analysis (BIA).  The purpose of a BIA is to quantify the impact to the business (in dollars and cents) that the loss of a service would have.  It is a valuable source of input when trying to ascertain the business needs, impacts and risks that the organization may face in the delivery of services.  The BIA is an essential element of the overall business continuity process.  It identifies the most important services to the organization and therefore will help to define the overall strategy for risk reduction and disaster recovery.  At a more granular level this analysis enables the mapping of critical service applications and technology components to critical business processes.  It is an invaluable input for Continuity, Strategy, Availability, Design, and Capacity Management and can have a significant impact on the cost of designing, delivering and maintaining these services based on their criticality as defined by the business. 

The BIA’s strategic purpose is to show which parts of the business will be most affected by a major incident and what affect it will have on the company as a whole.  The form these damages or losses may come in are:        
  • Loss of income
  • Additional costs
  • Damaged reputation
  • Loss of goodwill
  • Loss of competitive advantage
  • Breach of law, health or safety
  • Immediate and long term loss of market share
  • Political, corporate or personal embarrassment
  • Loss of operational capability
As part of the design phase of a new or changed service the BIA should be conducted to help enable a greater understanding about the function and importance of a service.   Working with Service Level Management, this will allow the business to define:
  • Acceptable levels and times of a service outage.  How the degree of damage is likely to escalate after a service disruption, and the times of day, week, month or year when a disruption will inflict the greatest damage.
  • The staffing, skills, facilities and services necessary to enable critical and essential business processes to continue to operate at minimum acceptable levels.
  • The time within which all required business processes and supporting staff, facilities and services should be fully recovered.
  • The cost the loss of a service has to the business. This is critical for Financial Management.
  • How to appropriately develop a budget for being able to institute the appropriate countermeasures for any and all services.
For more information please see ITIL Service Strategy and ITIL Service Design