Devolving Decision-Making through Frameworks

Jumbled music

If you create an appropriate framework, people can understand what to do when you haven’t told them the details.

All too often, organisations define rules that do not need defining. They may choose to set criteria for approvals, or host panels in order to evaluate submissions. A better approach in many cases is to create a suitable framework and devolve the authority to those who need it.

Suitable Framework

How would we know whether a framework is suitable

  1. What to do under what conditions
  2. What to do when those conditions aren’t met
  3. Guidance on what to do when the conditions do not make sense/do not apply
  4. Guidance on what to do when the process cannot be followed

Let’s have a look at Bobby Mcferrin and how he is presenting the scale.

  1. He creates a framework, defining how we are meant to respond based on the presenting condition in front of us (i.e. where he stands)
  2. He indicates that we’re only interested in the semitones – i.e. we’re not meant to respond to every slight step or assess the accuracy of where he has landed in order to produce microtones.
  3. The framework he has created allows to very quickly infer what the proper response should be when presented with a new condition (i.e. he steps outside of the boundary).

He builds on our already existing knowledge (e.g. what we’ve learnt in our early years, what we’ve observed from watching other musicians such as pianists, etc) and combines that with what he’s defined so far, so that the audience can infer the next note. Even though he hasn’t actually told us what that note is. 

Application

What could you take away from that?

Are there set (often regular) meetings within your organisation? Look at them and see what could be devolved either to smaller groups (even down to one person) if the rules can be defined.

Collaboration or Contract: A Decision of Flow

Mint tea

Ask anyone who’s been involved in any significant implementation and they’ll have come across the waterfall approach. It typically leads to a contractual relationship between one team who are working on artefacts that are then handed over to a subsequent team. While the flaws of waterfall have been well-documented, this concept of contract versus collaboration extends to many areas of work.

Example

Coffee Shop
Coffee Shop

Let’s use a brief story as an analogy for the concepts of contract and collaboration. It’s an incredibly simple story, but even with the simplicity, we can see the complications that can arise from a contractual relationship.

My wife and I walked into a coffee shop. I was left to order the drinks at the counter. So I’d asked what drink did she want.

“Mint tea please”

She orders a lot more hot drinks than I do, so she’s more familiar with the script that we all follow in coffee shops. And she definitely knows I do not order as many drinks, so she’s aware that I’m not that familiar with the standard scripts. In fact, I order hot drinks (maybe once a year) so rarely that it’s almost a new experience every time.

So I’m at the till and I’ve asked for mint tea. I hear in the barista’s response that it’s blended mint tea. So I’m then thinking:

  1. Is blended mint tea acceptable?
  2. Are there are other teas in this coffee shop which are more acceptable?

I decide it’s acceptable.

I’m then asked what size. How would I know? I was just told mint tea. And I know for a fact that my wife chooses different size drinks, but mostly takes the larger options in general.

So I ask for big.

Not good enough, it’s one of those shops. They have small, large and grande (or some phrase like that). So which is it; big = large or big = grande?

And what happened to medium? (but that’s another story)

I choose large.

Then I’m asked take away or stay in. Thought I’d already asked for the tea to go, but no worries, it’s a busy shop with background noise, so I say to take away because I know the context.

I’m then asked if I want one teabag or two. Woah, where did that one come from? It’s a cup of tea, a bag goes in in order to flavour the hot water. The longer you leave the bag in, the stronger the tea. Mint tea works the same way, doesn’t it? So what would be the advantage of two? Rather than ask what that benefit would be, I chose one since I hadn’t seen many cups with two bags before.

Seeing the way the interaction was heading, I waited for the “do you want extra water with that?” question. Fortunately that didn’t come.

On being given the takeaway cup, I notice it’s hot to touch, but it doesn’t take a genius to realise that. So I look for the holders and place one around the cup.

Analysis

The wrong tea
The wrong tea

That coffee-shop interaction was a contractual one. It depicted a scenario where one person (my wife) stated her requirements, which were then interpreted and delivered by another person (me).

Although it’s a very simple scenario, it highlights how much needs to be known to be able to be fulfil the customer’s expectations.

There were numerous attributes that had to be chosen in order to complete the transaction and deliver the request:

  1. Feature/Product = Mint Tea
  2. Variety = Blended Mint Tea
  3. Size = Large
  4. Number of teabags = One
  5. In or out = Takeaway
  6. Temperature to hold = Need a holder

My wife only stated one of those. I, as the contracted partner, had to answer a variety of questions based on knowledge, size based on estimate, number of teabags based on memory, takeaway based on context and joint understanding, holder based on real-world experience.

That ratio isn’t uncommon with any set of requirements. No matter how well or how detailed you define your requirements, there will always be questions that need to be answered. If you’re not there to answer the questions, then it introduces a delay or it introduces a risk of diverging from your (unstated) requirements.

Collaborate

2 computers at one desk
2 computers at one desk

Now, imagine the same scene, but with my wife also involved. The barista would be able to ask her directly, or at worst, ask me to then ask her (e.g. if she’s had to sit at the table rather than stand at the counter). While the latter scenario introduces some back and forth, it’s still more timely and risk-reducing than me guessing and getting the order wrong.

That’s the situation that occurs in many organisations. An artefact is commissioned. It’s defined and passed onto another group. Who digest the documentation and then ask questions. And it takes time to progress through this rigmarole.

While I don’t think the people involved must be present in the same room all the time, they do have to be able to communicate in a way that doesn’t lead towards a waterfall approach.

So the default position could then become one of collaboration rather than contract, with those involved working together to define and review. Now while that concept is well-adopted in more agile organisations, those organisations that have remote development teams can struggle with some of the implementations.

However, it’s not just IT development. The concept of collaboration should be present for any change, any time that an organisation progresses, especially within the organisation itself. And that’s where a number of organisations fail.

 

Finding a balance between the needs of the organisation and the needs of the customer

Checkout Till
Some companies are immature in their approach to customer relationship management (CRM), but at the heart is a desire to get something for free. And that’s wrong.

The scenario

You look around a shop, you pick something up, take it to the checkout, wait in a queue. You notice that the queue is moving slowly, despite most customer only having a handful of items and then paying with credit card. Maybe the link to the credit card authoriser is a bit flakey today? It’s your turn at the checkout. Once the greeting and the small talk is out of the way, the dreaded question is delivered by the sales assistant “Can I have your email address please?” or some variant on that request for your email. This may be followed with “can I take your postcode?” or “do you already receive our newsletter?”.

The analysis

What’s happened is that the company’s desire for collecting valuable customer data got in the way of its prime purpose and I’m guessing the prime purpose is to make money by selling goods that customers want to the customers that want those goods.
There are other methods for collecting customer data. Some methods cost more than others, some are more accurate than others, some are more comprehensive than others. More importantly, some are less demanding to the customer and even less demanding to the customers in the queue behind them.
Often the desire is created due to a new multi-channel campaign that wants to treat all customer channels equally, not recognising that there’s a different social contract in place when you’re in a store to the one that’s in place when you’re buying on line. Companies that slow down the queue in order to collect information have broken that social contract.

Exceptions

While I’m against slowing queues down, I can concede that short analyses are valuable. This would mean performing the data collection during the natural queue created by your checkout processes. Even then, I’d be concerned that you have a queue and, while it may be acceptable to have queues, I would question an organisation if it counts queues as excellent customer service. If the answer to that is no, then we can prompt other questions such as relative priorities, but that’s for a different article. The take-away here is that companies usually choose acceptable customer service over exemplary customer service.
There are potentially other methods that they could use in store. One that never seems to be used apart from by car salespersons is the option of walking up to a customer, engaging in a conversation and then asking for their contact details. Can you imagine this working in your supermarket, the next time you buy a phone or the next clothing shop you go into? While I don’t believe we should all move to the used-car sales model, I do believe there is room to find a better balance.

The Real Issue

There is no need to wait until the checkout to ask for this information. In fact, asking at the checkout is contrary to the purpose of the checkout.
What’s missing is that the company is trying to build a relationship with the customer. But rather than trying to do that in an underhanded manner at the checkout till (sometimes in the guise of asking to email a receipt), why not engage with that customer while they’re perusing? This highlights the actual issue. It’s not what the company wants, but what the customer wants. What value is the company going to deliver to the customer in exchange for a longer-term relationship?
So rather than trying to obtain an email address for free, consider what you’re going to provide so that the customer would actually want to provide their email address. When viewed in that light, a 10% voucher may not be sufficient.

Alignment

I take issue with any company that slows down the purchasing process for the purpose of collecting customer information. Whether it works financially or not, it’s a bad customer experience and not one I want to see implemented in any shops. I believe in a managed flow from a lean perspective (that’s Lean, not Lean Startup) and so, simplistically, anything that gets in the way of that flow is waste and should be avoided. Instead I’d provide options for collecting emails while people are queueing, while they’re on their way out (e.g. a pedestal table, pen, cards and a ballot/post box on the way out) or have it built into the product itself (like the cupcake liner mentioned in an earlier article).
In short, engage with customers at a more appropriate time (or stage of their purchase) and collect data that’s appropriate to collect for your future interactions but don’t make the purchase process worse just so that you can collect that data.
Any comments, you can find me @alanward.

Lack of Design Thinking in Supermarket Car Parks

Car Park
Car Park
Car Park

I’m convinced that there’s no thought to place of people in the design of most supermarket car parks.

Poor Design

I’ve just been to a great example of poor design.

When driving in, you turn off the main road to a roundabout. At this roundabout, you turn right, away from the store, to the main car park. You can turn left, towards the store, to the disabled and parent+child spaces. There is no path between the main car park and the store. So at the roundabout, we also have people walking from their car to the store and back from the store, laden with shopping, to their cars. All those people also have to walk through the disabled and parent+child car park. Even in that car, the only two differences are that the spaces are wider and closer to the store. Once you’re out of your car, there is no pathway or walkway, even as disabled or with a child; you’re straight into route of cars (with their drivers looking for spaces).

More Common Example

I’ve always wondered why every supermarket car park has the access road running right past the front of the supermarket pedestrian entrance. From a day-to-day safety perspective, it doesn’t make sense. It forces drivers to drive their cars past pedestrians trying to cross the road from the car park to the store. It feels like lazy or shoddy design. I hope that it’s a law or bye-law regarding providing access for emergency vehicles. However, even if that were the case, is the road right in front of the superstore the correct approach?

Attitude

What’s missing here is the realisation that we’re all pedestrians. Whether we drive or not, at some point, we’re walking or moving with the aid of a wheelchair. That element has been forgotten and instead, the focus has been placed on the car, not the people.

Cars can’t speak for themselves, they can answer questions in a design sprint. Only people can. And there will always be more people than cars going to supermarkets. At least, until automation becomes more prevalent.

Can you imagine what a car park would look like if it were designed with people in mind first? Better walkways, better trolley parks (self-driving trollies?), more visible paths splitting pedestrians and cars, straight walkways that go from the store to where people want to get to (as opposed to the current approach of pathways where it’s least awkward for cars).

Fundamentals of Process Mapping – Introducing Subprocesses Part 4

From what we have seen so far, we’d have 3 separate, but related process models. One for each of the following:

  • Buy a Book
  • Choose a Book
  • Pay for Book

Numbering the processes

Some of that was getting difficult to describe. The fact that Pay for Book is a process step in one diagram and a whole process was causing some difficulties in describing the relationship. I’d recommend reading through it again, slower this time, checking that you are certain which process step is being to referred to at each point.

Some standards help understanding by providing a key to each process step. The most common method is to assign a unique number to each process. The benefit of this is that you can define the process once (e.g. say we define “check stock level”) and then we can use it elsewhere as a process step (e.g. in an ordering, logistics or auditing processes).

Some standards help you navigate the hierarchy by assigning and set of numbers, e.g. everything at the top level has one number (1, 2, 3, 99, 123, etc). The next level down would have another point number so that all the process steps in process 1 would have numbers of 1.1, 1.2, 1.3 and those in process 3 would have 3.1, 3.2. Down another level and we’d see labels such 1.1.1, 1.3.4 and 4.3.5. This does lean towards a parent-child relationship between processes. Not necessarily bad, but I prefer more freedom.

The more levels and the greater the complexity, the greater the need for a naming convention.

Reuse

By allowing processes to appear in other process maps, they can be reused. For instance, theScan Book process step above could be used elsewhere, e.g. to retrieve information about a book such as how many are in stock, price, different versions, etc. The process step would be the same in all processes.

Common Mistakes

  • The Process Start in a subprocess doesn’t relate to any process step in any other process map. So you’d never actually use this process.
  • The process overlaps with the previous or next process in the chain – as we saw earlier with the Scan Book process step.
  • The Process Ends (i.e. the outcomes of a process) for the subprocesses aren’t reflected in the higher-level processes.
  • Change in process mapping methods – giving a process step to a different analyst can result in that process step being described using different methods or no standards. This isn’t necessarily a mistake, but should be considered before responsibility for process mapping is delegated.

Why 3 Levels?

You don’t have to have 3 levels, they suited the early part of this article. It’s a common concept in a lot of domains. In Data-modelling, the hierarchy of Conceptual, Logical and Physical data models has long proved beneficial. Closer to the process domain, Alistair Cockburn was promoting multiple levels of Use Cases almost a decade ago.

When do you stop going smaller?

When everyone understands the process step without having to ask any questions.

For many clients, two levels is sufficient for the process analysts to be involved in; a high-level mapping of all the processes, then a more detailed view of each process. a 3rd level may be created for the more complex processes that require more analysis. Developers are likely to look for further detail, so either another level or different diagramming technique can be used.

Recap

  1. A process step can be described in more detail in its own process map
  2. Processes can be re-used in more than one process
  3. Process maps should contain sufficient information to relate to each other – using the Process Starts and Process Ends
  4. Different readers will have different ideas of how much detail they want to see
  5. The different levels of process maps can be used for different audiences
  6. As the number of processes and levels increases, the greater the need for a naming convention

Next Article

Notice that Buy a Book was written from the buyer’s perspective whereas Pay For Book was written from the Bookseller’s perspective. We’ll discuss how to handle that in the next article.

Which Diagram type?

All the diagrams above could be process maps. In some cases, especially with mapping the flow of user-interfaces, then UML Sequence Diagrams can be more useful than Activity Diagrams. I’ll explain why in a later article.

This is an article in the Fundamentals of Process Mapping online book provided by Alan Ward

What’s in a process?

I’ve had a view for a number of years now that a process cannot be described with just a process map.

Well, not in its entirety. A standard process map usually consists of rectangular boxes linked with arrows. Better process maps have some variety in the size and shape of boxes representing the variety of actions and decisions that occur at the process steps. When good, these process maps conform to BPMN, UML (Activity Diagrams) or other similar standards. When bad, there can be missing outcomes from decision points, missing references to other processes or references to missing processes and so on, the list goes on.

How Deep?

However, no matter how good the process map, they cannot completely describe the process. Take the instance of capturing an AS-IS process, perhaps during the check phase of lean systems. A process map would only give a brief description (1 to 20 words maximum usually) of the process step in question. Just as a process can be broken down into process steps, process steps can often be broken down to a further level. And then those steps can be broken down again. In practice, there’s a point of diminishing returns after which you decide that enough detail is enough and that to gather more detail, although useful, would not be cost-effective. So it follows that no matter at what level you stop when looking at business processes, there’s always a level of detail that you’re missing. There are exceptions to this, for example when designing circuits, then the process steps may well be atomic. In most cases with business processes, there are further, more granular levels.

BPMN and UML Activity Diagrams are good at showing relationships between steps, including the order and control flow of the process steps and how they link together. That’s useful and should be used. The process maps should be consistent with the standard that the author is using. So make sure that if follows the rules. Simplistically, any decision point has to have at least 2 outcomes. If it has only one, then there wasn’t a decision. How does the standard deal with branching, merging, delays, broken or disjointed processes? Find out and use it. But that’s not all.

So what is missing from a process definition?

Most often, I find that the underling rationale for the process is missing. A process or a process step exists for a reason, usually it’s do something. In reality, the process steps in a process map are representations of what something or someone does on a routine basis. More commonly, it’s an actor (a person or a system) doing an action to transform an object. This could be processing an application form, taking a payment, assessing eligibility, writing a letter, creating an account and so on. Let’s take one of those in more detail. A likely scenario of processing an application would have:

  1. a customer submitting an application form
  2. the organisation receiving the form,
  3. an agent checking the application for completeness
  4. the agent recording the application on the organisation’s system
  5. the agent assessing eligibility
  6. the agent giving a reply to the customer (by letter or email)
  7. if the application was accepted, then a new service or entitlement is started on behalf of the customer

Input and Output 

The common item throughout all the above is that there’s an application form being processed. The customer fills it out, the agent assesses it. It goes on a journey and the process steps cover that journey. The application form probably has a “for office use only” on it. Sound familiar? Well the agent would be filling out that part. What’s important is the each process step receives the application from the previous process step. So the application is an output from step (1) and an input to step (2). By noting these on a process map or in an accompanying text document, we’ve improved the quality of process map incredibly. So if a process step needs to receive something, list it as an input. Similarly for output. Often, any analyst who’s previously been a developer  will probably focus on data inputs and outputs to a process, e.g. parameters that have to be passed along the journey. Watch out though, paper, faxes and files are equally as important.

Transformations 

Back to the rationale, the process step will transform the input into the output. These transformations should be recorded. So if the agent adds something to the application, record that fact in the process description. Bear in mind that the process step can (so far) only achieve an output by transforming an input. By recording these, we’ve added more detail and more rigour to the process definition.

Record Data Usage 

In step (5), the agent assesses eligibility. Maybe they retrieve some customer details based on the information in the application form and perhaps also retrieve a sliding scale as a reference. These are pieces of data that the process step uses to change. Ignoring human emotion, the output can only come from a combination of input, retrieved data and an algorithm. From what we covered earlier, the algorithm could be broken down to more more granular steps. The process step could also update a retrieved form or create further data to be stored somewhere. This retrievals and updates should also be recorded as part of the process definition. At a high level, I’d expect to see which systems are being used per process step. At the next level down, we should cover data at the conceptual level (e.g. Customer, Car, Address). Another level down, I’d be looking to record usage of data at the logical level (customer first name, customer last name, address postcode, car registration number). To some extent, the old Data-Flow Diagrams handled the flow of data between process steps. The combination of ERD and DFD seems to be have been lost in today’s modelling skills.

Channels 

In step (6), I mentioned “by letter or by email” rather lazily not differentiating between how the process may differ for each channel. The process should be consistent with the channel that it applies to. If there’s a change in the channel or medium, these should be recorded. Coming from implementing multi-channel solutions, I like process maps to be applicable to all channels and only show the exceptions. In practice, this often requires a split, either due to the time nature of the interaction (synchronous or asynchronous) or whether it’s electronic or in person.

Where? 

Reading the steps in the list above, you’d expect steps (2)-(7) to be performed by an agent in the same place. If the geographic location changes, then record this. Same goes for teams, although using the swimlanes in BPMN and UML should already cater for these. Ideally, anything that changes about the environment in which the processes are conducted should be recorded. It’s best to describe what I mean by example here; if an analyst or group of analysts are mapping a group of processes, if all the processes are performed in one location, then that can be recorded in the text description of the process. If the location changes per process or process step, I’d expect to see each step have the location recorded. It’s better to be explicit rather than leave people guessing, especially where you have the opportunity to reduce ambiguity.

Summary 

To recap, a process definition should consist of at least:

a) a textual description of the process and each process step
b) a control flow of the process through each process step
c) zero or more inputs to the process and to each step
d) zero or more outputs from the process and each step
e) zero or more retrievals for each step
f) zero or more updates for each step
g) environmental variables

Any decent modelling tool should as a minimum allow the analyst to capture this information, be it diagrammatically or textual.

In my experience, the vast majority of analysts do (a) and (b) only. Some analysts make an effort at doing (c) and (d) with varying degrees of success. Get any analyst with a process background rather than full understanding of the systems development life-cycle and you’ll be struggling to get anything beyond (c). I’ve made some generalisations, but they are true from my experience.

Yet there’s still more to capturing an accurate description of a process. Each process has attributes (e.g. time taken, peak volume, average volume, etc.) that should also be recorded.

Service Redesign

Yorkminster
Yorkminster
Yorkminster – design on design on design

Are you designing a service or transforming an existing service?

For redesign, we help organisations to reform teams more logically and change the way that they work resulting in more efficient processes. This is more structured and more logical than older BPR (Business Process Redesign) concepts as we’re heavily influenced by Lean but in a service environment.

At the smaller end of the scale, there are service improvement engagements and delivering strategies and methods for continual improvement. We can’t implement the continual improvement for you; that has to come from within your own organisation, but we can be there with you on your journey.

For new services, we assist organisations in developing their new operating models. At this level, it’s not the strategic target operating model, it’s a more tactical design that has to be workable in a live situation with real customers. It should link to the target operating model and indeed should move your organisation closer to achieving that target.