Skip to main content

Posts

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