Contingency as a Behaviour

After a late evening fixing a plumbing emergency at home, I’m reminded of the concept of contingency and how it can’t be practically be used as a buffer for all non-planned events.
So with my current main client, I start out early in the morning, long before must people (or birds) have risen. My wife told me about an hour before I was due to go to bed early in order to wake early that we had an issue.
Applying typical contingency management as found in most projects wouldn’t help. That’s the type where a task is estimated to take 2 days, so you add in some contingency for that task. What would have happened in that case? All the tasks had finished, we were effectively waiting for a deploy (ok, it was a deploy of one person to a train, so I’m stretching the analogy a bit)
Applying a buffer contingency may have helped somewhat, but again, the tasks had all completed, there was no buffer to call upon before the deploy.
House alarms/Burglar alarms encourage similar behaviours. You only discover that the alarm isn’t working when you come to set it on departing your house. Again, no typical contingency would resolve the issues.
In the above examples, we’d usually have to add more time for the journey in the morning (possibly even travelling the day before). But the more we do that, the more ridiculous the timescales become and the demands on those involved become more exorbitant to accommodate for any issues. Even with buffer management, at some point we’ve passed the point where the buffer can be applied.
The only alternative that I’m aware of for this type of issue is one of preparation. It becomes more about damage limitation. So in my example, have I prepared for what I would do if I have to remain at home, if the train is delayed or cancelled, if the my taxi doesn’t arrive on time, if my car doesn’t start? Those are more the failure modes, as can be explored using an FMEA matrix for example.
From that perspective, contingency isn’t just a buffer (whether applied to a single task or applied to the project), it’s a behaviour and it’s planning about what if. It’s about ensuring that you know what to do, have the resources to do it and can execute in the time required, at whatever time it happens.

How accurate is your testing routine?

Traynor Guitar Amp

Testing is not just for software, but for the business processes, organisation or service that you’re implementing?

I’ve seen many test routines that are too artificial, too removed from the reality of what the users will go through. Fortunately this factor has improved over time, especially with more focus on user stories.

Let’s consider one of the best examples of testing I’ve ever seen. Guitar amps are generally fragile. They’re usually robust enough for scrapes and minor bashes as you’re carrying them through doorways, but they don’t survive being dropped down stairs very well.

One amp manufacturer had a test routine of removing the glass valves (they’re replaceable consumables) and then throwing the test amp from the roof of the building to emulate the journey that some amps go through. On the ground, they inserted valves and powered it up to see if it would work.

How does that compare to your test routine? Is yours as accurate to the reality that it will be used in?

Here’s a clip of the actual test

Art requires rigour, science requires creativity


I heard this quote the other day, but I didn’t catch who originally said it.

Art requires rigour, science requires creativity

The first point is that it’s contrary to the standard view. The second point is that both perspectives are valid and that there shouldn’t be that much of a difference.

It then made me think of typical transformation programme roles and the relation between creativity and rigour. Most roles have a balance between the two, with that balance changing according to the standard role and, at times, according to the demands on that role.

Rigour And Creativity

For instance, process analysts should generally follow a set of standards. Business Analysts have to be more creative, but still have methodologies to follow. Service Designers have less rigour methods, usually a composition of tools and techniques rather than the standardised methodologies of previous decades. At the more rigorous side, project managers have their methodologies and frameworks to follow. Programme managers see a wider scope and have more creativity in organising the interdependencies. Which then fits nicely with my normal comment that a Business Architect has more in common with a Programme Manager than a Project Manager; there are more skills in common, even though the professional methods involved are different. Which leads me to the Business Architect who has to know when to be standardised and when to be creative. There has to be the flexibility to modify the approach to suit the needs of the client, depending on the stage of transformation.





Using Archimate to model OKRs for Business Motivation

A Fabricated Example of Using OKRs with Archimate

Following the theme of moulding different modelling languages, methodologies and toolsets together, I want to take a look at how to model OKRs in Archimate.

Once again, I’m using Archi (or ArchimateTool) with the Archimate modelling language.

OKRs do not cascade

Just because the diagram depicts a hierarchy, doesn’t mean that the objectives cascade down the organisational hierarchy. Following the logic in OKRs don’t cascade, I’ve taken the approach of the depicting the hierarchy, rather than how that hierarchy is achieved. In the article, Felipe mentions that objectives should not be cascaded down the organisation. Instead, objectives and key results should be discussed and agreed at each level. The resulting picture is the same either way, but the content of the objectives and key results may be different depending on the route.

Contributing Goals

Depending on the level of the organisation, many of the components that achieve an Objective will not be Key Results, but instead will be lower level Objectives (e.g. of the next team down in the corporate hierarchy or downstream in case of a flatter hierarchy). The diagram allows both Key Results and Objectives to form part of an Objective.

Modelling Goals and Objectives

Key Results have been modelled as Outcomes. Objectives and Contributing Goals (lower-level Objectives) have been modelled as Goals. In doing so, I’ve allowed for a hierarchy of Objectives to fulfil the concept of Contributing Goals. Had I gone with a model of Objective = Outcome, we would have seen a model of hierarchical outcomes which would not have made as much sense, especially to those having to achieve those outcomes.


From the perspective of Business Architecture, I’m interested in the alignment of actions to the overall vision. I like to see a clean line connecting actions of the workforce to corporate objectives to vision. Many organisations suffer because the objectives are cascaded down rather than agreed at each level. Combining OKRs with a culture of joint-goal setting has a good chance of resolving that core issue.

Notes about the diagram

The content is fabricated; completely artificial. I haven’t populated every single branch, but enough to indicate what could be captured. For those areas that I did populate, I kept to the concept of 3 key results per Objective, of which any of the Key Results can be replaced with Contributing Goals. You can flex that as you wish.

I’ve created a tiny environment in which the OKRs operate, featuring an internal driver for change, an external driver, the assessments for both and the corporate vision and missions.


The interesting concept for me regarding business motivation is that the diagram is agnostic of the organisation structure in that it doesn’t indicate which team or who is responsible for achieving which objectives or key results. I’ve done that on purpose.

If we imagine a typical organisation of 400 people. Each of those named 400 individuals could have Key Results to deliver. Some of those Key Results would contribute to team Objectives. Some of those team Objectives would coalesce to fulfil higher level Objectives and so on. That’s the bottom-up picture.

The top-down picture is that the strategy needs to pervade the organisation and steer the choice of actions and the delivery of those actions. At the top level, the objectives may be independent of who is going to deliver them, but shortly thereafter the key results or contributing goals would have to be assigned. And it’s likely that they’ll be assigned to relevant directors (in the case of stretch targets and keeping the operation running) or delivery teams (in the case of changes). However each of the delivery teams should have a sponsor. It’s that sponsor that’s actually accountable in this case for the delivery of the key result, whereas in many organisations it would be the delivery team.

Overall, OKRs force a concept of personal responsibility or rather, a concept of personal accountability if we follow a RACI model. For the majority of a workforce, the individual is likely to be both accountable and responsible for their key results.

What I haven’t address is the non-aligned use of OKRs, e.g. allowing or encouraging the setting of key results that do not fit with corporate objectives.

A Fabricated Example of Using OKRs with Archimate
A Fabricated Example of Using OKRs with Archimate

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.


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.


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.


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.


Look at the Evidence – the Spike and Delay Pattern in Social Care

A number of years ago, I was transforming a city’s social care directorate and, as part of that transformation, we aimed to reduce the time it took to do anything when interacting with the service. The transformation was based on a more fundamental need to free up workers to be able to do the work they were meant to do rather than having to fight the fires caused by delays and resulting failure demand. I instigated a methodical approach for identifying which cycles to focus on first. As the team progressed through the cycles, I noticed a pattern; it’s the spike of activity followed by a lengthy delay as discussed in a previous article.
As we looked in particular at a few cycles of spike followed by a delay, I routinely advised the team to question the need for that common feature of bureaucracy: the signature.

Why require a signature?

In the case of social care, signatures are often required from service users or their representatives. This can be as proof that the content of a form is accurate or as a record of the service user providing consent (either for data to be shared from the form or for the authority to request data from other agencies).
These signatures create the spike-delay pattern in which a short spike of activity is followed by a lengthy delay while the authority sends the form to the customers and waits for the return of a signed copy. Part of that delay is caused by the postal service in both directions. Part will be the time it takes the service user to open the letter, read the form, make amendments, find an envelop and stamp and then go to the post box. Considering the high percentage of infirm service users compared to the general population, that sequence of activities can take a long time. Then we have the additional wait time caused by processing the response as it arrives into the authority.

First approach

So, my first instinct is to remove the need for a signature and thereby remove the need for the spike-delay round. This could be changed from requesting a signature to providing information on the form that the data will be used. If you don’t agree, don’t submit the form. The response from staff was that we needed the signature as a record of consent and/or accuracy, depending on the form in question.
On the fact of it, that seems a reasonable and fair response.

What does the evidence say?

However, the data showed a different reality. What actually happened is that, even if the form wasn’t returned, the process could still go ahead. True, it didn’t go ahead for every service user, but the fact that it could proceed implied that the signature wasn’t always required. Or rather, wasn’t required all of the time. We were able to look at the data to understand how many service users progressed without signature, we were able to look at common characteristics, etc.
By presenting this understanding back, we ended up moving forward in our joint understanding of the process; joint in that the consultant and the team had the same understanding. Before that point, they had had different interpretations.

So where does that leave us?

An undocumented process or exception is a risk. In the above case, we had uncovered that some of the cases were allowed to progress without signature, but there was no documentation defining which cases could proceed and which cases had to stop. Instead it was left to individual judgment, but again without defined criteria. So what happens if the usual staff members weren’t present? Were the decisions they made equal and equitable to all involved? How did we measure the outcomes?
Depending on the type of organisation and service involved, there will be a different focus regarding the risk involved.
In this case, we had a process with an unclear gateway, e.g. do we continue or do we halt and wait?
  1. Complete the analysis in terms of understanding when the process can continue.
  2. Engage with service users to understand what they need out of the process, what their engagement should be
  3. As a team, choose a default option, either they progress by default or they pause by default
  4. Help the team define the rules that govern the exceptions
  5. Implement a training and induction programme for ensuring that everyone knows how to apply the rules
I always prefer the default option to be the one that improves efficiency, e.g. the one that’s the most common option or the one that removes a spike-delay pattern.


The wider understanding that, in most cases, the signature wasn’t required let us to a better solution. Had we not challenged either with data or further questioning, we would have been left with the difficult situation of lack of signatures stopping the process and the resulting action of requiring signatures in order to proceed. Instead by challenging the assumption and developing solutions to the issues of the spike-delay caused by several signatures for a sequence of documents, we were able to reduce the expected time from 6 months down to just over one day (actually 2.5 completions per week). That’s a massive difference in expectations for customer and the organisation serving the customer.
Anything to say, get in touch at @alanward.

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.


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.


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.

How Might We Apply Service Design to the Enterprise?

Business Architecture and Service Design

I simplistically take the view that Service Design is the concepts and methods of Design Thinking applied to making services work better for their customers. It’s a definition that works in the circles I most commonly move in, i.e. directors, programme directors, etc. It allows me to set the stage in which service design and design thinking both play.

However on the same stage, we commonly find KPIs, OKRs, Business Architecture, etc. And the stage starts to look crowded very quickly. We also start to see people pulling in different directions, like someone has let a mouse loose in the chorus of an Italian opera.

Operas and plays have directors, often many directors each responsible for their own domain, but with one artistic director responsible for the overall vision.


Now imagine what would the stage look like if the director asked the question “How might we…..?”.

It’s the opening line of many a design thinking ideation round. And it serves many purposes, explained better by others elsewhere.

Taking the stage analogy further, I hear questions such as “How might we produce more colourful costumes?”, “How might we light the back of the stage better?”, “How might we fill this part of the stage?”.

All of them are good questions and relate to the specific problem that has been uncovered during the discovery phase.

What they’re not doing is thinking of the entirety of the show. They just resolve the problem that was uncovered for their part of the show.

How might we approach this differently?

What they’re not doing is asking “How might we aim to deliver a better show?

Business Architecture and Service Design
Business Architecture and Service Design

Let’s look at that question more thoroughly.

It’s got the typical format of “How might we…?” introducing the concepts of inclusion, a shared problem, and an indication of possibilities and potential.

I didn’t stop at the simpler question of “How might we deliver a better show?”. That’s where service design typically fits.

If we step back from the stage and consider an organisation, even applying service design in this way would be a stretch. At this scale, we’d be trying to apply service design to the whole organisation, e.g. how might we deliver better services? Where typically each service would have its own change activity, often in the form of design sprints, etc. Instead, the simpler question of “how might we deliver a better show?” could be translated into a top-down design question for an organisation of “how might we deliver better products and services?”, “how might we become a better organisation?” or similar organisation-wide design questions.

However, the question I introduced earlier focusses on the aim, not necessarily the end result. It asks about how might we aim to deliver. In focussing on the aim, it allows us to explore the goals and how goals are set. It leads us to question what goals would be required in order to deliver a better show. In understanding the goals, we have to understand what good looks like, what counts as successful and not just in the eyes of the board, but in the eyes of customers. If we set the concept of goals smart enough, this could easily set the scene for continual improvement.

Alignment with Business Architecture

Back to the organisation, now that we’re asking about the aims, and we’ve looked at the goals, we can start to see how the goals for the enterprise could be set. This brings Service Design up to the area where it aligns with Business Architecture. While this may seem at odds with a top-down approach of setting KPIs, we have to ask the question of why wouldn’t we want to develop an organisation that is driven by achieving its goals that deliver value to customers?

Alternative Business Motivation

By combining Business Architecture with Service Design, there is the possibility of redefining the concept of Business Model Modelling. Typically that’s a top-down approach, modelling external influencers, assessments, goals, objectives/outcomes, etc. Taking the combined service design/business architecture approach would result in metrics that matter to customers as the metrics percolate up through the organisation, not cascade down as is more common.

Whereas the concept of One Metric That Matters may suit startups as they redefine/focus on a different metric per stage of development and growth, it would not be expected to change as often in a more mature organisation. Instead, we may see a single metric that is of most interest for a cycle of improvement. But here’s the clincher – that metric would be an aggregate of the metrics defined by exploring the problem space with customers, not one that’s defined by an executive board.

However we may see a situation where an executive board decides to steer the organisation away from its current model towards a different business model. In that case, we would consider a more top-down approach.

The Washroom Principle – The Easiest Way to Evaluate a Company

The Washroom Principle - Revised

There are plenty of methods for conducting due diligence, whether for partners, customers, suppliers or mergers. They’re lengthy and they’re expensive. There are times for adopting principles of formal Business Architecture, such as capability matching in M&A situations. But no matter what the deliverables indicate, there’s a useful and quick check to perform as a balance.

I’d like to introduce the quickest method for evaluating a company.

  1. Check the state of the washrooms nearest the directors
  2. Check the state of the washrooms in the middle of the office, e.g. where developers work, where finance work, etc
  3. Compare the two and evaluate according to the 4 box model below

The Simplified View

The Washroom Principle - Simple
The Washroom Principle – Simple

The simple view consists of a 4-box model with two axis; vertical for the quality of the director/board/exec washrooms and horizontal for the quality of the employee washrooms. That leaves us with 4 quadrants to review:

High quality for director washrooms, high quality for employee washrooms. This the ideal situation. Comfortable for all to work in, with employees respecting their organisation space.

High quality for director washrooms, low quality for employee washrooms. This is a poor situation. It implies one of a few cultural attributes. Either:

  • the directors think that they are worth more and merit more than the workforce,
  • the directors do not work closely enough with the workforce (and so do not see the disparity) and/or
  • the employees don’t care about the quality of the environment (probably resulting from not feeling respected)

Those fall into 2 different categories. The first two fall into whether there is a disparity in provision. The third falls into maintenance and behaviour in an environment.

Low quality for director washrooms, high quality for employee washrooms. I’ve never seen this exist. In all the organisations I’ve work for or consulted for, directors have washrooms of at least equal quality to that of the workforce.

Low quality for director washrooms, low quality for employee washrooms. At least their is parity in these organisations; everyone shares the same facilities. Typically I find these in public sector organisations where money is more importantly spent on providing the services to public rather than on office accommodation.

The More Complex View

The 4-box model gets us to the point of a very quick analysis. But thinking about it further, the relationships are slightly more complex. Hence the revised version:

The Washroom Principle - Revised
The Washroom Principle – Revised

The revision version uses the same axes as in the 4 box model, but hasn’t been restricted to just the 4 boxes. Instead we’ll take a closer look at the relationships between directors and employee washrooms.

Firstly, the box that related to low quality of director washrooms and high quality of employee washrooms has been extended to a triangle to cover half of the chart. This section, highlighted “Do not exist” relates to any point of the chart where directors have worse quality washrooms than employees.

On the left, we have a basic minimum standard. It’s not an absolute minimum, but one that covers a point at which employees are not being respected.

The top left is similar to that in the 4 box model, again highlighting where directors do not walk in the shoes of the employees.

That then leaves us with a blue area covering an acceptable region. This is the region in which behaviour of the directors matches that of the workforce, with no undue disparity and more a shared “we’re all in this together”. Even with the typical stretched finances of public sector organisations, we should be careful not to stray too far to the left that the lack of care in maintaining washrooms starts to be reflected in the quality of services provided by the workforce.


Despite being British (or perhaps because of being British and very British problems), I couldn’t bring myself to call this the “toilet principle”. It was too disparaging and cast the wrong tone for what I intended. Similarly, the lavatory principle didn’t work. The Bathroom Principle sounded good apart from the ambiguity of bathroom=lavatory or bathroom=room with a bath in. I settled on the Washroom Principle as it should be obvious to all (even those in the United Kingdom) which room I mean.