Category Archives: Practice

The service concept revisited #3: where are the people?

Johnston, Clark & Shulver write about the service concept mainly from the customers’ perspective. They also allude to relevant others (specifically, ‘business leaders’) when discussing the service experience, outcomes and operations. However, this only seems to be a subsidiary concern.

Their version of a service concept does a good job of summarising key aspects of a service in an informal manner — and I use it in this way. However, more structure is clearly needed when going beyond that informal summary.

We need to think about employees (more generally, service providers) first. If we take good care of employees, they will usually take good care of customers, too. So we need to think about the employee experience, outcomes for employees, and the value a service creates for employees as much as about the customer experience, outcomes and value.

But other people are involved in or affected by the service. These may include others in the organisation providing the service as well as people external to it such as investors. Furthermore, there may be regulators, the community the organisation operates in, and even society at large (think ecological or ethical externalities).

When thinking about customers (or clients), we ought to also think about non-clients and anti-clients. Tom Graves (2010, loc. 254-256) describes non-clients as “people who are not and will probably never be customers of ours, such as people who live in a different country than one we serve” and anti-clients as “people who don’t trade with us in the normal sense but who don’t like us or what we do”. (Also see Tom’s blog posts on anti-clients here.)

A good way of approaching this is creating a map of actors and their needs or stakeholders and their interests. See also Service ecology maps and the enterprise canvas on my old blog as well as Enterprise Design Framework: Big Picture on this blog.


A conversation with Tom Graves contributed to this post.


References

Graves, T. (2010) Mapping the enterprise. leanpub.com.

Johnston, R., Clark, G. & Shulver, M. (2012) Service operations management: improving service delivery. 4th ed., Pearson.

Johnston, R. & Clark, G. (2005) Service operations management: improving service delivery. 2nd ed., Pearson.

The service concept revisited

Yesterday

My discussion of The structure of the service concept is the most popular post on my old blog On Service Design. When I wrote it almost six years ago the topic didn’t seem to get much attention. Academic services marketing and service operations literature mentioned the term frequently, but almost no-one bothered to define it or describe its structure or content.

The Service operations management textbook by Johnston & Clark (the recent edition is by Johnston, Clark & Shulver) is by far the most thorough discussion I was able to find.

Today

I still like the idea of a service concept very much, in particular for its effectiveness. A well-written service concept can communicate a wealth of information in a very small space.

I typically use the service concept in a fairly casual form when exploring initial ideas for digital services with clients and colleagues. Interestingly, I’m back to the earlier (2005) version of the concept’s structure (although the differences aren’t huge).

Tomorrow

It’s useful for me to revisit the fundamentals and relate it to other relevant concepts, including some of the popular design canvases. Furthermore, I want to dig into its elements in more detail. I’ll be doing this in a series of future posts.

I look forward to discussing how the service concept works nicely with the things Tom Graves is doing (see his Toolsets for enterprise architecture overview) and, particularly, his Enterprise Canvas.

 Watch this space for updates…but don’t hold your breath.

Interested in the idea of a well-defined service concept? Let’s talk, please!

Other posts in this series


Related older posts

References

Johnston, R., Clark, G. & Shulver, M. (2012) Service operations management: improving service delivery. 4th ed., Pearson.

Johnston, R. & Clark, G. (2005) Service operations management: improving service delivery. 2nd ed., Pearson.

Not having all the answers

We thought that we had the answers
It was the questions we had wrong

 — 11 O’Clock Tick Tock, U2

I’m afraid I’ve been a bit of a disappointment to some of my clients and to some of my managers. Rather than dropping into a situation and having the right answer to the issue under discussion, I tend to ask questions. Many questions. Way too many questions. And it’s getting worse with age.

Why does he ask all these questions? Isn’t he an expert?

Truth be told, it hasn’t always been like that — but the result’s weren’t always pretty. I can provide an answer quickly even today, but this is probably not a good answer to your question. At least not to the question you should be asking.

I can’t know what that question is until we’ve had a good conversation. Even better, you might be able to decide what that question should be during or after our conversation. And while we’re at it you might be able to determine what a good answer to that question is, the one that considers the specifics of your situation — which you understand so much better than I ever could.

I’m with you all the way on this journey. I’ll try to ask smart questions, give you food for thought, identify issues and risks, but also opportunities, probably make some suggestions or recommendations. And I’ll tell stories about similar or related things that I’ve seen, of things that worked and things that didn’t.

We’ll explore a situation together and co-create insight.

I’m lucky that I meet more and more people — clients, managers, colleagues, partners — who value this approach.


Ruth Malan has a somewhat related Twitter thread right here.

Visual design, visual architecture, software architecture: Ruth Malan

As a software developer, software architect or anyone else who influences software, you’ll want to know about Ruth Malan. Ruth writes about software architecture and, particularly interesting, about visual design in the context of software architecture.

She runs renowned software architecture workshops with her husband Dana Bredemeyer.

Ruth has published tons of fabulous material. I think the links below make for a good start:

Ruth’s work is full of insights and — perhaps even more importantly — utterly enjoyable to read and work through.

Change mapping, tools for change: Tetradian on Patreon

I think you might be really interested in what Tom Graves (Tetradian) and Joseph Chittenden are doing on Patreon.

Their work is relevant for anyone involved in making change happen in organisations, i.e. you, me, regular people, and those in roles such as line managers, project managers, programme managers, product managers, product owners, system owners, business architects, enterprise architects, business analysts, software architects and so many others.

Fat markers and guided, incremental change

There has been a strong backlash against architecture and, perhaps more to the point, architects in the software development field for many years. One source of that backlash are parts of the agile community. Some of the reasons for criticism are poor practices by some architects as well as a misunderstanding of the suggestion to avoid big design up-front. Software, solution, systems and enterprise architects seem to be the primary objects of this criticism.

To avoid doubt, some of that criticism is well-deserved. As always, the devil is in the details and context matters. This post is not about the details or about who is more wrong.

By and large, that conflict seems unnecessary to me. Many of the ideas popularized by the agile movement have been accepted by people far beyond the software development field. In particular, many architects (in the fields I mentioned above and beyond) don’t need convincing regarding the value of respect for people, cross-functional collaboration, outcome orientation, and responding to change.

Having begun reading their book “Building Evolutionary Architectures: Support Constant Change”, Neal Ford, Rebecca Parsons, and Patrick Ku explain very well how software architects can meaningfully contribute to modern software development efforts.

They describe their notion of evolutionary architecture as follows:

“An evolutionary architecture supports guided, incremental change across multiple dimensions.”

That is certainly compatible with my understanding of architecture and the architect’s role.

Against his information architecture background, Jorge Arango states:

“A design career is a progression from thin markers to fat markers.”

He also highlights the need for design work at different levels of precision:

“You can’t design exclusively using whiteboard markers any more than you can with only fine markers. You need a combination of both.”

Jorge continues:

“As a leader, you don’t necessarily stop being a practitioner; you just move on to a fatter marker.”

Architecture is design, so all of this is also applicable to the architecture fields I mentioned above. It is also compatible with the notion of guided, incremental change, as well as the fundamental principles popularized by the agile community.

Jorge provides a meaningful description of what an architect-as-practitioner looks like. To me, this in sharp contrast to naïve interpretations of the “architects must code” idea. It also is a clear rejection of the idea that fat-marker wielding architects could provide comprehensive, detail-level specifications to those wielding fine markers or IDEs.

While I’m not sure I’ve been actually aspiring to these ever fatter markers, they certainly have been coming my way throughout my career. And that’s alright for this practitioner.

Liveable application landscapes

Sarah Mei published a Twitter moment titled Livable Code.

The moment’s description reads:

“The modern practice of software isn’t much like architecture or construction. The buildings are largely built. These days, we make a pre-built space work for whoever lives there.”

Sarah talks about the differences between a staged house and a liveable house, and uses this as an analogy to discuss codebases in textbooks vs. in real-life systems. Go read these tweets, although I’ll mostly just riff on the description. I’ll wait.

Let this sink in:

“The buildings are largely built. These days, we make a pre-built space work for whoever lives there.”

I still see a surprising amount of custom software development in companies, but I’m convinced we’ll see better decisions on what to build and, more importantly, what not to build in the future. Building software to “make a pre-built space [i.e. COTS software] work for [the company and its people]” can be very worthwhile, writing yet another variation of CRUD code for customer addresses or basic product information usually less so.

As a side note, “[making] a pre-built space work for whoever lives there” seems to be what a sizeable chunk of today’s practice of architecture and construction is about. In this context, I enjoyed How Buildings Learn: What Happens After They’re Built by Stewart Brand very much.

In the early 2000s when Enterprise Application Integration was all the rage, Gartner predicted that companies would begin differentiating themselves less by the features of their applications rather than by the way they integrate these applications. This statement resonated deeply with me and I’ve been waiting for it to become true ever since. (OK, so this might actually be true, but I’ve been waiting for it to become a conscious decision.)

This integration, together with modelling concepts and activities in terms of COTS applications’ data structures and functions, is what makes applications (i.e. pre-built spaces) liveable (i.e. “work for whoever lives there”).

While Sarah wrote about code, I’m convinced her insights apply equally well on higher levels of aggregation such as applications, a company’s landscape of applications and beyond the organization’s boundary into the shared enterprise (i.e. customers, suppliers, partners, and beyond).

To me, “[making] a pre-built space work for whoever lives there” is a powerful metaphor and honourable work.

Sarah, thank you for that.


Originally published on Medium.

Perspectives in (service|enterprise) design

All sorts of perspectives on service design and/or enterprise design keep spinning in my head and, I think, in many posts on the topic. Why not add one more?

This post is work-in-progress and an attempt to clean up my thinking.

Fundamental perspectives

As Tim Brown states in Change by Design and IDEO explain on their website, successful design has to satisfy the three constraints of:

  • Desirability (human perspective: Do people want it? Does it make sense? Is it meaningful?)
  • Feasibility (technology perspective: Can we do it?)
  • Viability (commercial/ecological perspective: Can we sustain it?)

The faculty of Industrial Design Engineering at Delft University of Technology recognizes these perspectives as peopletechnology and business.

Consequently, desirability, feasibility and viability are three perspectives that we will want to consider in most of our design activities. (We’ll have to ensure that we do not consider these to be constraints too early in the process so that we do not prematurely limit our thinking.)

Levels of abstraction

Drawing upon work by Tom Graves we can identify several levels of abstraction when taking a service-oriented view of the enterprise:

  • Purpose (Why are we here?)
  • Context (Who is “we”? Who and what else is around?)
  • Concept (Who does what for whom? When? And, especially, why? The conceptual (or functional) level.)
  • Implementation (How is this going to work? The implementation-specific level.)
  • Deployment (When will this happen? Who is and which resources are involved? The operations-specific level.)

I’ve been rambling about this before. This time I’ve omitted the action-record level, i.e. the level providing an historic record of activity within the enterprise. This brings us to:

Time

I think time is best considered to be a distinct dimension rather than an aspect of other dimension. It can be useful to consider the past, present and future when discussing desirability, feasibility and viability. Similarly, different time perspectives can play meaningful roles when discussing the different levels of abstraction introduced above. In particular, the action-record level is just a past slice of the deployment level. An action plan constitutes a future slice of the same level.

In the context of service design, we’ll often want to consider five different time periods: before, at the begin of, during, at the end of, and after the service encounter. This could be easily extended by considering distinct phases of becoming and ceasing to be a specific service provider’s customer (for services involving continuous or repeat services).

Over time, the enterprise changes its shape: participants leave and others join, resources disappear and others become available.

Jeff Sussna pointed out that these comments reflect a purely linear view of time that is typical of many service design efforts. I think that this is also true for many other types of design efforts including user experience and business process design. However, in many cases, the people involved have at least a latent understanding of the fact that life is not as linear as e.g. a customer journey map might suggest.

As designers we need to be more explicit about the fact that linear time-based maps are a gross simplification. We need to point out aspects such as concurrent or parallel processes (which may have varying degrees of interdependence) and other non-linear aspects of time.

More of Jeff’s tweets on the topic here, here and here.

What next?

The above is only a start, but the mess in my head feels a little more manageable already. Other dimensions can (and should) be added, the different concepts could (and should) be discussed in more detail. For example, entire books can be (and have been) written on desirability alone.

Updates

Changed “What else is around?” to “Who and what else is around?” in Context.

2016-02-20: Added reference to Delft University of Technology to Fundamental perspectives.

2016-02-15: Updated section on Time based on comments by Jeff Sussna.

The end of service encounters and customer relationships

I’m currently reading Service Design for Business: A Practical Guide to Optimizing the Customer Experience by Ben Reason, Lavrans Løvlie and Melvin Brand Flu of Livework. I’m enjoying the book so far and am convinced that it will make the field of service design much more accessible to a wider business audience.

The authors have extended the traditional three-stage model of service consumption (pre-purchase/pre-encounter, encounter, post-encounter stages) by another stage (begin) yielding these four stages: before, begin, during, after. Their reasoning for adding this stage is sound:

How customers begin their relationship with a service is critical to success…A good beginning helps to avoid dissatisfaction and makes customers more disposed to do more business with you later. –Reason, Løvlie, Brand Flu

In their takeaway messages for this chapter they conclude:

The beginning sets the tone for the relationship. –Reason, Løvlie, Brand Flu

Symmetry suggests we also take a closer look at how service encounters or entire customer relationships end. Thinking about our own experiences as service customers it becomes clear that the end stage of an individual service encounter or a relationship with a service provider can have significant impact on our evaluation of the overall service experience and the service provider.

For example, being rushed out of a restaurant after a nice meal with our partner (or having to wait too long for the bill) may well spoil an otherwise excellent experience on the finishing line. Similarly, if the service provider makes it difficult for me to leave a service after my needs have changed, my overall evaluation of a satisfactory service experience up to that point will be diminished.

In both cases, my readiness to re-purchase the service will be severely reduced as will be my readiness to recommend the service to others. On the contrary, I’ll probably complain about the service failure to anyone who cares to listen.

The authors seem to recognize this without highlighting the end of a service encounter or customer relationship as a distinct stage:

Past customers are also potential future customers–and are therefore always worth attention. –Reason, Løvlie, Brand Flu

In conclusion I suggest extending the discussion by considering referrals & recommendations by current and former customers, and by adding an explicit end stage to the model, thereby yielding these five service stages: before, begin, during, end, after.

 

Enterprise Design Framework: Frames

The third layer of the enterprise design framework as described in Intersection: How Enterprise Design Bridges the Gap Between Business, Technology and People by Milan Guenther deals with frames or viewpoints of conceptual models.

Higher layers of the enterprise design framework deal with anatomy and the big picture.

The four frames covered by the framework are business, people, function and structure.

This choice of frames seems highly useful to me, as do the descriptions of intent of and the selection of methods for the business and people frames. I’m less sure about the function and structure frames.

According to the paper version of the book, the function frame “captures the purpose the enterprise fulfills and the behaviours it exhibits towards its stakeholders. The functional viewpoint helps the understanding, prioritisation, and selection of a set of requirements the outcomes of a design initiative [are] expected to meet” (pg. 185). Requirements engineering is introduced as an appropriate design method for achieving these goals.

To me, requirements management tends to gloss over the fact that requirements are design decisions rather than natural laws or unfailing wisdom passed down from the powers that be–at least when practised as I usually experience it.

Sally Bean, an enterprise architect consultant, is quoted (pg. 215):

Requirements are often just laundry lists: someone makes them up, they are arbitrary, out of context and just plain wrong. –Sally Bean

That neatly sums up my experience, too.

Engineering seems to imply a degree of certainty or inevitability that the term design and the notion of a design decision avoid. In turn, this enables discussion of trade-offs between different decisions and design choices.

In addition to classic approaches to expressing requirements, tools such as value stream maps (or value network maps) and capability maps can be extremely useful (as well as many other methods and tools). I also recommend User Story Mapping by Jeff Patton.

The paper version of the book states that the structure frame “captures the objects and entities relevant to the enterprise, how they interrelate and form a structure. It enables an exploration of the problem domain in conceptual models and the transformation of those models in the course of a design process”.

In this context, domain-driven design as proposed by Eric Evans is put forward as an appropriate design method. Without intending to criticise domain-driven design in itself, this seems too software-centric and perhaps also too (software) implementation-focused in this context. The ideas put forward by Martin Fowler in Analysis Patterns and related writing would have come to my mind first. Skipping all the implementation-related stuff in Streamlined Object Modeling, the twelve collaboration patterns described by Nicola, Mayfield and Abney seem highly relevant, too. (You also might want to read this.) And in many cases, the simplest thing that could possibly work might be just a plain old concept map. Furthermore, service ecology maps and the Tom Grave’s enterprise canvas (especially the scope level) come to mind (more here).

This is not an all-out criticism of the enterprise design framework or the intersection book–on the contrary, I find both extremely useful. My perspective and my experience varies somewhat, and consequently so does my approach.