Skip to main content

Posts

The Whitehouse - Transitioning of Power to the New Administration

So the election is over and we move into the transitioning of power to the new administration. This doesn’t officially happen until January 20 th 2017. President elect Trump met with President Obama and so begins the transfer of Data, Information, Knowledge and Wisdom. So with such a short time the transfer between the transition teams and the operational teams has to happen quickly, efficiently and effectively.  This transfer of power has happened 43 times in our nation’s history with 11 happening so far in the postmodern era and the Obama to Trump administration being the twelfth. Can you say change model? The ability to have this smooth transition rests to a significant extent on the ability of those involved to be able to respond to existing circumstances, their ability to understand the situation as it currently exists along with any options that may be available, along with the known consequences and benefits.  The quality, relevance and accessibility of this knowledge

What is RCV?

RCV stands for Release, Control and Validate.  These are critical activities that are required for every deployment.  Proper Release, Control and Validation (RCV) is achieved as a result of integrated process activities.  In today's dynamic business climate, service outages cause real bottom line impact to the business. Mature processes are critical in enabling IT organizations to smoothly transition new and changed services into production, helping to ensure stability for IT and the business. The ITIL Capability course, Release, Control and Validation (RCV), provides the best practice process knowledge required to build, test and deploy successful IT services.  RCV is also the name of an ITIL intermediate training and certification. This course provides in-depth knowledge of the ITSM RCV processes that include: Change Management Release and Deployment Management Service Validation and Testing Service Asset and Configuration Management Request Fulfillment Change Evalu

Organizational Change Management

Change is not something that you do to people, change is something that you do with people. What thoughts occur when you or your staff are notified of a significant change to a process or service?  Is it one of dread, fear or perhaps frustration?  Managing organizational change should be a required element in any or all process and service changes where significant impact for users and staff are expected.   Service providers must ensure readiness for the change and ensure that a cultural shift does indeed take place.  Organizations change for a variety of reasons that could include the need to “get better” or perhaps to “be the best”.  Sometimes organizational change management is triggered by the need to deal with a changing economy or revenue loss.  At the outset, management must be honest with workers and still able to convince them that the best way to deal with current reality is via change.  Each individual’s ability to understand and to accept change will vary.  Change is i

Every Business Has Become a Technology Business

Every business has become a technology business.  Let that one sink in for a moment.  With the internet of things ever increasing it has become ever more imperative for us to make wise decisions about how to move forward on which IT services we should be delivering into the future (pipeline), how long we should continue to deliver our current (catalog) and when should we retire them (retire).  We literally could be an app away from becoming irrelevant. It is no longer enough to satisfy our customers, we must now delight and excite them.  They have to be able to enjoy the experience of how they receive these services along with the knowledge and comfort that the service provider of choice can continue without interruption to deliver this level of performance and functionality and even deliver new capabilities swiftly and often. By engaging in DevOps principles & practices (Scrum and Agile) at the strategic level we can begin to prioritize new and changing customer require

Operation and DevOps

DevOps is a culture, movement or practice that emphasizes the collaboration and communication of both   software developers   and other   information-technology   (IT) professionals while automating the process of software delivery and infrastructure changes.   It aims at establishing a culture and environment where building,   testing , and releasing software can happen rapidly, frequently, and more reliably. It’s about improving, communicating and collaboration.  From a Service Operation perspective we are already part of the way there, so maybe it won’t take as long or require as much organizational change as we think. Application management is responsible for managing applications throughout their lifecycle.  Application management covers the entire ongoing lifecycle of an application, including requirements, design, build, deploy, operate and optimize.   The application management function is performed by any department, group or team involved in managing and supporting opera

CASM and the 3 Ways

Agile Service Management ensures that ITSM processes reflect Agile values and are designed with “just enough “control and structure in order to effectively and efficiently deliver services that facilitate customer outcomes when and how they are needed.  We accomplish this by adapting Agile practices to ITSM process design.  Implement service management in small, integrated increments and ensure that ITSM processes reflect Agile values from initial design through CSI. By being able to incorporate a variety of tools from many practices, the Certified Agile Service Manager (CASM) can engage both the operations and development sides of the organization when defining and documenting processes, engaging in a major project or just move through these steps as part of an improvement project.   By incorporating these DevOps principles along with the CASM role, we can begin to incorporate the idea of process and functional integration much earlier in the development lifecycle.  It allows

Agile Process … What?! Is That an Oxymoron?

To survive in today’s competitive business climate organization’s must respond quickly  to their customers’ evolving needs and desires.   How many times have you heard that? We know from experience that an agile culture where agility is gained through people, process and tools can enable organizations to gain market share and competitive advantage.   And still, more organizations than not silo agile principles to software and product development. Ever wonder why, as an industry, we are not getting the types of returns that are expected from our efforts? Agile software development alone will not get us there!  Other factors include: Ability to quickly respond to customer feedback and needs – Customer engagement. An understanding that the customer and business requirements are dynamic and that we must have agile processes in place to respond to them. (Not only agile development) Sustained innovation and speed from idea to end of life for the service and processes. Incre

DevOps & the Top 5 Predictors of IT Performance

DevOps is here and it seems to be what everyone in ITSM is buzzing about. So what are the goals and how do we know it’s not just the next hot kitchen color for this year?  DevOps is a cultural and professional movement that stresses communication, collaboration and integration between software developers and IT operations professionals while leveraging agile, lean and traditional ITSM practices. Stakeholders on the development side will include, but not be limited to, all of the people involved in developing software products and services.  On the operations side it will include, but not be limited to, all of the people involved in delivering and managing those software products and services and the underlying IT infrastructure on which it is being delivered.  The goals are to better align IT responsiveness to business needs, smaller more frequent releases, reduce risk, increase flow, improve quality and reduce time to market. These can only be accomplished by underst

IT Benefit to Business

In a previous blog I wrote about the need for a high performance Service Desk.   So what do we get in terms of business benefit? The value statement in IT terms is reduced re-work, less down time, better utilization of higher cost resources (knowledge management), increased stability, reliability, availability  and predictable levels of IT services. So the question is how do we effectively communicate the business benefit of our support efforts? The goal of course is to align our IT metrics to the business benefit and define that benefit with language the business can relate to and understand.     IT Metric Average speed of answer.  First Call Resolution.  Average Escalation Duration. Total # of incidents recorded by: Service, CI, Assignment team. IT Goal Less down time, lower abandon rate, quicker speed of answer. Less down time, lower abandon rate, greater use of knowledge bases.   Less down time, predefined escalation paths, greater cooper

Are You Ready for the Football Season?

It’s that time of year where the kids are heading back to school, the seasons are about to change and YESSS it’s time for FOOTBALL!!!! The other night I was watching the HBO series NFL Hard Knocks about the Los Angeles Rams training camp and it dawned on me how much a football organization is like an ITSM organization and how they can incorporate the 12 Agile principles into their game plans.  I know your saying, what?? But hear me out and let me explain: Our highest priority is to satisfy the customer. Ultimately this means to win the Super Bowl, but we have to win each week against a different opponent, with different circumstances at each game. Weather, crowds, injuries all have to be adapted to. We have to welcome changes, even late in the game.   Some changes might not be so welcome but we have to be agile and adapt to whatever circumstances arise during game day. This may mean dealing with something bad or some opportunity presented to you during the game.   (Respond to

The Best of the Professor: The Third Way

The “Best of the Professor” blogs focus on one unique individual topic and will be followed by links to papers with more in depth information. DevOps initiatives are supported by three basic principles. 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. These principals are referred to as The First Way, The Second Way and the Third Way.    In earlier papers from the “Best of the Professor” we discussed  the “First Way” and how this DevOps principle was all about the flow of work from Left to Right.  We then discussed the “Second Way which was all about the flow of work from right to left and how critical that is for measuring DevOps value.  In this iteration from “The Best of the Professor“, the focus will be on the last of these three DevOps Principles known as “The Third Way”. The Third Way – Continual Experimentati

The BRM Function

I was recently asked if I had any insights into what roles (titles) are commonly used in companies and organizations to fulfill the BRM function.  This individual commented that the BRM function is one that they wholeheartedly support, but were finding that investing in a resource that is exclusively focused on that is something that companies either can’t afford (legitimately) or that they struggle to justify the cost for the position. Finding the suitable individual with the proper skill set to fulfill the Business Relationship Management (BRM) role can certainly be a challenge.  One thing to recognize is that the BRM job role function is dual fold.  This person represents first and foremost the customer.  They must be familiar with intimate details regarding customer needs, expectations and preferences.  On the other side the BRM also will liaise with the business to ensure that the service provider can fulfill those customer needs.  This is sometimes more of an art than a

The Best of the Professor: The Second Way

The “Best of the Professor” blogs will focus on one unique individual topic and will be followed by links to papers with more in depth information.  DevOps initiatives are supported by three basic principles. 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. These principals are referred to as The First Way, The Second Way and The Third Way.    This segment of “Best of the Professor ” will focus on “The Second Way”.   The Second Way                In an earlier “Best of the Professor” paper we discussed “The First Way” and how this DevOps principle was all about the flow of work from left to right.  “The Second Way in contrast is all about the flow of work from right to left.  It is reciprocal. How do we take all of the knowledge and learnings acquired and create feedback loops to the previous s

IT Services: External View vs Internal View

In every organization the one constant is change.  In operation all functions, processes and related activities have been design to deliver specific levels of service.  These services deliver defined and agreed levels of utility and warranty while delivering an overall value to the business.  The catch is this has to be done in an ever changing environment where requirements, deliverables and perceived value changes over time.  Sometimes this change can be evolutionary or can take place at a very fast pace. This forms a conflict between maintaining the status quo and adapting to changes in the business and technological environments.  One of the key roles of service operation together with processes from the other stages of the life cycle is to deal with this tension between these ever changing priorities. This struggle can be broken down into four general imbalances so that an IT organization can identify that they are experiencing an imbalance by leaning more toward

Change Evaluation

I often get asked where change evaluation takes place.  Isn’t it part of change management?  It is a separate process however it is driven by change management and is triggered by the receipt of a request for evaluation from Change Management. Inputs come from several processes including the SDP and SAC from Design Coordination, change proposal from SPM, RFCs, change records and detailed change documentation from Change Management.  It holds discussions with stakeholders through SLM and BRM, testing results from service validation and testing to ensure that its members have a full understanding of the impact of any issues identified and that the proper risk assessments can be carried out against the overall changes and in particular the predicted performance, intended affects, unintended affects and actual performance once the service change has been implemented. The purpose of change evaluation is to provide a uniform and structured means of determining the performance of a

The Best of the Professor : The First Way

The “Best of the Professor” blogs will focus on one unique individual topic and will be followed by links to papers with more in depth information.  DevOps initiatives are supported by three basic principles. 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. These principals are referred to as The First Way, The Second Way and The Third Way.    This segment of “Best of the Professor” will focus on  “The First Way”. 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

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