The Business Relationship Manager is a role that serves as a strategic interface between the IT Service Provider and one or more Business Partners (or Business Units within a single organization) to promote, and influence Business Demand for IT services and products. They also work to ensure that the potential business value from those products and services is realized, optimized and properly documented.  The Business Relationship Manager can accomplish this through the engagement of four core disciplines which are defined as part of the house of Business Relationship Management (BRM).  This house is built upon a foundation of BRM competencies which support the Business Relationship Manager role and ensure it has the skills and aptitudes to be effective and deliver value to both the Provider and its Business Partner. The Four Core BRM Disciplines: Demand Shaping: This discipline stimulates and shapes business demand for the provider’s services, capabilities and products. It ensu

The Metaphors for Business Relationship Management (BRM) can be helpful ways to think about and describe the BRM role, discipline and organizational capabilities. There are three metaphors we currently use today.  They are as follows: BRM as a Connector: The BRM acts as a connector between the Service Provider organization and its Business Partners – forging productive connections between Provider resources and the Business Partner and among Business Partners.  There are three primary aspects to the BRM’s role as a connector: Facilitate productive connections and mobilize projects and programs. Stimulate, surface and shape business demand for the Business Partner while increasing the savviness within the Business Partner regarding the Provider’s services and products. Influence the Provider to ensure appropriate supply of services and products, both in terms of quality and capacity. (1)  BRM as an Orchestrator: The BRM also acts as an orchestrator between the Provid

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 d ifficult processes to follow.  We want just enough process, just enough governance and the process activities will no longer be

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 Practice

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 K

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 performi

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 fo