Skip to main content

Posts

Minimum Viable IT Service Management (MVITSM)

The aim of Minimum Viable IT Service Management (MVITSM) is to put in place “just enough” process to meet your organizations, needs, goals and circumstances. Minimum Viable Product To understand this concept let’s take a look at some of the origins.  The term Minimum Viable Product (MVP) originated in software development.  If we research the definition we find that in product development, the MVP is a product which has just enough features to gather validated learning about the product and its continued development. Gathering insights from an MVP is often less expensive than using a product with more features which increase costs and risk in the case where the product fails, for example, due to incorrect assumptions. Minimum Viable Process In a recent workshop Donna Knapp from ITSM Academy indicated that the Minimum Viable Process is really a matter of looking at what are the minimum critical activities that need to be performed in a process.  Complex bureaucratic processes

Business Relationship Management (BRM)

Business Relationship Management (BRM) is the process and role that allows us, as a service provider, to establish a strategic and tactical relationship with our customers. This will be based on ensuring we understand the customer and the business outcomes they are trying to create and how and what services are engaged by the business to meet those defined goals and objectives. A key activity of the BRM process is to ensure that as business needs change over time, we as a service provider, are able to translate these needs into requirements through the use of a Service Level Requirements document (SLR) which then manifests itself into the portfolio in the form of defined services.  The BRM will assist the business in articulating these requirements and the value of these services that the business places on them. In this way the BRM process is executing one of its critical success factors, which is to safeguard that the customer’s expectations do not exceed what they are

The Best of the Professor for DevOps #1 – Resources to “Educate and Inspire”

If you are a strategist, manager or practitioner working in service management today you will probably be working on ways to improve lead time, cycle time and overall flow of work through the lifecycle of delivery.   Business demand requires speed and dynamic business requirements force us to look at ways to bust out of silos for cross functional integration.  Time to market, customer satisfaction and the need for secure robust systems are being optimized by many service providers as a result of successful DevOps initiatives.  When considering where and how to optimize the flow of work from ideal to end of life for a service , managers and IT staff frequently have a subjective view of what DevOps is all about and will often get into war room discussions around what certain terms mean.  Over the last year there have been many papers written by the ITSM Professor that clarify terms, concepts and methods current in the industry for service providers.   For clarification, and to ensur

Death by Meetings

So I assume everyone has heard the phrase “death by meetings”, that fear that you are going to be in a series of meetings and that no matter how hard everyone tries, you seem to come out of these meetings with the same to do list or a larger one.  I know your all shaking your head yes or saying “been there done that and have the tee shirt to prove it”.  We at ITSM Academy recently had our yearly strategic meetings and I want to say up front, Best Strategic Meetings in the eight years I have been with the organization. Now that it is not to say that we haven’t had great Strategic Meetings in the past, because we have.  And that is not to say that I wasn’t heading into these meetings with a bit of trepidation, as I think most of us do. I recently read an article called Managing Yourself, Learn to Love Networking*. It defined four strategies that you can engage to help you network with other people even if you really don't enjoy it.  I thought, why can’t I take these 4 approaches

The Technical Catalog

As most of us are already aware, the business of IT has become even more critical in ensuring the overall success of an organization.  In today’s fast pace and fluid environments the statement that “every business decision triggers and IT event” is becoming increasingly true for those of us who operate in the world of ITSM. One of the most valuable tools that we can employ is our service catalog.  In a mature ITIL organization we can have two views of this catalog. The first being the Business/Customer catalog where we connect our customers/users to the standard IT services that we offer, deliver and support.  The second view is the Technical/Supporting service catalog, which when appropriately maintained is a very powerful tool that allows us to relate IT services to our supporting services and the underlying supporting infrastructure.  It is this second view that we will review here. Our service catalog provides us with a central source of information on all of the IT servi

FAIL

We all know failure!  If a deployment for a critical service fails and negatively impacts business partners and consumers that can not be good.   One would have to consider why did this happen?  And even more critical is, why does it happen more than once? There are times when failure can be viewed as good. That of course is when we admit and then correct the reason or the cause of that failure.  Many organizations struggle with a culture that fosters hiding failure.   It is very difficult in this type of stringent culture to be effective and even more difficult to be efficient and innovative.   Not being able to admit or to discuss failure generally will lead to repeated and more disruptive failure.    What is a service provider supposed to do?  Do we fire individuals who drop the ball and fail?  If so, what size of failure would instigate such an action?  Do we restrict staff from elements or areas of the value stream so that their failure does not have the opportunity to impact u

To Collaborate or To Compromise … Which Is Best?

The people factor and your ability to absorb change could and does make all the difference for IT service providers.  Most IT practitioners will agree that “change” requires some organizational change management.  Organizational Change Management (OCM) is the process of preparing, motivating and equipping people to meet new business challenges.  Conflict can be looked upon as good!  Embrace conflict don’t ignore or avoid it because it is necessary to listen to conflicting opinions that may not have been considered.  Learning to use different conflict modes helps to move forward and increase engagement that could make your organizational change a success. The   Thomas-Kilmann Conflict Mode Instrument   is a tool for helping people understand how different conflict-handling styles affect interpersonal and group dynamics and for empowering them to choose the appropriate style for any situation.  I was studying this in preparation   for an “Organizational Change Management” workshop an