I recently published a blog that explained the Theory of Constraints.  In his book “ The Phoenix Project “, Gene Kim  leverages the Theory of Constraints and the knowledge learned in production environments to describe the underlying principles of the DevOps movement in three ways. The First Way  Workflow!  The first way is all about workflow or the flow of work from left to right. Generally referring to that flow of work between the business and the customer.  Work that is flowing from development to test and then test to operation teams is really only work in process.  Work in process really does not equate to anything until value is realized on the other side.  We must identify and remove or free up our constraints. For example, reducing the cycle from time of code commit to the time we are in production will reduce the release cadence. Ensuring the workflow from left to right can radically increase workflow throughout the delivery cycle.  Define work and make it visible.

There is often confusion between the goals, authorities and roles of Change and Release Management.  In fact, the objectives of each of process are very, very different. Change rules! Change Management is an authoritative process that governs anything that potentially impacts a new or existing service.  It is both the enabler of innovation and protector of stability.   It is first and foremost a risk management process.   It is also a planning process.   If Change Management is a governance process, Release Management is an action process.  Under the authority of Change, Release builds, tests and releases new or updated services into the production environment.  Every release is comprised of a single change or package of changes.  Release Management is more technical than Change. If done well, both processes will avoid unnecessary levels of bureaucracy and will build a collection of change and release models that pre-define and pre-approve the rigor required based on levels

Do you assume that all IT service management programs must adhere to the IT Infrastructure Library (ITIL)?    In truth, there are several other frameworks available and efforts underway.     Most are variations of or are rooted in ITIL but may apply to a specific environment or context.   Some are very comprehensive, while others advocate a “lighter” approach.    A service lifecycle is an ongoing theme.    None are meant to be highly prescriptive. Which is right for you?   Of course the answer is “it depends” on your goals, resources and business models.   To meet the needs of organizations that were overwhelmed by the enormity of the 2000+ pages of the IT Infrastructure Library, renowned ITSM expert Malcolm Fry published “ITIL Lite”.   This approach  makes service management more realistic for organizations with fewer resources by focusing on the essentials.        ITIL Lite is an official ITIL publication.   ( http://www.theitillitebook.com ). For years, Microsoft has  also

Trends such as mobile computing, consumerization (also known as bring your own device (BYOD), and cloud computing are having a dramatic impact on the service desk and present great opportunities for discussion within your organization. Considerations for the Service Desk and other IT support teams:  How does service catalog management support these trends? What about SACM and change management? What improvements might need to be made to incident and problem management and request fulfillment? What role does the service desk play in all of these processes? How does the service desk interface with business relationship management and service level management relative to these trends? The future is now.

What is a new moon? It is the phase of the moon where the moon is rising but not yet visible from the earth. For us, a new moon is definitely rising. It may not be visible but it is definitely here with BYOD, virtualization, shadow IT and cloud computing.   And that moon is demanding that we examine our practices in order to improve Time to Value. You may have heard a lot about the cultural and collaborative movement called DevOps.  Some service providers are making the DevOps vision a reality by focusing on improving their cadence - the  rhythmic   flow of something as it moves forward, such as software development or complex projects.  Agile service management and DevOps strive to improve the cadence between three main players in the value stream: Cadence of the Business Business demand is dynamic and the rate of speed is increasing. The business needs a cadence that is able to meet their accelerated requirements.  Jayne Groll in a recent webinar from ITSM Academy desc

Through the implementation of best practices, one of ITSM's critical success factors is to enhance the business' perception of the IT organization.   By creating a service strategy which helps to define good design, encourage effective transition processes and deliver valuable services through efficient and effective operational management, we work hard at making this goal a reality. Unfortunately, IT is often perceived to be ineffective and inefficient.  Recently, the government’s inability to deliver a working website for the affordable care act was splashed all over   news with many of my non-IT friends and family asking, how could this happen?   How come IT people never get it right? I want to respond with “BUT WE DO” and list many of the successes that I have been part of during my career.    But I look at them sheepishly and respond with” I don’t really know”.   As I think about this, I begin to get angry and not just because I’m an American tax payer, but because a

With the rise of service specialization, sourcing services from multiple service providers has become the normal way of doing business. This approach has allowed service providers to deliver higher quality services and enhanced support capabilities while more affectively utilizing a greater constrained set of resources.  In order for this cost savings and ability to spread risk to be realized an organization must be able to maintain a strong relationship with each service provider. In order to support the development of strong relationships in a multi-vendor environment, guidelines and reference points (technological, procedural and organizational) between the organization and the multitude of vendors being engaged must be established.  These validated reference points are known as service provider interfaces (SPI). A service provider interface is a formally defined reference point which identifies some interaction between a service provider and user, customer, process or on