Applying Different Categories of Knowledge

Introduction

Categories of Knowledge
Categories of Knowledge

We should be careful when we judge the effectiveness of others and reflecting on this can in turn help influence us in how we approach change activities. I’ll use this chart (shown in more detail further down) to describe the differences.

First Day Effectiveness

On numerous occasions, I’ve seen people judge others by their effectiveness on the first day at work.

In some cases that may be fairer than others, but let’s take the view of a clinician arriving on a hospital ward for the first time. That nurse may be one of the best nurses ever to have existed, complete with outstanding nursing skills and excellent nursing experience, but they may be judged overly harshly as being ineffective due to not knowing the location of certain items on that particular ward.

It always takes some time to understand how a new environment works, whether that’s where items are stored, who to ask or what policies an organisation has in place compared to other organisations where you’ve worked. If you’re a temporary or bank worker, then you have to face this every time you start somewhere new. Fortunately, the more you change environment, the more adept you become at picking up the nuances of each new environment. But that does not remove the fact that each time is still a new learning experience; it just reduces the time you take to adjust as you begin to spot patterns between different environments.

Take-away Points

There are two points that we should consider:

  1. We should separate out professional knowledge from knowledge about the local environment, including the organisation.
  2. A person can be judged on many different axes of professional knowledge. For instance, a nurse may be an awesome nurse, but would they be a good change professional or a great accountant?

Further Analysis

The chart below depicts the typical range of knowledge seen on change programmes. I’ve treated these as different categories of knowledge and I have chosen to blur the lines between knowledge and skill.

It is rare in most organisations to have sufficient critical mass of people who know the organisation, know how each team works and know how to progress change effectively. People usually fall on one side or the other or there are too few of those that have knowledge on both sides.

So we introduce a change professional, whether a business analyst, change analyst, change manager or other similar role. They are introduced to the local, operational team and the aim is to balance the team’s knowledge of what they do and the organisation with the consultant’s knowledge about how to effect change. Neither would be functional without the other in this scenario.

Categories of Knowledge
Categories of Knowledge

The more time that a consultant spends within a sector the less they’ll need sector advice. The more time that a consultant spends within an organisation, the more they’ll know how to act directly (and this can happen very quickly depending on the style of consultancy involved). However, it’s nearly always the case that the consultant will still need the team to provide local knowledge, no matter how long they spend together.

Further Thoughts on Reversing our Approach

The usual view on a change programme is of allowing the change analyst or consultant to gain the knowledge of how the organisation works from those currently working in the teams.

What advantages could we see if we reversed this concept and instead helped the teams to gain knowledge about change programmes from the consultant?

By this, I’m not thinking of being trained (whether through train-the-trainer concepts) or shadowing, but something more fundamental.

Imagine the benefits to an organisation if every hour of a consultant’s time spent learning about current processes, etc is also followed by an hour of the team learning how to make changes. It would slow down the pace of change initially, but would it decrease change fatigue, would it decrease resistance? Could it also increase success of change and the scale of change achievable?

Service Improvement Book – In Progress

Lean Service Improvement Book

After a year or so working with a large, complex client and some time before that working on a startup, I’m back to writing the book I started a couple of years ago.

Three good things have come from this break:

  1. Both of the experiences have confirmed that the book needs to be written. What I have seen in the last two years has proven to me that there is a gap and this book will fill that gap
  2. Both of the experiences have provided more evidence about which tools and techniques work well
  3. From a personal perspective, the break has given me more motivation to complete the book

I expect to be publishing in 2016.

Forthcoming Book on Improving Your Own Service

Lean Service Improvement Book

Some of you may already know, I’m in the process of writing a book on improving your own service.

Lean Service Improvement Book
write by followtheseinstructions under CC BY-SA 2.0

I’m aiming the book at the people who work the process themselves, e.g.:

  • nurses
  • social workers
  • claims adjusters
  • HR/OD staff
  • office managers
  • office administrators
  • hotel staff
  • and their managers
  • and change agents/analysts

As you can see, it’s not restricted to any industry, but will be most relevant to those working in service industries (whether from private, public and 3rd sector), so that should include:

  • public sector
  • health
  • finance
  • retail
  • leisure
  • legal

More accurately, the information in the book could be useful for any industry, however there already exist books for improving manufacturing production processes, so I have not covered them.

What’s the book about?

The focus is on improving a service without recourse to large consultancy fees and should work well on small changes locally within a team and managed changes with partner teams and organisations (e.g. suppliers and B2B clients). It’s heavily based on Lean concepts, using simple tools, but also includes a framework in which to manage the changes. I’ve borrowed from a number of methodologies and concepts to meld together a method that is suitable for the average worker and implementable in any service team.

Your Input

While I’m happy to write this book alone and for everyone to read, I really like the idea of the readers contributing their thoughts as I write it. This fits nicely with the Lean Startup model, so to accomplish this, I’ve listed the current table of contents below. Please have a read through the table of contents and let me know what you think. If you’re interested in this book, let me know what you want to learn from it.

Draft Table of Contents

Section I: Beginning
1    Introduction
2    Background
3    Where to Start?
Section II: Redesign
4    How to Redesign the Service
5    Detailed steps for How to Redesign a Service
Section III: Other Paths
6    Refocus service on customer
7    Only have today to make changes
8    Bottleneck Resolution
9    Reduce errors and improve service
10    Create a new service
11    Improve office layout
Section IV: Case Studies
12    A Real World Example: Capacity and Value Stream Owner
13    A Real World Example: Duty Role in Social Care
14    A Real World Example: Urgent Cases in Social Care
Section V: Extensions
15    Other sorting methods
16    Making it Happen
17    Managing the Change
Section VI: Continuing
18    Sustaining Change
Section VII: Reflections
19    Important Perspectives
20   Other Frameworks
21    A final piece of advice
Section VIII: Appendices
22    Appendix A: The Rules
23    Appendix B – Pocket Guide for Service Redesign
24    Appendix C – Indicators of Blocked Flow and Waste
25    Appendix D: Tools
26    Appendix E: References
27    Quotes

Lean Cost Benefit Analysis of a Quick Improvement

Kanban prototype for an NHS Acute service
Kanban prototype for an NHS Acute service
Kanban prototype for an NHS Acute service

Last week, I was provided with the short opportunity to improve a service within an NHS Acute Trust. I had 5 minutes to understand the problem and then I suggested a quick improvement. I’d like to take you through how we arrived at a solution and the resulting lean cost benefit analysis of that solution.

I don’t get that involved in the individual solutions anymore, instead I’m usually engaged for more strategic issues and end up mentoring others to make the changes across the whole organisation or enterprise. So it was fun to roll up my sleeves and suggest a solution that could work in a hospital. I fully expect the team to modify it to suit their specific needs and I’ll be on hand to help them improve it.

So let’s get to the calculations:

Lean cost benefit analysis

Analysis Investment

  • 5 minutes x 1 health professional explaining the problem
  • 5 minutes x 1 consultant listening to the problem
  • 5 minutes x 1 consultant developing a solution
  • 10 minutes x 1 consultant describing how the solution could work and what could be changed to make it more suitable
  • 15 minutes x 1 health professional understanding the solution
  • 1 x flipchart paper
  • 1 x pen

Potential Savings

  • 3.5 hours per day x 4 health professionals across a 5 day week = roughly 2,800 hours a year
  • The 3.5 hours is based on a reduction from 4 hours to 30 minutes for handover and prioritisation.
  • At roughly 1,400 working hours per year (based on 200 days per year and 7.5 hours per day), that equates to 2 FTE (full-time equivalent) posts saved per year.
  • So that could mean the service treating a lot more patients,  a potential cashable saving of roughly £70,000-£90,000 per year or – as is often more likely – a mix of the two

Not bad for a 15 minute session.

Practicalities

Implementation

The solution would need installing, but that’s the easy part. It would require some pens and a whiteboard or similar. That’s probably £200-£400 for a board and magnetic strip and counters plus £20-£50 per year for pens.

The implementation would usually rely on a critical core of the staff wanting to implement the change. In this case, by applying Lean Startup concepts, just one staff member could do it and then the others will learn about how it could affect their working lives and the impact on their patients.

What was the solution?

My suggestion was based on Lean, using a Kanban board. It relies on the principle of visual management. In this case, it’s easy to see at-a-glance where the work lies. It seemed a perfect fit for the problem. Due to the small amount of time spent with the service, there is a significant risk that the solution may not work for all the health professionals involved. I’d have liked more time with more of the team to mitigate this risk.

My aim was to improve flow. There was a blockage in the handover stage of the day and that’s what I wanted to eliminate. With more time, I’d have taken a more relaxed view of the entire process, involving other stakeholders, referring teams and teams that are being referred to. As it was, engaging with only one health professional, I focussed on what could be achieved quickest to remove the blockage.

The kanban board isn’t the end of the solution; it’s the start. I expect the therapists to find that the bulk of their work is being stuck in one or two stages or that they are not able to provide services to low priority cases. I don’t actually know what they’ll find, but that’s what I would be looking for. After the therapy team have been running the board for a week or two, they should be able to see patterns. Then they can act on those patterns.

Perspective

So which appeals more; the lean solution itself or the numbers in the lean cost benefit analysis?

From my perspective, they’re two sides of the same improvement and I teach analysts to remember both sides (and some others) when engaging with teams and their stakeholders.

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

Use Case Diagrams for Documenting Scope

Use Cases

I embraced UML as a communication tool some years ago and have found it successful in being able to convey messages in a simple manner. I don’t use every type of diagram – some are too strange for the average business user. I do use Use Case diagrams. These are great and, with a small amount of education, are suitable for use with business users.

Use Case Diagrams for Scope

As a communication tool, Use Case diagrams are great at showing who does what at a very high level. They’re good at showing system solution scope, types of actors and ownership of integration points. In one diagram, I can show the scope of the system in a way that users will understand. Now that’s a powerful tool.

Depth of the Scoping Use Case

Ideally I like to have short Use Cases, perhaps 2 or 3 sentences at the highest level. Used like this, they don’t conform to the more common view of Use Cases, but they do give a good, brief overview of what happens in the solution. More detail is required in later stages, but you can’t beat a concise description to get the ball rolling.

Why use Use Case Diagrams for Change Management?

There’s a system involved. By system, I don’t necessarily mean an IT software application. There are people, teams, dependencies on other organisations, dependency on phone network being available and so on. Often the people in the change team, including the users themselves are not aware of all the interactions that they have with these external organisations (including teams in the same organisation). This is where a simple Use Case comes in. It can show, at a single glance, the main interactions between the team in question and their environment. I use them to gain a joint understanding of what the team does now, or what they’re trying to change to.

Multi-level Use Cases

Originally the concept was that a system had 10-20 Use Cases. If you had vastly more than that, then you were doing it wrong, it you had less than 5, you probably weren’t analysing far enough. Time’s moved on and real-world, practical experience has been added to this. What analysts and software methodologists/project methodologists came to realise was that the power of Use Cases was that they were readable and understandable by users but that to capture sufficient detail, they were becoming unwieldy and cumbersome. Alistair Cockburn has been influential in his work promoting Use Cases at different levels, some will be user and high-level, some more detailed. It does raise the risk of implementing a more traditional waterfall approach where one analysis has to follow on from another.

Use Case Diagrams for Developers

I know that there’s a strong argument for not using Use Case diagrams at all. This comes from developers and I can understand their perspective. That’s fine by me, I expect developers to know what works for them better than I do. In their case, the text of Use Cases counts for more. That doesn’t prevent analysts from using the tool.

Mentoring and Training

Bottle Stack
Bottle Stack

All of the changes facing every organisation require skilled personnel, either increasing a team’s knowledge in the tools and techniques used for change or by mentoring analysts, providing guidance and supervision.

Training

Training packages can be developed in the following:

Each training package is bespoke, specifically tailored to the client’s needs.

Mentoring

Mentoring is a longer engagement than training, designed to offer support to your staff in their profession. For those involved in the change profession (change analysts, business analysts, business process analysts), we can provide a mentoring service; either with regular drop-ins or remote via email or onto your organisation’s existing discussion forums. This service should be considered as supplementary to the standard employee mentoring and welfare within your own organisation.

It is ideal for SME (Small-to-Medium Sized Enterprises) with one or two business analysts, but who do not have sufficient need or resources to accommodate a wider analysis function. This service provides mentoring by a senior analyst, reducing what could otherwise be an costly commitment for a small organisation and providing experience from a number of industry sectors.

This mentoring service will open up the opportunity for your own staff to think more strategically and, eventually, develop your organisation’s target operating models.

Want to know more, then contact us.

Strategic Analysis and Direction

Direction sign
Direction sign

Bringing a calm strategy to muddy waters. The benefit of using external consultants is that they can see through the internal politics and difficulties.

Strategic Analysis and Direction

Often the direction is not clear; there are a myriad of options or the service is trapped in an ever-continuing scenario of fighting daily fires. If you’re in that situation, then you could benefit from an engagement of Strategic Analysis. In that engagement, we look for the critical fulcrums; those pivot points that provide the greatest benefit to you at the time that you will need them.

We specialise in Lean concepts, finding it more applicable to service industries than Six Sigma or mixed Lean Six Sigma. By applying these concepts at a strategic level, organisations can achieve more efficient and aligned processes and teams. In the end, we’re always aiming for a better, smoother flow of work.

Target Operating Model

A specific package of the strategic direction resulting in a model for how your service will operate in future. It provides a destination against which all other changes can be evaluated. Target Operating Models (TOMs) usually consist of several integrated layers (e.g. geography, functions, customers, etc). The choice of which layers to use and how to represent them depends on your situation and can be discussed during engagement.

Want to know more, then contact us.