Treat your customer as valuable

Treating your customer as valuable could be the first step to understanding what your customer values.
Shopping Carts
Shopping Carts

I went shopping in my local supermarket. It was eventful for the number of things that went wrong for me, all of which could have been prevented with some foresight and some real-world gemba.

It was early in the morning so I had chance to see the store operate with fewer customers. This also meant that I could move around the store quicker than usual. So from that perceptive, the shopping expedition was a success….at least until the checkout process.
For a large supermarket, there were no checkout assistants at that time in the morning. Instead, there was a bay of 4 self-service checkouts. That’s not too bad, I find them very useful when I have a handful of items. However on this occasion I had a full trolley and had no choice but to use the self-service checkouts. The first issue with this is that there is very little space to put items once you’ve scanned them. To keep scanning more items, I had to swap out each bag once I’d filled it. Every time I did this, the machine told me off. This meant that a checkout supervisor had to come across and tell the machine to ignore the missing bag. That dance occurred several times since the trolley was full.
I valued the speed and efficiency of being able to pick my items at my convenience. I didn’t mind whether I scanned the items or whether they were scanned by a checkout assistant. However I did mind the lack of planning for catering for shoppers who had more than a basket. And I minded being reprimanded by a machine for solving a problem that it was creating. I’m confident enough that I have zero issues with being reprimanded by a machine; it’s just a set of algorithms encoded by another human. In this case, a human that didn’t foresee the machine being attached to a tiny tray and being used by a shopper with a trolley. But I did mind the rigmarole that it created.

I had a brief stay in hospital a few years ago. Everything ran smoothly until I was discharged. From my perspective, I was still a patient regardless of the official status. I was in hospital, feeling lousy and weak after 5 days of little to no food or drink and due to continue with medication for a further 7 days. Nothing major, but enough that I was allocated a hospital bed (if you’re familiar with the UK’s NHS, that’s a good measure of a condition). I was discharged in the morning, roughly 9:30am and was due the following dose of medication at 10:30am. Unfortunately, medication after discharge isn’t dispensed by the ward staff, it comes from the hospital pharmacist. I spent 3 hours waiting for the hospital discharge to deliver my medication to the ward so I could go home. That meant I couldn’t arrange transport since I didn’t know when I could leave. More importantly to me, the medication I was due at 10:30am didn’t arrive until the afternoon. During this time I occupied a hospital bed, although I think I would have been moved to a day room had the ward been full to capacity.



At that time, NHS hospitals in the UK had a 28 day return policy, in that they were fined for patients who were readmitted for the same condition within 28 days of discharge. That goes some way to ensuring that discharges are medically appropriate. Unfortunately it doesn’t go to check that the discharge process itself is appropriate. It’s still focussed on the condition that the person was originally admitted for, rather than the smoothness of the discharge process. It’s as if the patient is no longer a patient once medically discharged, assuming they will be safe in their environment (e.g. home). The actual situation is somewhat more intricate than that but the effect on the discharged patient isn’t any different. To them, they’re still in hospital, still expecting the rest of the hospital services to be working to achieve the full discharge (not just the medical discharge).
Similarly, for the supermarket. The main experience was great but marred by the part of the process where I actually get the goods I pay for.
In neither of those cases did I feel fully valued. In the case of the hospital, I can forgive easily. However, from the perspective of efficiency, there’s a lot to be said for getting me out of the hospital as quickly as possible, so as to free up resources for others who need them. The more time I spent in the hospital following the medical discharge, the more failure demand I created (simply by being there, not that I created it on purpose). And the more risk of something happening while I was on the hospital grounds.
This leads onto the peak-end rule where we attribute a large portion of our memory of the experience based on the peak and the end of the customer journey. So no matter how good a service you provide to your customers, they’ll remember how it ends.

Outsourcing Your Future – part 2

theatre seating

There are a number of company-hosted competitions, events, hackathons all with the aim of introducing innovation to the host company. I questioned the rationale behind these initiatives in the first part of Outsourcing Your Future.

The P&G Signal Accelerator Innovation Brief for Daycare Subscription is a good example of how these can be presented to the public, encouraging submissions from other companies. It opens the door for innovation with the potential reward of access its brands for the external company.

Whereas I questioned the motivation behind the initiative in the previous post, I want to look at other aspects in this post.

Maturity of the host

When I talk about maturity, I’m usually thinking of the difference between experience and wisdom. Someone can have a great number of experiences, but they may not be wise from what they’ve experienced. Similarly, an organisation that is mature in age is not necessarily mature in its capabilities.

By hosting innovation events, older companies are trying to introduce the capability of innovation into their organisation. It’s a parallel move to that which we saw in call-centres, then contact centres and also in shared services solutions. The company focusses on its core and outsources some standardised capabilities of its business.

In principle, that seems fair, since innovating is just one of many capabilities (we could give it a better name, but it’s still innovation). The bigger issue is that the target of these innovation events is often the core business; something which very few chief executives would ever dream of outsourcing. However in hosting innovation events, that’s what they’re doing; they’re outsourcing the company’s future.


Having read through a number of calls-for-applications and similar invites, plus being familiar with a larger number of events, I see two directions forming.

  1. Rather than the innovation happening on the inside and pushing it’s way out, the innovation is nurtured on the outside and is adopted internally. Or more often, it meets the resistance of the host organisation and fizzles.
  2. Innovation happens on the outside and is then partnered, e.g. you keep the external startup as an external and then purchase services from it (which may be viewed as allowing it access to your procurement team, but it’s still money transferring for services). That partnership arrangement keeps the innovation skills on the outside, but allows you the benefit of the innovation for a cost.

Managing risk

Considering the age of many companies hosting these events, they will have rigid governance procedures. Startups, on the other hand, do not. They are more flexible, more able to change direction and quicker to deliver. By allowing other companies into your problem space, you take advantage of their ability to take shortcuts that wouldn’t be allowed in your organisation. Those short-cuts may not be short-cuts in reality, it could well be that your organisation has created obstacles that do not need to be there. However, the result is that the external startup can deliver more quickly than your internal teams. That speed of delivery has value in terms of being able to conduct business experiments and learn from the experiments more quickly.

But as well as being able to make short-cuts, startups can take riskier approaches, which is easy to see when one of the guiding mantras of the startup ecosystem is “Do things that don’t scale” originally from Paul Graham.

By hosting innovation events, you’re outsourcing some of your risk management. You allow yourself to focus on the product, not how the product was developed. That doesn’t free you from all responsibility, but it does allow a shift in responsibility at significant points in the development process.


There’s been a growing trend of recognising the concept of technical debt. In the same way that shortcuts or short-term decisions for technology have to be paid back later, there are other forms of debt. I’ve discussed process debt before.

Innovation events, especially sprints have an element of creating debt. It’s not necessarily bad debt, since the act of bringing people together to progress a common goal has significant value, but the team involved may decide to do something quickly because of the time available. Even if the decision is “I’ll do it in this tool to get it ready by Thursday evening and, if the concept is accepted, then we’ll do it properly next week.” – that’s still debt. And we’ll see those decisions across process, technology, management structure, job descriptions, skills, stakeholder management, customer engagement, etc.

At the point that you want to bring the innovation in-house, you will have to pay that debt, so where have you found yourself? Did hosting the innovation event outweigh the debt incurred? Sometimes yes, sometimes no.


And that brings me to my last point. I’m struggling to think of – actually, I can’t think of – a single company that has ran an innovation event and then openly discussed those innovations a year later. There are companies that regularly host innovation events and there are those that are starting out in 2018 for the first time. Of those that have hosted previously, none publish what’s happened since. Some do not refer to previous events. A few publish what happened soon after the event, but do not follow-up with current news, reflecting on the value realised through hosting the event.

I can think of one company that has benefited from an innovation event from a cultural perspective; being able to expose its wider workforce to innovation through immersing them in a week-long festival. Even in that case, one which they openly refer to previous innovations, I do not know which of the innovations are currently active one year later.

For instance, I’d be interested to see previous entrants to the event, how they were engaged following the event and what progress has been made up to now.

I can think of one brand-led accelerator, Collider, that does publish details about previous cohorts.

Overall, it looks like the pickings are slim when trying to evaluate the performance and value of outsourcing innovation through hosting an innovation event.

Failure in public sector – The Reprise


I read Vim‘s article on What Does Failure Mean for Public Services  and I wanted to respond. I wanted to build upon Vim’s thoughts from my own perspective. I’ve developed that perspective over a couple of decades working across front-line teams and supporting teams, transforming workforces across public and private sector. This results in me having to balance many different levels of change (including success and failure) ranging from a conversation discussing funding allocations over £100m, followed by a conversation discussing attitudes to change, shortly followed by another discussing the approach for very local decision-making such as choosing the ideal location for a printer.

It’s mostly the same

We should see failure in the public sector in the same way that we see failure in the private sector with the one, not so subtle difference; the public sector is there to make a difference to the population. Pick a public sector service, if it’s not making a positive difference to the population, then it’s failing. I can’t think of a simpler definition. Every other private sector metric (perhaps with some tailoring in the case of profit metric) should apply to the public sector.

Unfortunately, the more we pick it apart, the more difficult it becomes to define failure. And most of that difficulty comes from the difference between providing for the population and providing for an individual.

Most of the failure is seen at the individual level, but not extrapolated quickly enough to realise that the service is failing. Most of the success is also seen at the individual level but we don’t really celebrate these as much unless they’re specifically health-related. For many services, we only notice when they go wrong. For instance, how many local authorities celebrated 0 people in the queue for social housing back in the 70s when it was feasible? Perversely, we may be able to achieve 0 in the queue now, but that could be because eligibility thresholds have risen. It’s not the same service or the same level of service anymore.

At one extreme, we see the death of an individual, we see one person homeless. Then we see multiple people homeless due to congregating together, but it takes longer for social consciousness to become more aware of the deaths of increasing number of individuals. All of this could be failure.

Criminal or Incompetent?

“He’s either criminally incompetent or incompetently criminal”

It’s a phrase I heard years ago from a charitable organisation that raised no money after holding an event where lots of people attended and money changed hands but no profit was made to turn into funds for the charity. We’re talking small money here, margins were very tight, but even so, no-one quite knew what happened.

That’s partly how I think about the systemic failure within public services although I’ll broaden the definition of criminal to include unethical, immoral or against the mass of service users you’re meant to be serving. When a service is failing, I wonder where the decision was that caused it to fail. Was someone competently unethical or incompetently ethical? Competently immoral or incompetently moral? Bear in mind that leaves out the options of competently ethical (where they’ve chosen to improve services and made it happen) or incompetently unethical (where they tried to restrict services but enacted it poorly).

Was it an implementation or management decision by the team manager to assign a lesser-skilled worker to the case where a more experienced one was required? Implying incompetence on the manager’s part.

Or was it because there wasn’t enough money to pay for more experienced workers, resulting in only newly-qualified workers being available? Implying a deliberate decision to underfund on the funder’s part.

Did the funder underfund because they’d allocated more funds to other services? implying an incompetence on the funder’s part.

Or did that funder not have enough money to distribute to the services because of a reduction in centralised funds, e.g. from central government? Again, implying a conscious decision to underfund numerous services.


Public services are funded to meet the demand that’s expected to present to that service, e.g. through referrals from other services and bodies, through walk-in or through outreach (where the team goes out educating the population on the service available). It’s always a balance between who is at most need of the service, the funds available, the skills and experience of the team available and the time available to respond.

Considering public services have a duty to provide for the population, if a service cannot meet the demands placed upon it, who is criminal and who is competent/incompetent?

The manager should understand the costs of the service and the variation based on demand being presented. At the point that it becomes underfunded, it’s time to shout. For many services, that point was passed many years ago. Underfunding results in some people not being served or the quality of service (in terms of what can be provided, e.g. the duration of engagement such as number of CBT sessions) is reduced. That then has a further human impact, e.g. people being homeless or in debt which both can lead to homeless and in debt, which leads to decreasing health, which leads to inability to work (but possibly not recognised as inability). Even one day of no service provision can escalate quickly, exacerbated by the climate of mistrust and unbalanced power between those services with funds and those people applying for funds. That one day can result in missing benefits, resulting in deteriorating health (have to choose between rent, paying heating/lighting bills, feeding children and self, getting to a job interview, clothing, etc). So underfunding a service so that it can’t provide to all it’s designed to deliver to has a cascading effect on the system through shifting referrals elsewhere or to a position of no services available and has a cascading effect on the individual.

When viewed that way, is the funder criminal (or at least unethical or immoral) if they don’t fund the service?

Reducing Inefficiency

The issue and opportunity to this point over the last couple of decades has been the inefficiency inherent in the public sector system. Public sector services do not get the same level of investment as private sector. A telco can choose to spend multiple millions of pounds on a transformation programme and it will happen. No questions (or at least no scrutiny other than board approvals and monitoring). A public service has to jump through many hoops (each costing time, effort and money) to prove it’s spending the money wisely. So public sector transformation programmes usually start smaller than private sector counterparts to make the programme easier to approve, and end up being smaller still after being watered down through many approval boards. Each of these transformations leaves an effect, usually positive in terms of efficiency, but often negative in terms of morale and capacity to flex for the next transformation.

There is still room to go in terms of efficiency. There are still pockets with severe inefficiencies, but they’re rarely on the front-line teams to the scale that’s expected. And it’s these teams that are usually the focus of funding pressures, especially in response to changing demographics, e.g. people living longer and living with more serious needs.

Active Maintenance

In addition, services need active maintenance, to some extent in the same way that you take your car in for regular maintenance. However it’s more than that. Active maintenance is not simply day-to-day management and keeping it running. It’s observing the service from multiple angles to understand what’s happening that shouldn’t be, to uncover why it’s happening and to resolve it so it doesn’t happen again. That takes an investment of time and energy.

In most public sector hierarchies that responsibility falls to the manager. The better managers (there are a few of them) have empowered their team to do this daily. They’re succeeding in keeping the service to acceptable levels (although still probably underfunded to do the job they were originally tasked to do) and keeping ahead of changes in demand. Then there are others who are just managing the day-to-day or take on adapting to change themselves. Even if competent as day-to-day managers, they’re incompetent overall since the service remains static.

Failed Culture

Vim mentions that “Failure in the public sector is also rooted in a culture that means you can’t fail”. The issue is wider than that. It’s already failing. It’s already underfunded. Austerity or not, there isn’t sufficient money to meet front-line services at their current level of demand in the way that they are currently working. Asking a team to be prepared to fail is an awkward request since in their hearts, they’re already aware of the people they’re not able to help. Most of the professional health colleges put a focus on treating the person in front of you, not those in the queue later on. Give proper treatment to the person that you’re currently treating. In a throughput setting, such as a hospital ward with a flow of patients in and out, that makes sense. In a setting where you have a caseload, such as found in most social care settings, that makes less sense overall. The opener to this conundrum of supply and demand is that we may be able to help more people and help them better than now through experimentation. And that has to be allowed to fail. 

Even with that opener, bear in mind that there are ethical considerations in most public sector departments, especially those in education, health or care settings. The Authority has a duty to treat everyone from an equitable position, not necessarily equally. So it can’t create an experiment that disadvantages a customer segment. This can be inadvertent, e.g. by promoting one customer segment’s needs, it alters that principle of equitability. So by improving the service for one segment, it can’t make the rest of the service worse. It’s also widening the gap between the treatment of segments. That’s not a blanket “no”, just be prepared to think it through and complete an Equalities Impact Assessment before you start.

How much is too much training?

Hospital ward
I’m divided in this, but lean towards only brief training, just enough to inform them, rather than enough to practice.
On one hand, it pays to understand why change in general is necessary and specifically, why the change that you’re about to implement is necessary. Often I see professionals who spend time with the person sat in front of them (and so they are patient-centred) but ignore the mass of people also requiring the same service. It’s not that they can’t see the queue (whether a real standing queue or a waiting list), it’s that if they recognise the queue then they realise that they can’t serve everyone to the same level. For some, it’s a question of professional ethics, where their professional body demands that they treat the person in front of them to the best of their ability, regardless of the needs of others. There are good reasons for that approach.
Usually, someone, e.g. a manager or budget holder, recognises the capacity issue and so increases the eligibility threshold or reduces the professional time available for that treatment. This is an attempt to average it out. However it misses the point that some treatments take time to work, if you half the time available, then you may get zero results, not 50% of the results had you allowed the necessary time for full treatment. It also leads to a worsening service as the capacity gets further reduced through a series of cuts, so that wouldn’t be the answer that we’d choose given a choice.
More fundamentally, the communities that the local and regional health providers serve are different to those that existed 30 years ago and the changed communities have different needs. So, it seems obvious that we have to adapt the service to meet the changed needs.
On the other hand, the health professionals are just that; professionals in health. There will be some with additional skills; some complementary, some tangential. I wouldn’t expect health professionals to be experts at change. However they do need to be aware of the change and why they have to contribute. As do we all, no matter what job we perform, no matter which sector we work in.
By recognising the above issues, we can more easily understand why we have to continually change. It’s a matter of adapting to needs. However that doesn’t feel like it requires a formal training in the guise of a university module, more an hour or so during induction combined with some questions during the interview to assess their attitude to change. I expect the professionals to know the service best, so they should be best placed to change it rather than having budgetary changes applied without thought to impact on patients.
To get this message across and gain acceptance and commitment from the group, I usually go through the need for change at the start of any change programme and definitely before each intervention.
One area where I think some training could be useful is in negotiating and debating how services will change. The changes will happen, but being able to influence the changes could be invaluable. Oddly enough though, it’s probably not the health professionals who need the training, instead it’s for anyone who’s trying to change the service, e.g. performance improvement staff, HR/OD, commissioners, etc.
I think the reason for my varied opinions above is that I see a difference between management and change management. I acknowledge that management techniques should be taught in advance as well as broad concepts of changes management, whereas the required, more detailed parts of change management can be taught as required.
I don’t believe we should conduct changes without speaking to the end customer. Taking on the role of patient, I’d much prefer the consultant to have spent their time learning how to treat patients, rather than learning how to manage change. Let’s permit some degree of functional specialisation, with front-line professionals continuing to be good at what they do and change professionals helping them create/design the service that the patients need.
However, I recognise that many front-line professionals either don’t have access to change professionals or do have access but that they’re not listened to. Hence the need for a book that’s applied for front-line staff.

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.





Draft or Final


Some organisations have a different approach to how they handle the status of a document. The approach belies a more fundamental culture of how work is commissioned and reviewed and how staff are viewed.



One of my clients exhibited odd behaviour regarding commissioning work and approving it.

Due to the nature of the engagement, decisions were made by me and then relayed to the client. That, almost unilateral, form of decision-making has not be the norm for my engagements. Instead, I’d have preferred to have reviewed the actions while I was working on those actions (rather than after the fact). It was all a bit backwards compared to any other client engagement, where we would address scope questions early on and progress from that more detailed, joint understanding.

Even though I was assessing business capability maturity, it felt contractual. I would have preferred a more collaborative approach, but the organisation’s approach to generating change was a contractual one. It’s an issue I’ve seen before but not as stark as with this client.



What I’d noticed with this client, was that if a document were released (no matter what version or draft status), it would be treated as final and published. The review comments would imply that the author had made mistakes and that it should never have been released in that format. Fortunately that didn’t happen to me, but that’s probably more to do with how I released documents. My documents had the same version control I’m used to including with many clients and consultancies. Draft documents (assuming little or no sensitive content) are published early to the intended audience for review, in order to influence the outcome and content of the report. The more sensitive the content, the more restricted the initial distribution and the earlier that guidance is requested.

With this particular client in mind, that approach would raise conflicting issues. The reviewers wanted to be able to influence the outcome of the commissioned work, due to the political status within the organisation. But the reviewers wanted to meet as a group to review the version, not necessarily as a steering group, to guide the work to completion, but as a review panel.


Review Panel
Review Panel

I had to tread carefully as to what documents I would release to anyone, regardless of draft status. While I’m used to not initially sharing electronic versions of documents with some clients, it was more important with this client. It created an odd culture, where people would complete work before releasing it, which then created rework and longer delays due to having to fit in reviews and changes.

Perversely, it also created a set of behaviours where many documents never reached a true state of finalisation or approval. Instead, they continued in some draft existence until ignored or replaced. That was a common occurrence, where I’d be looking for a previous strategy document, to find that it never reached completion, but became generally accepted as defining a destination or discarded. However, there had been no formal acceptance or rejection of the content, just a tacit decision across many people.

Reverse-Engineering the Culture

Hierarchy of pieces
Hierarchy of pieces

I think that much of the commission and review behaviour occurred due to the hierarchical nature of the organisation. That culture enforced a situation where superiors reviewed the output of their underlings. Couple that with an admonishing culture, rather than a praising culture, and you end up with a situation in which documents have to be final, or the critique becomes more about the person than about the document itself.

This was more than just a client seeing a document and then acting on it, treating it as a final document, e.g. to assist with negotiation or alter their position within the organisation. This was a systematic approach to not adhering to how artefacts are created and developed through to release and acceptance.

There was a severe hierarchy in the organisation where one grade couldn’t comfortably jump a grade when communicating, instead everything had to be passed up or down the chain. While organisations can work like that, many adapt and maintain the lines of communication even with flexibility and the exigencies of operating in any modern market. This organisation did not flex and those that did flex were generally put them back into place.

All of this led to gross inefficiencies and confusion due to navigating the corporate hierarchy. I’ll reiterate, the concept isn’t rare, but the ultra-strict adherence to hierarchy is rare.

This particular client compounded the inefficiencies from the hierarchy with the inefficiencies of poor document version management (or rather the document acceptance process), resulting in intricate, exhausting dance of what to share and what not to share, who to share it with and who not to share it with. All of this encouraged and promoted a contractual culture rather than a collaborative culture.

The Parallels Between RPA and Fax Automation

Fax Machine

There are times when the cheap and nasty solution is so economically efficient that it can preclude doing it properly later on.

Background – The Fax

Just under a decade ago, I was working with a local authority client and their NHS hospital partner. The interpretation of the law at that time was that email was considered a non-secure channel. Fax was at the time the chosen channel since it was considered to be secure.

So documents were sent from the hospital, via the fax machine to the fax machine in the social care offices. Continuing Health Care panels met to decide on whether the NHS or the local authority paid for the care, based on whether the primary need was a health need or a social care need. That’s simplifying the logic behind the process and the decision but it’s enough detail for this article.

To be able to make that decision on tens or hundreds of thousands of pounds per year per person, that panel needed to review the data about that individual carefully. So this meant that 40-150 pages per person would be faxed from the hospital to the social care office.

The process for this was relatively convoluted:

  • the hospital professional (therapist, nurse, discharge planner, etc) collates the documents
  • they ring the social care office and tell them they’re about to send the documents
  • they feed the documents into the fax machine
  • they’re sending more than the fax machine can fit into its auto-document feeder, so they have to standby to top it up
  • at the other end, the fax machine starts printing
  • the social worker picks up the paper before it falls onto the floor
  • the fax machine runs out of paper (several hundred pages per panel and it’s likely that you’ll have to refill the paper)
  • the social worker obtains blank paper, loads the fax machine with the new paper
  • the social worker collates all the faxes
  • the hospital professional rings the social worker to confirm that they have the documents.

The First Proposal – Email

Naturally, the partners want to make this more efficient so the design conversation usually reverts to proposal of email. But, as mentioned earlier, that’s not considered secure. Or at least the email solutions available at that time were not secure.

But there is a strange alternative.

The Implemented Solution – Fax Gateway

We used fax gateways at either end. It turns an email into a fax to be communicated on the phone line, to then be converted back to an email at the other end. The revised process was a lot more efficient:

  • the hospital professional (therapist, nurse, discharge planner, etc) collates the images ready to be sent (e.g. prints to file or scans in the remaining few that they don’t have electronically)
  • they send an email containing the fax header and the documents to their fax gateway
  • at the other end, the fax gateway converts the received fax into an email for the social worker.
  • the social worker reads the email and downloads the attachments ready for the panel

It’s a solution that shouldn’t have existed. It relied on old technology but until the law caught up with the technology (or the technology caught up with what it had to do to be secure, e.g. accounts, etc), then it was the cheap, workable solution. But it was messy and I shudder every time I think of it as a solution. However it made it better for the clients, making the process simpler for them as end-users and freeing up time to do more important work.

Front-End RPA

That’s what the current state of RPA feels like to me. Not the whole of RPA, but the element that’s involved in the user front-end of systems. It’s like the fax gateway. So instead of the better solution of orchestrations between the various IT systems involved, we’ll automate the front-ends.

The Parallels

Now I’m wondering if we’ll see the same situation with RPA as we did from implementing the fax gateways. We found ourselves with a cheap and nasty solution which then made the business cases for full integration prohibitive.

Why would you spend hundreds of thousands of pounds on a better solution when the cheap one works adequately?

So if that angle of RPA solves the automation from a front-end, replacing the mundane tasks performed by employees, why would we look to orchestrate the back-end?

Will initial RPA implementations deter us from better integration of products? And, more importantly, is that necessarily a bad thing? After all, my NHS and LA client were still able perform better with the cheap solution than they were able to without it, and they also avoided a costly integrated solution. In the end, it was a temporary measure until secure email became a practical solution for them and their partners. I’d expect to see parallel initiatives nowadays with RPA, with clients improving their efficiency through the introduction of RPA, but avoiding more costly integration. Especially, as a temporary measure that will likely have a longer-than-intended lifespan.

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