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
Service Management
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.
Psychology and Service Management
Skeptical about Psychology
I was invited to deliver a presentation last year and received as a token of appreciation a book, Daniel Kahneman’s Thinking, Fast and Slow. If you are like me, you have been skeptical about what benefits social sciences, such as psychology, can bring to other activities. This book completely reversed my appreciation of the subject. [Read more…] about Psychology and Service Management
Principles for Billing for Services
Criteria for How to Bill for Services
When billing for services, a principle should be adopted that is simple, unambiguous, complete, fair, sustainable and strategic. These criteria apply equally to the provision of business services and technical services. This posting is intended to help service managers whose services are not easily billed on a transaction by transaction basis. [Read more…] about Principles for Billing for Services
Problem Workarounds and Incident Resolutions
The Scope of this Discussion
When a problem is identified reactively, it means that one or more incidents have occurredand it has been decided to take note of and perhaps investigate their underlying causes. I exclude from this discussion both the proactively identified problems—the problems identified before any related incidents have occurred—and those organizations that treat problem management as a discipline for resolving difficult incidents rather than a discipline identifying the causes of those incidents. [Read more…] about Problem Workarounds and Incident Resolutions
Taking Service Forward
Taking Service Forward
The initiative Taking Service Forward now has a Google+ community to support its work. The community is open to all interested parties.
Anyone interested in the work of developing a new service model and, ultimately, a service ontology, should consider joining that group. Our understanding of managing services depends on each of us to contribute her or his knowledge and experience.
Creating a service catalogue should not be so difficult!
Organizations find creating a service catalogue difficult
It is a great mystery why service provider organizations that attempt to improve the management of their services often do not have the most fundamental document—a list of its services. How can one even imagine trying to manage services if those services have not even been identified?
Service providers are so often daunted by the prospect of creating a service catalogue for many reasons. They end up spending many months trying to develop a catalogue. Often, the result still leaves much to be desired. Part of the fault is due is the confusion sown by the tools used to manage catalogues. Part of the fault is the poor communication between the service provider and its customers. But most of the fault is due to an extremely complicated approach to an activity that ought to be quite simple. [Read more…] about Creating a service catalogue should not be so difficult!