Manning the phone in the battery headquarters late one night in Basic Training I wiled away some time with a book I found. I read how Colonel Chamberlain’s extensive drilling of his men allowed them to execute a wheel maneuver in pitched combat that resulted in the successful defense of Little Roundtop at the Battle of Gettysburg. I also read about Napoleon giving his men campaign awards as a source of motivation observing, perhaps cynically, that “A soldier will fight long and hard for a bit of colored ribbon” and “Give me enough ribbons to place on the tunics of my soldiers and I can conquer the world.”
What these events have in common is the recognition that individuals respond to incentives and that positive, reward-based incentives lead to better outcomes. Chamberlain and Napoleon were effective leaders and process designers who knew how to instill confidence and satisfaction that would survive under extreme stress. Compared to the horrors of combat, keeping customers happy, informed, incentivized, and engaged while buying a fancy coffee ought to be a piece of cake, right?
Along these lines at this evening’s IIBA Pittsburgh Chapter Meetup, Jean-Marie Sloat discussed a field called Service Design. I’ll link to her presentation when it’s posted but for now I wanted to report that the content was extremely interesting, especially regarding the technique of Customer Journey Maps. It involved many of the concepts I’ve used in my own career as a process analyst, business analyst, and process improvement specialist. My formal training in Project Management, Lean Six Sigma, and Business Analysis (and even Scrum and Agile, which feel like more limited disciplines) overlapped across many of the same ideas, and Service Design seems to do the same thing. Indeed, it is known as being very cross-disciplinary. The disciplines the field sees itself as touching on or including are:
- Systems Thinking
- Design Research
- Business Modeling & Strategy
- Multi-disciplinary (this is more of description than a field, no?)
- Visual Design
The talk was really interesting to me because I could see my concerns, techniques, and emphases underlying everything Ms. Sloat described, and those considerations are doubtless addressed by her and her colleagues in the course of their work, but they were not her main area of concern, at least for the purpose of her talk. Her concentration, beyond the many interesting tools she described (that I plan to write about shortly and that will make this idea really pop), was on the emotions and reactions of participants in a process. She noted that she’s a fairly empathetic person and listening to and addressing the needs of people is an important part of her m.o..
I usually try to analyze a process by approaching it like a simulation, and for typical processes involving people and businesses this means discrete-event simulation. Whether a simulation is actually going to be built and run is immaterial, the analysis starts by mapping out flows of material and information in a process, including states, decisions, calculations, transformations, routings, and so on. Six Sigma improvements usually involve some combination of reducing variation, improving centering in a range, root cause analysis, and prevention of errors. Lean improvements usually involve a combination of compression, rearrangement, automation, and elimination.
It’s easy to imagine such techniques yielding improvements in bloodlessly technocratic measures like cycle time, loss and rework percentage, readiness, and cost savings. The question is whether any of these indicators reflect the emotions of the participants in terms of satisfaction, stress, abandonment of the process, shortcutting the process, or generating positive or negative referrals. The question is also whether these factors are considered when identifying the need for change in the first place.
I mentioned earlier that Service Design approaches the same problems as other groups of techniques but does so from a slightly different viewpoint, which is analogous to the way UML analysis drives you to examine computer systems from multiple viewpoints. If all of the techniques of UML are used you’re at least likely to consider a wide range of factors. This is no guarantee that you won’t do anything wrong, but such frameworks provide an organized way to make sure you’re being thorough. This seems to be a characteristic of many formalized bodies of knowledge. My feeling, after reflecting on tonight’s material, is that traditional techniques do, indeed, consider the emotions and reactions and well-being of process participants both as drivers and output measures of improved operations.
- My Six Sigma training included the Kano Model, the Likert Scale, and probably others I can’t remember away from my notes and references. These deal specifically with the needs and desires of customers.
- I’ve certainly designed user interfaces to improve control, understanding, and situational awareness, which results in improved confidence, efficiency, and even safety of users and other parties. This deals with the needs of providers.
- Establishing measures of effectiveness (MOEs) in terms of maximum wait times is certainly about customer well-being.
- Asking what people want and need must consider their emotions and needs at various levels (I learned about Maslow’s Hierarchy of Needs when I was in Junior Achievement in high school, so I’ve essentially always been aware of this).
- Having managers take suggestions from workers is an example of this.
- Paying people based on production or profits and not just hours worked takes emotions, well-being, and incentives into account pretty directly.
- A Total Quality Management (TQM) consultant I met in the mid-90s described how Ford Motor Company’s motto, “Quality is job one” was doubly effective because it not only reassured customers but also motivated Ford’s workers at all levels.
Indeed, most, if not all, process improvements are about making people’s lives better in some way.
We engineers and process analysts may seem dry, removed, technical, and unresponsive, particularly when we’re doing something geeky, complicated, and opaque that involves computers, but we’re ultimately trying to help people. Considering things from the viewpoint of Service Design may be a way to be thorough, to relate to the people we’re trying to help in a way that they “get.” You know. Emotionally.