The service management marketspace is populated with hundreds of tools, nearly all of which resemble each other more than they are distinct. Fundamentally, they are a place to log tickets of various types, to push those tickets to various roles for their updating, to document the structures upon which the handling of those tickets depends and to analyze and report of the performance of the processes supported by those tools. In some cases, the use of the tools is extended to users. In other cases, various types of knowledge management functionality is also included. The tools are designed to be integrated into the existing management environment either using out of the box connectors, or using documented APIs, or by generic accesses to the underlying database(s). [Read more…] about Manifesto for Service Management Tools
Posts
Can we really not multi-task?
Can the human brain multi-task?
The loss of efficiency and effectiveness due to context switching among various tasks is one of the underpinning tenets of why a Kanban approach helps organizations to reduce the lead times of their work. But is it really true that the human brain cannot multi-task? [Read more…] about Can we really not multi-task?
Stopping the clock vs. waiting time
Stopping the clock is a pernicious practice
There is a tradition among certain service providers to “stop the clock” when measuring process cycle time. They consider that any process activity under the responsibility of someone other than the service provider should not count against the agreed service level. There are two main cases: when the provider is waiting for customer feedback and when the provider is waiting for a third party supplier.
From the point of view of the customer, such practices are pernicious and demonstrate a fundamental misunderstanding of the difference between accountability and responsibility. We may readily agree that a third party might be responsible for any action that might have been escalated to it. But this does not relieve the service provider of its accountability to the customer for the results! And it hardly makes any difference if the service provider has managed to hornswoggle the customer into agreeing to such practices. [Read more…] about Stopping the clock vs. waiting time
Organizing for Kanban
When Kanban decides against lower lead times
Certain organizations applying Kanban principles may choose not to include IT operations specialists in cross-functional teams, on the assumption that it would be very hard to keep such specialists busy. These organizations prefer, instead, to group the operations specialists in their own teams, thereby increasing the risk that an operations specialist might not be available immediately when a work item is assigned to that team. In other words, a compromise is made in favor of higher occupation levels for these specialists, as opposed to higher levels of throughput and lower lead times.
This article discusses the paradigms for organizing IT personnel that underpin such decisions. The choice between a pure cross-functional team and the separation of developers and operations into separate teams is more nuanced than a simple choice between optimizing occupation levels as opposed to lead time. [Read more…] about Organizing for Kanban
Psychology, Flow and Kanban
Kanban and Flow
The benefits accrued to an organization by adopting Kanban methods are closely related to the concept of flow as described by Mihály Csíkszentmihályi (Flow: The Psychology of Optimal Experience, New York: Harper and Row, 1990). Having a social scientific underpinning for Kanban, we may be assured that it is not just a flash-in-the-pan phenomenon, not just the “next big thing”. [Read more…] about Psychology, Flow and Kanban
Configuration Management at Home
About two months ago I acquired my third laptop in about six years. My first laptop started having a series of troubles on the day that I left for Hong Kong – and the day that volcano in Iceland erupted, causing the airspace in Europe to be closed for more than a week. It was extremely difficult to make travel arrangements to get home without a computer at hand. [Read more…] about Configuration Management at Home
Releases and Changes
“Best Practice” in 2000(?)
I remember being taught in an ITIL® V2 class that higher quality is one of the principle benefits of grouping changes into releases. This is principally due to more efficient use of testing. ITIL mentions as benefits (Service Support §9.4.1):
- a greater success rate in the Release of hardware and software
- assurance that the hardware and software in live use is of good (or known) quality
- better use of User resources because of combined efforts when testing new Releases
- minimization of regression-testing requirements, offering greater coverage than is possible with small changes that occur frequently or too close together.
And yet, the partisans of such approaches as extreme programming (XP) or continuous delivery claim precisely the opposite. Smaller chunks of software released frequently are much easier to manage and to ensure high quality. Has something changed in the very few years separating these two approaches or is one approach right and the other wrong? Or is the issue largely one of scope and applicability, making the apparent conflict a case of apples and oranges?
What ITIL Assumes
The argument advanced in ITIL V2 is based on a set of assumptions about how software is developed, tested and deployed:
- Software was (at that time) typically developed using a waterfall-style project. This generally implies that software releases are developed as large chunks taking relatively long time.
- Users do not like their software to change very frequently. The assumption is that they are used to working in a certain way. Ifsoftware changes all the time, the users must regularly adapt how they work, making work less, rather than more, efficient.
- When users do want software to change, they are likely to need to change other aspects of how they work, implying that the deployment of the software must be planned in function of when the users will be ready.
- Testing of software is always partial, because it is too expensive and too time-consuming to try to test all functionality
- The interaction of different components of a software system is difficult to predict
- IT Operations and support do not like software to change frequently. Since software releases generally contain a lot of bugs and because the integration of the software into an operating environment is often not taken into account during the design and testing phases, the work required to iron out the issues is both lengthy and exhausting
The Agile Manifesto was written barely one year after the publication of ITIL Service Support. While agility in software development, and consequently in software releasing, was already being practiced in 2000, the authors of Service Support can surely be excused from taking into account what was not yet recognized as a leading edge in software development trends. The same cannot be said for ITIL 2007. The charitable reader will be perplexed by the failure of ITIL 2011 to better integrate agility into its discussion of release management. Less charitable readers can only regret this failure, which is more probably due to publication policy than to any opinions held by the authors of ITIL 2011.
Agility puts ITIL’s Assumptions into Question
Whatever the rationale, the agile movement questions the well-foundedness of many of ITIL’s assumptions.
- The traditional waterfall approach to managing software development projects has a dismal track record and may be inappropriate in many contexts.
- The assumption that users do not like change is based on changes that are not well aligned to business needs. Changes that truly deliver value are indeed welcome.
- It is not only entirely unacceptable to release software without adequate testing, the design of the test should precede the development of the code! Software must always be in a releasable state.
- Nothing is harder for a developer to fix than a bug introduced months ago, when it is not clear precisely where the bug exists, and frequently when the debugger is a completely different person than the original coder. And nothing is easier for the developer to fix than a bug introduced the same day as it is detected.
- By ensuring that software is always releasable and by radically decreasing the number of bugs, one of the principal objections from operations and support disappears.
- The work of developing software is not finished until that software is delivering value.
Agility Triggers New Questions
All the changes brought on by a more agile approach to software development lead to a new set of assumptions that need to be tested, relative to changing and releasing:
- Software is but one component of an IT service. While this should be the case, many persist in thinking of a release as being a software release.
- The people responsible for operating software inproduction participate in the design and testing of the solutions based on that software. Again, this should be the case. What happens in reality is yet another question.
- Testing includes test cases that may lead to operational acceptance. Even if such tests existed, guess what would be sacrificed first if a release is “late”?
What Agile Developers do not Say
There remain certain circumstances that are not explicitly addressed by proponents of agile software development:
- On many platforms, especially when thick clients are used, the deployment of new software requires a period of unavailability. Depending on the nature of the activities of the users, even short periods of unavailability may be unwelcome and are tolerated only occasionally. It is difficult to imagine a development-driven, continuous deployment approach in such circumstances.
- If new releases provide genuine value to customers, they nonetheless require an investment in time by the people training the users and the people supporting the users. All the time used to update their knowledge and their deliverables is unproductive time relative to their support and training missions. From a lean perspective, these activities are a form of waste.
The Bottom Line
We are probably in a transitional period between systems depending on hard to manage clients and systems with high availability clients. This trend is fostered by the increasing use of software using very thin clients, SaaS, automated and transparent software deployment. We are furthermore in a situation where people who started using computers and software as adults are gradually leaving the business user marketspace. As a result, people accustomed to agile solutions with frequent functional changes will come to dominate the workplace.
The result of these trends is that the technical and social objections very frequent releases will disappear. In this case, all the benefits of frequent releasing will come to dominate the equation, providing higher and more reliable value more frequently.
User Support and the Co-Creation of Value
Understanding the value of a social approach to user support depends on having a framework for understanding the co-creation of value by the user support service. In this posting, I will propose a framework for understanding how both the service provider and the service consumer contribute to creating value during the support service and the types of respective value created by that service. In a future posting I will apply that framework to analyze social support as opposed to traditional in-house support.
Fitness for Purpose and Fitness for Use
Let us assume that the value of a service depends on both its fitness for its purpose and its fitness for use. This is what others have called the service’s utility and its warranty. It is not possible to treat these two factors independently. If you are a service desk agent and a user asks you for support, it might very well be the case that the value of your support could increase if you had more time to investigate and prepare a response. So, you need to find the right balance between helping your user when your user needs help (fitness for use or warranty) and providing to your the help that is really needed (fitness for purpose or utility).
Furthermore, the value provided via that support is not the result of a one-sided activity. It is the result of what service scientists call a “co-creation.” In other words, the input to the service is coming from both provider and consumer and the outcome of the service is of value to both the provider and the consumer. A few examples illustrate some modes of co-creation.
Input and Process as Co-creation
Service Agent as Midwife
A user calls the service desk for support and presents the issue. The agent asks some pertinent questions that trigger a certain number of realizations on the part of the user. Spurred by those questions, the user figures out how to resolve the issue, without receiving an explicit solution from the service desk agent.
Issue Clarification
Frequently, the support required by a user is not to identify a solution, but rather to identify the problem. The user is not asking the right questions and is not seeing the issue for what it really is, due to limited experience or preconceptions. The dialectic between user and agent helps to clarify the issue. Once clarified, the solution itself is self-evident.
Delegation
It happens that some users are, well, lazy. Rather than completing their assigned tasks, they ask for help and get a service desk agent to do some of the work for them.
Information Transfer
Often, the purpose of a support request is to acquire some data or information to which the agent has access and which the user needs, but cannot reasonably be expected to have. Or, information transfer leverages the skills of the agent as a knowledge worker, who has the meta-information and experience to find the right information more quickly than the user might have done alone. The responsibility for using that information lies entirely with the user.
Innovation
Resolving a support issue is not always a question of identifying the right answer, as if that answer exists in some Platonic reality. Sometimes, an issue is resolved by innovating a solution based on the mutual input coming from the user and the agent. The agent could not innovate the solution without the knowledge of the user’s issue and the user benefited from the agent’s cognitive skills, communication skills, experience, tools access and knowledge.
Co-creation of Outcomes
The outcome of the support service is not restricted to the user and the user’s organization. In all cases, there is an outcome of value for the service desk agent and the support organization.
Outcomes for the User
The types of outcomes that are of value to the user are:
- Getting a solution of higher utility, one that is more fit for the purpose at hand. In short, it helps make the user’s work more effective
- Getting a solution of a given utility more quickly, enabling higher productivity by the user
- Getting the knowledge and experience that enables the user to independently solve similar issues in the future
- Helping to make the user a more valuable and immediate resource for other users in the same organization
- Helping the user’s work to comply better with regulations and policies.
Outcomes for the Support Function
The types of outcomes that are of value to the service desk agent are:
- Discovery of new solutions and methods that may be reused in the future
- Enforcement in the mind of the agent of current issues, making them easier to diagnose in the short term
- Improved knowledge of the user, helping to facilitate future interactions with that same user
- Improved knowledge of the user’s work and organization, enabling the agent and the service desk to provide higher utility support in the future
- To the extent that the user is satisfied with the support, the user (and his or her colleagues) will be encouraged to increase their use of the support service, thereby creating a spiraling cycle of co-creation of value.
Assessing Social Service Support
Now that we have a framework for describing the types of value created during the support service, by both the service provider and the service consumer, we are in a position to assess the value provided by social support as opposed to the traditional support provided by a dedicated, in-house support function. This analysis will be made in a future posting.