• Skip to main content
  • Skip to primary sidebar

This view of service management...

On the origin and the descent of managing services. We put meat on the bones.

  • Kanban Software
  • Services
    • Kanban Software Solutions
    • Consulting & Coaching
    • Training and Seminars
  • Posts
  • Events
    • Events – Agenda View
    • Events – Calendar View
  • Publications
    • Our Publications
    • Notable Publications
    • Quotes
  • About us

A Manifesto for Service Management Agility—Part II

14 September 2017 by Robert Falkowitz 3 Comments

This is the second part of a series proposing a Manifesto for Service Management Agility. It draws upon the Manifesto for Agile Software Development and proposes a modified version of that manifesto’s propositions, based on the issues characterizing the management of services. In this installation, I will discuss the third proposition, “Customer collabor­ation over contract negotiation”. How would a Manifesto for Service Management Agility understand, and possibly reword, that pro­position?1 If you wish to jump to my proposed new version before going with me on a journey and its digressions, here it is.

Forms of collaboration

Remember that the propositions of the Manifesto for Agile Software Development are meant to help increase agility in the face of certain issues in software de­ve­lopment. The issue in the third proposition is the inability of most customers to provide a software specification from
which the developers can create the application that the customer will genuinely want and use. Customers rarely have such skills and depend on seeing a prototype, a draft version or even the final version of an application to clarify, complete and otherwise evolve the explanation of what they want. A customer is not a chicken laying an egg as a one-time, all or nothing event. And when the developers build a product based on speculation, rather than based on customer requirements, yet an­other form of collaboration in software development occurs, based mostly on user feedback from alpha and beta testing or live use.
software customers do not produce specifications as if they were chickens laying eggs - a manifesto for agile service management
Fig. 1: Customers do not produce software specifications as if they were chickens laying eggs
Both these forms of collaboration are applicable to services. This is especially true when software is at the heart of the service delivered. The design, testing and imple­men­tation of a service require the same types of collaboration as for the development of software. Further­more, services resemble software in that the customer cannot decide if the service is correct until it has been delivered, until the service act is performed. That being said, many services are designed and the provider’s service assets acquired without any direct collaboration with customers at all. On the other hand, the service act itself can be very different from software. Whereas the customer normally works alone to use software, the service act often involves the active participation of the both the customer and the provider.
A barber cutting hair
Fig. 2: The service act of cutting hair requires provider-consumer collaboration.

Let’s take the simple example of cutting hair. The barber cannot perform this service without the cooperation of the customer. The customer needs to clarify the parameters of the service being delivered, specifying hair length, style, perhaps coloring or washing. The customer needs to be physically present. The customer must tilt and turn his or her head to allow the hair to be cut effectively. And the customer gives various signals of approval or disapproval that guide the progress of the haircut.

Similarly, a user support service requires the customer to actively participate in the exchanges that help to specify the nature of the support required, perform the diagnosis and even implement the solution. In the most extreme form, the service becomes a self-service, where the customer performs the entire service act.

Although these forms of col­la­boration during the service act closely resemble the col­la­bo­ration during software design and building, the key difference is the immediacy of the interaction in a service act, whereas design and building are generally mediated and consist of additional actions by the developer that do not depend on the presence of the consumer. I suppose it is possible for software developers to build their software in the presence of customers and by continually interacting with them. Maybe this would be the most efficient way to build software, if only the customers deigned to be available. Alas, this is hardly the general practice, even among agile software developers.

If I appear to be belaboring the obvious, it is because I am preparing the ground for what follows and the explanation for why I want to change the manifesto’s proposition.

Contract negotiation

Contracts are a good example of the fact that the manifesto does indeed value the items on the right of each proposition. In a com­mer­cial relationship governed by legal codes, a contract—be it implied or a signed document—is unavoid­able. In fact, the valuing of collaboration over contract nego­ti­ation is an example of the issue described in my earlier article on a Manifesto for Service Management Agility. Although a contract might specify many aspects of the commercial relationship, it is not likely to cover all conceivable types of interactions. Thus, as a way of creating value for both partners, collaboration in good faith is to be preferred to wrangling over the interpretation of what the contract might mean.

Although the Manifesto for Agile Software Development may have envisioned contract negotiation in its literal form, when we talk of services we need to think in broader terms, which I will address in the next section.

Contracting for services

There are various forms of contracts, both implied and formalized, between the service provider and the service consumer. If a service is developed in response to a request from a customer, there may be a contract defining the responsibilities of the parties so engaged. Once the service exists, there may be a contract governing the commercial relationship be­tween the provider and the customer. Or there might be a published set of conditions of service that customers accept, tacitly or explicitly. A commercial contract may be accompanied by a service level agreement. All of these contracts may be constrained by rules promulgated by the ap­plic­able regulatory authorities.

Negotiating such contracts is itself a co-ordinating activity rather than a transactional activity.1 Nego­ti­a­tion does not, in and of itself, provide any value to either party. Only when the negotiating has ended, the contracts agreed, the payments made and the work started does value start to flow. So, if a service were to have any value today, but its delivery would be delayed until tomorrow because of contract negotiation, it should be asked if the value increase due to negotiation is greater than the value decrease due to delay in receiving the service (see Fig. 3).

value gap due to negotiation - a manifesto for agile service management
Fig. 3: Comparison of net value of work with and without period of contract negotiation

As we have seen, if that negotiation establishes the definitions of fitness for use and fitness for purpose, they are likely to be temporary, incomplete and even erroneous, pending future confirmations by the customer that the service is correct. However necessary nego­ti­a­tion might be, the value of the time spent in trying to define fitness is minimized, if that de­fi­ni­tion is going to change and evolve as work advances. Thus, agility values the collaboration needed to advance the work over an attempt to specify and constrain the result at the start.

Agility recognizes that at the start of any new project, only a small percentage of what is ultimately needed to be known is already believed to be known, a very large percentage is already known to be unknown and to be determined during the project, and yet another large percentage is unknown and only discovered as work advances (see Fig. 4).

What you know and what you don't know during a project - a manifesto for agile service management
Fig. 4: What you know, what you learn and what you don't even know you don't know until you start the work

Constraining the agile service provider

We have seen that collaboration between the service provider and the service consumer is at the heart of both service design and service provision. It makes little sense to repeat the agile software de­ve­lop­ment manifesto’s pro­po­si­tion, say­ing that collaboration, which is of the essence in services, is to be valued more than something else. This would be a tautology. Services without collaboration could not exist. Indeed, collaboration is really a form of service. Instead, I believe that the issue of service ma­nage­ment agility concerns whether the service provider ever delivers a service other than what it has agreed with the customer. In this sense, the issue impacting the agility of managing services is not the same as the issue of collaboration and software deve­lo­pment.

The essence of the service provider-consumer relationship is that the provider performs acts valuable to the consumer that the consumer either does not know how to perform, or lacks the resources to perform, or cannot manage or otherwise has decided not to perform on its own. The provider does this via an offering of services, but also with the transfer of goods to the consumer. In return, the provider receives value, in the form of funding or payment for the services, in the form of increase in skills, knowledge and experience and in the form of enhanced reputation. When in doubt about what service acts to perform, the fundamental guideline should be whether the service act is part of this mutually beneficial exchange. But a service provider can hardly deliver all the services a customer might wish to receive. What constrains the agile service pro­vi­der?

First of all, the same reasons used by the service consumer for seeking a provider in the first place should also apply to the prospective provider. If that provider lacks the skills or the resources to provide the service, it makes no sense to attempt providing it, even though the consumer might request that service. On the other hand, the service provider might be able to indicate to the consumer another provider who is capable of deliver the requested service.

But what about the case where a service is requested that the pro­vider is fully capable of deli­ver­ing, but one that has not been negotiated in a contract, one that is neither in any service catalogue nor mentioned in a service level agreement?

The stiff, inflexible, arthritic provider might tersely reply, “We don’t offer that service”. Such an organization might be unwilling to take risks in re-allocating its resources, even for the shortest of terms. It is probably an or­gan­iza­tion where everyone is constantly busy and where everyone has the belief that they never have any time to do anything other than their prescribed tasks. When such organizations start to lose cus­to­mers or revenue, they tend to reinforce their existing behaviors, adding more and more controls, trying to maintain market share of an ever-diminishing market.

A more agile provider might respond, “Let’s see what we can do to help you with this request”. It is like a bather at the seaside, cautiously testing the waters. If the temperature is not too cold, she takes another step. If she is not surrounded by medusas, sharks or slimy seaweed, yet another step. And if the bottom starts to fall away, she can always quickly return to shore.

Agilely testing the waters - a manifesto for agile service management
Fig. 5: An agile provider advances incrementally and with low risk, by testing the waters

A fully supple provider might re­spond, “That sounds like a pro­mis­ing area for a new or modified service. Let’s investigate”. Its per­son­nel focus more on delivering value rather than keeping busy. It is willing to take greater risks to better understand what customers really need and how those needs evolve. It is able to nimbly re­al­locate its resources on a longer term basis, if it turns out that a promising new service has been revealed, just as it is able to quickly step back if the affair turns out to be unpromising.

The agile service consumer

The Manifesto for Agile Software Development is very much targeted to the activities of the software developer. It is based on a set of well-founded assumptions about how customers for software de­vel­op­ment frequently behave. But the spectrum of behavior of the service consumer is much broader, particularly when it comes to the service act itself. I doubt that there is such a thing as a typical service consumer. As we have seen above, the types of collaboration between provider and consumer during the service act is of particular importance. Should we not speak of the agile service consumer as well as of the agile service provider? As a service provider evolves and becomes more agile, the benefits of this agility will influence the behavior of the customers that return for repeat services. Similarly, the agile consumer may influence the service provider, making it easier to be more agile. The diagram in Fig. 5 gives an overview of how agility or rigidity on the part of the service provider and the service consumer impact the value of the service and how the partners influence each other.
agile provider vs agile consumer - a manifesto for agile service management
Fig. 6: Agility and rigidity among the provider and consumer impact each partner

The remarks in this comparison are meant to indicate relativistic trends, only. There is no strict dichotomy or frontier between being agile and being rigid. As the manifesto itself indicates, there are multiple axes for assessing agility and those assessments are along a gradient.

It may turn out that we need to add a new proposition to the Manifesto for Service Ma­nage­ment Agility to address the issues raised by consumer agility versus provider agility. I reserve that possibility for a future article.

Rephrasing the proposition for a Manifesto for Service Management Agility

Unlike the case of the software developer, a service provider’s a­gi­l­ity is not so much a contrast between its level of collaboration and its contracts. Whether agile or not, some level of collaboration is in the nature of services. Rather, the key issue, when contrasted with contract negotiation, concerns when the provider commits to an engagement with respect to the consumer. At one end of the grad­i­ent, commitment to engagements for service acts are made in advance, with no possibility of changing those commitments as part of the service act itself. In such cases, engagement is solely in the domain of contract negotiation, albeit that domain is expanded to include other forms of agreements, both tacit and explicit, between the provider and the consumer.

As we advance through the gradient of agility, the provider progressively delays commitment until the performance of the ser­vice act. By delaying this commitment, the provider keeps open more options:

  • to find higher levels of value
  • to investigate avenues for ser­vice delivery that were hi­ther­to unexploited or un­known
  • to better manage the flow of its work by delaying en­gage­ment to perform work until the last responsible mo­ment
  • to take advantage of se­ren­dipitous situations

Thus, I would rephrase the pro­po­si­tion in a Manifesto for Service Management Agility as:

Flexible engagement over fixed agreements

Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License The article A Manifesto for Service Management Agility—Part II by Robert S. Falkowitz, including all its contents, is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.

Notes:

1  That is to say, negotiation is a means for organizing and managing (co-ordinating) the “real” work of the service (transacting). Co-ordination might determine and frame the transaction or the service act, but it does not, in and of itself, provide anything of value to a customer. There are many similar terms for this contrast in the types of work. For example, David Marquet refers to “blue work” and “red work”.

Credits:
Fig. 1: Downloaded from https://timbercreekfarmer.com/chicken-nesting/
Fig. 2: See page for author [CC BY 4.0 (https://creativecommons.org/licenses/by/4.0)], via Wikimedia Commons: https://commons.wikimedia.org/wiki/File:A_barber_cutting_a_man%27s_hair._Watercolour_painting._Wellcome_V0019644ER.jpg
Fig. 5: By Samuel Soundararaj – Own work, CC BY-SA 4.0, https://commons.wikimedia.org/w/index.php?curid=49440796
Summary
Manifesto for Service Management Agility—Part II
Article Name
Manifesto for Service Management Agility—Part II
Description
The Agile Manifesto was originally written for software development. What would a Manifesto for Service Management Agility be?
Author
Robert S. Falkowitz
Publisher Name
Concentric Circle Consulting
Publisher Logo
Concentric Circle Consulting

Filed Under: Agility, Service Management Tagged With: agile, commitment, engagement, fit for purpose, fit for use, manifesto, manifesto for software development, rigidity, serendipity, value

Subscribe to our mailing list

Click here to be the first to learn of our events and publications
  • Email
  • Facebook
  • LinkedIn
  • Phone
  • Twitter
  • xing
  • YouTube

Reader Interactions

Comments

  1. Julio JuradoJulio Jurado says

    1 November 2017 at 17:14

    Very interesting approach about agile manifesto. Please let me know where can I get Part I to get a better picture of your point of view.

    Reply
    • Robert FalkowitzRobert Falkowitz says

      1 November 2017 at 22:08

      Thank you for your feedback, Julio. Part I is here: https://www.3cs.ch/manifesto-agile-service-management-1/

      Reply

Trackbacks

  1. A Manifesto for Service Management Agility—Summary | This view of service management... says:
    24 November 2017 at 10:33

    […] Flexible engagement over fixed agreements […]

    Reply

Leave a Reply Cancel reply

Your email address will not be published. Required fields are marked *

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Primary Sidebar

Kanban eLearning

Kanban training online

Recent Posts

  • Verbs, nouns and kanban board structure
  • The role of the problem manager
  • The Three Indicators

Tag Cloud

ITIL change management lean management incident management tools flow efficiency priority process definition rigidity Cost of Delay knowledge management process metrics flow impact kanban board histogram knowledge work kanban manifesto for software development risk resource liquidity ITSM value stream lead time bias Incident Management context switching cause agile kanban training incident lean waste problem manifesto service manager service request process automation statistical control chart service management tools
  • Kanban Software
  • Services
  • Posts
  • Events
  • Publications
  • Subscribe
  • Rights & Duties
  • Personal Data

© 2014–2023 Concentric Circle Consulting · All Rights Reserved.
Concentric Circle Consulting Address
Log in

Manage Cookie Consent
We use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes. The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Manage options Manage services Manage vendors Read more about these purposes
View preferences
{title} {title} {title}